Я знаю, что большинство статей, посвященных микросервисам, говорят мне, чтобы микросервисы были независимыми и владели базой данных. Мы создали ограниченные контексты или области, которые не зависят от других контекстов. Такой домен, однако, имеет разнообразный список различных возможностей, технологий, интеграций или масштабируемых единиц.
Как видно на рисунке, каждый домен имеет несколько сервисов, использующих один и тот же ресурс (базу данных). База данных домена А содержит около 7 реляционных таблиц. В Домене A у нас есть службы для:
- Получение новых сущностей домена (ReceiveStation)
- Служба уведомлений для пользователей веб-приложений (SignalR)
- Процессор рабочего процесса для запуска бизнес-правил (автоматизированный процесс)
- Средство развертывания базы данных (Roundhouse)
- Открытая читаемая служба для внешних доменов для чтения данных из (AggregateGrpcService)
Преимущества этой архитектуры :
- Мы можем масштабировать каждую службу независимо
- Конфигурация для каждой услуги менее сложна
- Легче найти узкие места в производительности
Статьи, подобные « 11 причин, по которым вы отказываете при работе с микросервисами », скажите, что я не должен создавать сервисы для каждой интеграции. Они также говорят мне, что ни один сервис не должен напрямую общаться с базой данных другого сервиса. Я действительно проектирую свои микросервисы неправильно? Как сохранить описанные преимущества, если я объединю все службы в домене? Или есть другие способы сохранить эту гранулярность и сделать все сервисы независимыми?