Монолит vs микросервисы

Выбор между монолитной и микросервисной архитектурой является одним из ключевых решений в разработке программного обеспечения. Монолитная система представляет собой единую программу, которая выполняется в одном процессе, в то время как микросервисная архитектура состоит из множества независимых сервисов, каждый из которых выполняется в отдельном процессе. Такой выбор имеет значительное влияние на эксплуатацию, масштабируемость и поддержку системы.

Как это работает

Для того чтобы определить, какая из этих архитектур подходит лучше всего, можно задать себе три ключевых вопроса:

1. Структура команды: достаточно ли команд, чтобы каждая владела одним сервисом? Если количество команд меньше пяти, это может указывать на то, что монолитная архитектура является более подходящим решением.
2. Независимое масштабирование: имеют ли разные части системы сильно разные нагрузочные профили? Если да, микросервисная архитектура может быть более эффективной, поскольку позволяет масштабировать отдельные сервисы независимо друг от друга.
3. Независимость деплоя: нужно ли командам выпускаться независимо друг от друга? Если да, микросервисная архитектура позволяет выполнять деплой каждого сервиса отдельно, что упрощает процесс обновления и поддержки системы.

Правило Sam Newman — 'monolith-first' — рекомендует начать с монолитной системы и только затем переходить к микросервисной архитектуре, когда это становится необходимым из-за роста команды или увеличения нагрузки на систему.

Когда применять

Независимо от размера проекта, рекомендуется начинать с монолитной системы, поскольку это позволяет избежать сложностей, связанных с управлением множеством независимых сервисов. Переход к микросервисной архитектуре следует делать, когда:

1. Количество команд превышает пять, и каждая команда должна управлять своим собственным сервисом.
2. Координация деплоя стала узким местом, и требуется возможность независимого выпуска каждого сервиса.
3. У конкретных сервисов есть на порядок отличающиеся нужды масштабирования.

Типичные ошибки

1. Микросервисы ради резюме: принятие модной архитектуры без реальной нужды. Это может привести к тому, что команды будут сталкиваться с сложностями управления распределенной системой, что может привести к снижению производительности и увеличению времени разработки.
2. Distributed monolith: когда сервисы, которые не могут деплоиться независимо, делят общую базу данных или вызывают друг друга синхронно. Это создает худшие аспекты как монолитной, так и микросервисной архитектур.
3. Преждевременная декомпозиция: когда система делится на микросервисы слишком рано, до стабилизации доменных границ. Это может привести к необходимости постоянных переделок и слияний сервисов, что усложняет процесс разработки и поддержки системы.

Связанные понятия

• Monolith
• Modular Monolith
• Microservices
• Trade-off Analysis