Обычно монолитную архитектуру (рис. 38) можно описать так:
1. Единая точка разработки и релиза.
2. Единая база данных.
3. Единый цикл релиза для всех изменений.
4. В одной системе реализовано несколько бизнес-задач.
Рис. 38. Архитектура монолитного приложения
Материалы для погружения в контекст для специалистов в IT:
1. Pattern: Monolithic Architecture[54].
2. Бизнес-гибкость через микросервисную архитектуру (раздел II, глава 2).
3. Don’t start with a monolith[55].
Система единая, при этом решает много разных бизнес-задач. Разные бизнес-задачи развивают разные подразделения компании и двигаются с разной скоростью. Отсюда возникает проблема с взаимозависимыми релизами разных подразделений, когда все ждут самого медленного.
Сложно масштабировать бизнес-приложения, которые объединяет монолит. Это приводит к тому, что особенности каждого приложения не учитываются, а масштабирование неэффективно.
При выборе технологического стека для новой бизнес-задачи приходится подстраиваться под среду разработки монолита, хотя этот выбор не всегда является наилучшим.
Система полностью уходит в релиз, поэтому должна быть протестирована целиком. Это приводит к сложному регрессионному тестированию, затягиванию процесса тестирования и репортинга багов всем поставщикам изменений, замедлению скорости релизов и, соответственно, увеличению времени поставки новой версии, то есть пользователи дольше не увидят новые функции.
Последнее ведёт к тому, что бизнесу тяжело быстро собрать обратную связь от рынка.
В основе процесса выделения микросервисов лежит вынесение бизнес-задач из монолита в отдельные сервисы. Для этого нужно руководствоваться принципом единственности ответственности (SRP)[56], который можно выразить так: у микросервиса должна быть только одна причина для изменения. Этой причиной является изменение бизнес-логики той единственной задачи, за которую он отвечает.
В дополнение к SRP есть подход от любителей Domain-Driven Design: микросервис ограничивается одним или несколькими Bounded Context[57].
Постепенно у вас образуется набор из микросервисов, где каждый отвечает лишь за свою бизнес-задачу (рис. 39).
Рис. 39. Архитектура небольшой системы на микросервисах
Погружение в контекст для специалистов в IT:
1. Переход от монолитной архитектуры к распределённой [58].
2. How to break a Monolith into Microservices[59].
3. Command and Query Responsibility Segregation (CQRS) на практике[60].
4. Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы (раздел II, глава 5).
Чтобы не упустить ничего важного при создании микросервисной архитектуры, полезно периодически проверять себя по чек-листу The Microservice Architecture Assessment[61].