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

Один продукт можно разделить по-разному

Архитектура приложения — это не выбор между «старым монолитом» и «современными микросервисами». Главный вопрос в другом: где проходят границы ответственности и насколько независимо должны изменяться, развёртываться и масштабироваться разные части системы.

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

Что разберём

• Монолит. Посмотрим, как устроено приложение, которое собирается и развёртывается как единое целое, и почему это часто хороший старт.
• Модульный монолит. Разберём, как сохранить единое развёртывание, но провести явные внутренние границы между частями системы.
• Основы микросервисов. Поймём, что именно делает сервис самостоятельным и какие новые свойства появляются после разделения приложения на процессы.
• Декомпозиция сервисов. Научимся искать разумные части системы для выделения, а не делить приложение по таблицам или техническим слоям.
• Границы сервисов. Разберём, какие данные и правила должны принадлежать одному сервису и почему неудачная граница создаёт постоянные зависимости.
• Database per Service. Посмотрим, зачем микросервисам владеть своими данными и почему общая база возвращает сильную связанность.
• Переход к микросервисам. Разберём постепенную миграцию вместо рискованного переписывания всей системы за один раз.
• Компромиссы микросервисов. Соберём вместе стоимость распределённой архитектуры и критерии, по которым её преимущества действительно окупаются.

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