Введение: появление минисервисов
В сегодняшних реалиях все привыкли к тому, что есть всего два классических варианта архитектуры программы – монолит и микросервисы (пока вынесем за скобки serverless и т. д.). И, в основном, если речь идет о монолите, то о его миграции и переходе на микросервисный подход. И можно подумать, что наши архитектурные подходы живут в черно-белом мире, где есть только добро, зло и ничего другого. Но не все так просто, как кажется на первый взгляд.
Потому как третья альтернатива появляется подход с использованием минисервисов.
И чтобы понять разницу между всеми вышеизложенными вариантами, предлагаю иди постепенно. Важно понять, что дальше речь будет идти об основных характеристиках каждого из подходов, поэтому более подробные особенности могут быть проигнорированы.
Разбираемся в типах сервисов
Монолит (макросервис)
Достоинства:
- Простота. Монолитные архитектуры просты в создании, тестировании и развертывании. В основном масштабируется вертикально (путем увеличения количества RAM и CPU), ведь использование горизонтального масштабирования не целесообразно.
- Сквозные проблемы (Cross-cutting concerns): с помощью единой кодовой базы монолитные программы могут легко справиться со сквозными проблемами (Cross-cutting concerns), такими как логирование, управление конфигурацией и мониторинг производительности.
- Эффективность. Компоненты в монолите обычно совместно используют память (RAM), поэтому и взаимодействие между ними быстрее, чем связь между сервисами с помощью IPC или других механизмов.
Недостатки:
- Надежность. Ошибка в любом из модулей программы может привести к остановке всего приложения.
- Обновление. Через единую большую кодовую базу и тесную связку, для каждого обновления нужно будет развертывать все приложение.
- Стек технологий. Монолитное приложение должно использовать один и тот же технологический стек. Изменения в технологическом стеке стоят дорого, как с точки зрения времени, так и затрат.
Микросервис
Достоинства:
- Возможность экспериментировать с разными технологиями: между модулями есть меньшие технологические зависимости. Откат к предыдущим итерациям менее сложен.
- Малое связывание (Low coupling): компоненты микросервисов слабо связаны, поэтому они не взаимосвязаны и могут быть проверены отдельно. Это также делает приложение более адаптированным к изменениям с течением времени.
- Улучшенная изоляция неисправностей (fault isolation): большие приложения продолжают работать в случае сбоя одного модуля.
Недостатки:
- Коммуникация между сервисами усложняется: поскольку каждый сервис является независимым, поэтому необходимо обращать внимание на варианты взаимодействий для service-to-service communication[2]. В одном из таких сценариев разработчики могут быть вынуждены писать дополнительный код во избежание сбоев.
- Тестирование и мониторинг: как только вы разбиваете программы на независимые сервисы, у вас будет больше движущихся частей, которые нужно отслеживать и исправлять. Без надлежащих инструментов тестирования и мониторинга ситуация может быстро выйти из-под контроля.
Минисервисы
Достоинства:
- Независимая разработка: мини-сервисы можно разрабатывать независимо друг от друга. Поскольку домены четко разделены, заключив контракты с API, командам остается только беспокоиться о выполнении задач в домене.
- Масштабирование: чтобы масштабировать программу на основе минисервисов, вам нужно только масштабировать определенные компоненты, оптимизирующие использование ресурсов.
- Независимое развертывание каждого модуля: поскольку микросервисы являются отдельными модулями, их можно разворачивать независимо в любом приложении. Если любой модуль модифицирован, всю программу не нужно перестраивать и развертывать.
Меньшие кодовые базы означают более легкое и быстрое развертывание. Это объясняется тем, что существует меньше зависимостей, о которых нужно позаботиться в рамках сервисов. Независимая развертка отдельных сервисов также делает возможным непрерывное развертывание. Таким образом, гарантируя, что программное обеспечение постоянно обновляется для пользователей.
При этом следует учитывать, что все перечисленные преимущества немного проигрывают микросервисам.
Недостатки:
- Контроль интерфейсов еще более важен: каждый сервис имеет свой собственный API, на который приложения полагаются, чтобы быть последовательными. Хотя вы можете легко вносить изменения в сервис, не влияя на внешние системы, взаимодействующие с ней, если вы измените API (интерфейс), любое приложение, использующее этот микросервис, будет поражено, если изменение не будет обратно совместимым.
- Предварительные затраты могут быть выше: чтобы архитектура работала в вашей организации, вам нужна достаточная инфраструктура хостинга с поддержкой безопасности и обслуживания, а также нужны квалифицированные команды разработчиков, которые понимают все службы и управляют ими.
В отличие от преимуществ, недостатки в минисервисах не столь значимы, чем в микросервисах.
Сравним мини и микросервисы
Чтобы понять разницу между микросервисами и минисервисами, рассмотрим варианты реализации одного ТС, используя два подхода и сравним их между собой.
ТС: Web-приложение с аутентификацией, рендерингом pdf и отправкой файлов по почте.
Подход №1 (микросервисный)
Согласно разделению ответственности (Separation of Concerns) проектируем микросервисы с четко определенными обязанностями и получим:
1) HTML-renderer service – сервис рендеринга html.
2) HTML-to-PDF service – сервис конвертации html to pdf.
3) Mailer service – сервис почтовой отправки.
4) JWT-generator service – сервис генерации jwt токенов.
5) Authentication service – сервис аутентификации.
6) File-proxy service – сервис взаимодействия с файлами.
Подход №2 (минисервисный)
Минисервисный подход предполагает группировку схожих или зависимых функциональностей в один сервис, поэтому получаем следующие сервисы:
1) PDF-renderer service – инкапсулирует функциональность HTML-renderer service и HTML-to-PDF.
2) Mailer service – остается неизменным.
3) Authentication service – инкапсулирует функциональность JWT-generator service и Authentication service.
4) File proxy service – остается неизменным.
Вывод: микро и мини сервисы остаются схожими с точки зрения взаимодействия между собой, или с базой данных, единственное отличие — это количество инкапсулирующихся обязанностей (микросервис = 1, минисервис > 1).
Сравнение в глобальном масштабе
Сравним основные характеристики различных подходов:
| Macroservice/monolith | Miniservice | Microservice | |
| Code
(вариативность языков программирования) |
1/5 | 3/5 | 5/5 |
| Deploy
(сложность) |
5/5 | 2/5 | 1/5 |
| Reuse | 1/5 | 3/5 | 5/5 |
| Development time | 5/5 | 3/5 | 1/5 |
Вывод: каждый из подходов имеет свои преимущества и недостатки, но для каждого подхода есть свой главный use-case.
Monolith – маленькое приложение (не будет увеличиваться) для быстрого выхода в production.
Miniservice – мягкая миграция (менее затратная) из Monolith.
Microservice – построение сложного/большого приложения из 0 (from scratch).
Что выбрать: критерии
Если вы планируете начать разработку нового приложения и не можете определиться, какой из подходов использовать, задайте себе следующие вопросы, которые приведут вас на верный путь
- Четко ли определены требования приложения?
- Оценили ли мы бизнес-риски?
- Есть ли у нашей команды достаточно экспертизы (в микро/мини/макро)?
- Есть ли у нас необходимая инфраструктура?