Struchkov Mark
d0a4acf39c
7.2 KiB
| aliases | tags | date | ||
|---|---|---|---|---|
|
|
2024-11-24 |
Распределенный монолит — это архитектурный Паттерн проектирования, в котором компоненты системы, хотя и развернуты в виде отдельных Микросервис, фактически зависят друг от друга настолько, что не могут развиваться и масштабироваться независимо.
!
Внешне такая архитектура выглядит как микросервисная, но из-за сильной Связанность и отсутствия независимости деплоя она теряет все преимущества микросервисного подхода и в итоге становится даже более сложной и неудобной в поддержке, чем традиционный Монолитная архитектура.
Признаки распределенного монолита:
- Высокая Связанность между сервисами, требующие координации при деплое. Из-за этого невозможно обновить или развернуть один сервис без изменения других
- Глобальные транзакции, которые охватывают несколько сервисов, что приводит к сильной связанности и усложняет управление согласованностью данных
- Отсутствие автономности сервисов. Если один сервис не может работать без другого, и их логика тесно переплетается, то, вероятно, вы имеете дело с распределенным монолитом.
- Общие схемы данных. Использование Shared Database или общей схемы между сервисами приводит к тесной связанности и усложняет внесение изменений без координации между командами.
Причины появления распределенного монолита
- Недостаточное понимание микросервисных принципов. При переходе от монолита к микросервисам важно пересмотреть подходы к разработке и взаимодействию между компонентами. Не все команды понимают, что микросервисы требуют не только разбиения на отдельные сервисы, но и пересмотра способов их взаимодействия и управления данными.
- Излишняя Гранулярность микросервисов. Желание сделать сервисы как можно более маленькими и специализированными иногда приводит к обратному результату — коммуникационные накладные расходы становятся слишком большими, и система превращается в распределенный монолит с большим количеством зависимостей.
- Общие ресурсы. Использование общих баз данных (Shared Database) или сервисов, которые нельзя изменить независимо, приводит к тому, что сервисы не могут быть развернуты или изменены самостоятельно.
- Плохой дизайн API. Сервисные интерфейсы, которые создают жесткие зависимости и требуют координации между разными сервисами, также способствуют появлению распределенного монолита.
Как избежать создания распределенного монолита
- Слабая связанность и независимость деплоя. Стремитесь к тому, чтобы сервисы были как можно более независимыми друг от друга. Это касается не только разработки, но и данных. Каждому микросервису должна принадлежать Database per service, чтобы минимизировать зависимость от других сервисов.
- Декомпозиция по бизнес-доменам. Разделение системы на сервисы должно основываться на бизнес-логике и Доменная область. Сервисы должны быть построены вокруг конкретных бизнес-процессов, а не технических компонентов, что поможет избежать тесной связанности.
- ../../../../_inbox/Событийно-ориентированное программирование. Использование событийной модели взаимодействия позволяет уменьшить тесную связанность сервисов и избавиться от необходимости прямого взаимодействия между ними. Сервисы реагируют на события, а не вызывают друг друга напрямую, что повышает автономность.
- Асинхронные коммуникации. Использование асинхронных методов взаимодействия, таких как Брокер сообщений, снижает связанность между сервисами и позволяет им работать независимо друг от друга.
Мета информация
Область:: ../../../../wiki/zero/00 Микросервисная архитектура Родитель:: Источник:: Создана:: 2024-11-24 Автор::