Здравствуйте, Shmj, Вы писали:
S>Интересует вопросы архитектуры .Net (Core) приложений.
S>1. Какую(ие) СУБД используете? Настроили ли кластер или сингле-инстанс и т.д. Про репликацию и т.д. расскажите, что интересного. S>2. Есть ли разделение на Web-сервер и сервер приложений. Как взаимодействуют и т.д. Есть ли балансировщик нагрузки. Опять же — есть ли горизонтальное масштабирование Web. S>3. Какие популярные фишки используете, типа брокера событий и т.д. S>4. Как взаимодействуете с СУБД (какой ОРМ и т.д.), по какому принципу организовали архитектуру, используете ли CQRS?
S>И вообще интересно бы посмотреть код приложения, архитектуру которого можно взять за образец. Как продвинуться в этом направлении.
За образец мои приложения из "кровавого энтерпрайза" взять вряд ли можно Но они работают в крупных компаниях, не падают, заказчиков устраивают, деньги за них платят, так что почему бы и не рассказать. Все сделаны примерно по одному лекалу.
1) В основном MS SQL Server. Ни про кластеры СУБД, ни про репликацию ни в одном проекте (своём или чужом) не слышал. В типичном бизнес-приложении высокой нагрузки нет, да и толковые администраторы, умеющие всё настраивать, встречаются редко.
2) Как-правило, делается веб-приложение. Отдельный сервер приложений не использую. Балансировщик заказчик ставит сам на своё усмотрение (как правило NGINX). Моя задача как разработчика — сделать так, чтобы сайт работал независимо от наличия балансировщика.
3) Никаких популярных фишек. Если нет высокой нагрузки и "бигдаты", то модные фишки как правило не нужны. Грамотная структура БД, толковые индексы — нужны. А фишки — нет.
4) С СУБД работаю через Entity Framework. А если БД совсем мелкая (бывает и так, если основным поставщиком данных является сторонний сервис), то прямо ADO.NET — быстро, дёшево и сердито. Как правило, выделяю отдельный уровень доступа к данным, который скрывает все операции к нижележащим ресурсам. Хотя если проект активно работает с данными из БД, то использую напрямую Entity Framework (в конце концов это тоже уровень доступа к данным). Конечно, промежуточные слои — это здорово и правильно, но итоговый ценник красивой архитектуры заказчикам нравится крайне редко.
Интересует вопросы архитектуры .Net (Core) приложений.
1. Какую(ие) СУБД используете? Настроили ли кластер или сингле-инстанс и т.д. Про репликацию и т.д. расскажите, что интересного.
2. Есть ли разделение на Web-сервер и сервер приложений. Как взаимодействуют и т.д. Есть ли балансировщик нагрузки. Опять же — есть ли горизонтальное масштабирование Web.
3. Какие популярные фишки используете, типа брокера событий и т.д.
4. Как взаимодействуете с СУБД (какой ОРМ и т.д.), по какому принципу организовали архитектуру, используете ли CQRS?
И вообще интересно бы посмотреть код приложения, архитектуру которого можно взять за образец. Как продвинуться в этом направлении.
Здравствуйте, Shmj, Вы писали:
S>Интересует вопросы архитектуры .Net (Core) приложений.
S>1. Какую(ие) СУБД используете? Настроили ли кластер или сингле-инстанс и т.д. Про репликацию и т.д. расскажите, что интересного.
Это вопрос интеграции.
S>2. Есть ли разделение на Web-сервер и сервер приложений. Как взаимодействуют и т.д. Есть ли балансировщик нагрузки. Опять же — есть ли горизонтальное масштабирование Web.
Это вопрос интеграции.
S>3. Какие популярные фишки используете, типа брокера событий и т.д.
Это вопрос интеграции.
S>4. Как взаимодействуете с СУБД (какой ОРМ и т.д.), по какому принципу организовали архитектуру, используете ли CQRS?
Это тривиальный вопрос.
S>И вообще интересно бы посмотреть код приложения, архитектуру которого можно взять за образец. Как продвинуться в этом направлении.
Архитектура — это твои решения, выраженные в твоём коде, который отражает суть решаемой задачи и не зависит от внешнего окружения.
Какая разница, какую субд или брокер сообщений ты выбрал? В правильно структурированной системе, это изолированные технические решения, не влияющие на систему в целом. А если ты склеиваешь готовые компоненты между собой, которые просто гоняют туда-сюда одни и те же данные из базы данных, тебе достаточно того кода, который студия нагенерит при создании проектов. Если человек, хорошо владеющий Экселем, может повторить всё, что делает твоё приложение — у тебя нет архитектуры, ты опять создал очередную обёртку для базы данных.
Ты задавал бы такие вопросы, если бы пришлось писать саму СУБД?
Какую файловую систему вы используете?
Консольное приложение или служба?
Используете ли вы файлы, отраженные на память?
Используете массивы или списки?
Это важные вопросы, однако они не имеют отношения к архитектуре СУБД.
Здравствуйте, Степанов Андрей, Вы писали:
СА>За образец мои приложения из "кровавого энтерпрайза" взять вряд ли можно Но они работают в крупных компаниях, не падают, заказчиков устраивают, деньги за них платят, так что почему бы и не рассказать. Все сделаны примерно по одному лекалу.
А расскажите, Андрей, как у вас дела с кандидатской?
Помнится, лет 15 тому назад вы интересовались вопросами согласованности в распределённых СУБД.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
MSSQL/PostgreSQL, MSSQL
S> Настроили ли кластер или сингле-инстанс и т.д.
Azure SQL/Для разработки сингл-инстанс, на проде Azure SQL в облаке, БД заказчика в онпреме.
S>2. Есть ли разделение на Web-сервер и сервер приложений.
Да/Нет
S> Как взаимодействуют
REST API/REST API
S>и т.д. Есть ли балансировщик нагрузки.
Да/Да
S> Опять же — есть ли горизонтальное масштабирование Web.
Да/-
S>3. Какие популярные фишки используете, типа брокера событий и т.д.
define популярные фишки
S>4. Как взаимодействуете с СУБД (какой ОРМ и т.д.),
linq2db/linq2db
S> по какому принципу организовали архитектуру,
Вопрос непонятен
S> используете ли CQRS?
Нет/нет
S>И вообще интересно бы посмотреть код приложения, архитектуру которого можно взять за образец. Как продвинуться в этом направлении.
Есть только один способ — содавать архитектуры, а потом ловить шишки на проде.
Здравствуйте, Shmj, Вы писали:
S>1. Какую(ие) СУБД используете? Настроили ли кластер или сингле-инстанс и т.д. Про репликацию и т.д. расскажите, что интересного.
MSSQL, кластер с дублированием.
S>2. Есть ли разделение на Web-сервер и сервер приложений. Как взаимодействуют и т.д. Есть ли балансировщик нагрузки. Опять же — есть ли горизонтальное масштабирование Web.
Разделения на web-сервер и сервер приложений нет.
Балансировщик — nginx.
Есть горизонтальное масштабирование сервисов.
S>3. Какие популярные фишки используете, типа брокера событий и т.д.
В свое время, еще до того как .Net Core и Web API стали мейнстримом, зачем-то прикрутили RabbitMQ.
Из-за этого в workflow сейчас используется асинхронный конечный автомат со всеми вытекающими отсюда последствиями.
S>4. Как взаимодействуете с СУБД (какой ОРМ и т.д.), по какому принципу организовали архитектуру,
ORM — сборная солянка: ADO .Net, EntityFramework (постепенно отказываемся), Dapper. S>используете ли CQRS?
нет
Но они работают в крупных компаниях, не падают, заказчиков устраивают, деньги за них платят, так что почему бы и не рассказать. Все сделаны примерно по одному лекалу.
