Здравствуйте, 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 (в конце концов это тоже уровень доступа к данным). Конечно, промежуточные слои — это здорово и правильно, но итоговый ценник красивой архитектуры заказчикам нравится крайне редко.
