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


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

Этап №1. Монолит


1.1 Характеристики


Обычно монолитную архитектуру можно описать так:


  1. Единая точка разработки и деплоя
  2. Единая база данных
  3. Единый цикл релиза для всех изменений
  4. В одной системе реализовано несколько бизнес-задач


Погружение в контекст:


  1. Pattern: Monolithic Architecture
  2. Бизнес-гибкость через микросервисную архитектуру
  3. Don’t start with a monolith

1.2 Проблемы


  1. Система единая, при этом решает много разных бизнес-задач. Разные бизнес-задачи развивают разные подразделения компании и двигаются с разной скоростью. Отсюда возникает проблема с взаимозависимыми релизами разных подразделений, когда все ждут самого медленного.
  2. Сложно масштабировать бизнес-приложения, которые объединяет монолит. Это приводит к тому, что не учитываются особенности каждого приложения, и масштабирование делается неэффективно.
  3. При выборе технологического стека для новой бизнес-задачи приходится подстраиваться под среду разработки монолита, хотя этот выбор не всегда является наилучшим.
  4. Система уходит в релиз целиком, поэтому должна быть протестирована целиком. Это приводит к сложному регрессионному тестированию, затягиванию процесса тестирования и репотинга багов всем поставщикам изменений, замедлению скорости релизов, и, соответственно, увеличению времени time-to-market.
  5. Последнее ведет к тому, что бизнесу тяжело быстро собрать обратную связь от рынка.

1.3 Как перейти на следующий этап


В основе процесса выделения микросервисов лежит вынесение бизнес-задач из монолита в отдельные сервисы. При этом нужно руководствоваться принципом единственности ответственности, который перефразируется так: у микросервиса должна быть только одна причина для изменения. Этой причиной является изменение бизнес-логики той единственной задачи, за которую он отвечает.



В дополнение к SRP есть подход от любителей Domain-Driven Design: микросервис ограничивается одним или несколькими Bounded Context.

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



Погружение в контекст:

  1. Переход от монолитной архитектуры к распределенной
  2. How to break a Monolith into Microservices
  3. Command and Query Responsibility Segregation (CQRS) на практике
  4. Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы
  5. StranglerFigApplication

При создании микросервисной архитектуры полезно периодически проверять себя по чеклисту The Microservice Architecture Assessment, чтобы не упустить какую-то важную деталь.



Этап №2. Микросервисный монолит


2.1 Характеристики


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



Из четырех способов интеграции в микросервисной архитектуре обычно не используют обмен файлами и стараются не использовать shared database, зато активно работают с RPC и очередью сообщений.



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





По факту, получился тот же монолит, но с большим количеством новых проблем.

2.2 Проблемы


  1. Прямые связи между микросервисами усложняют анализ проблем. Например, запрос может пройти через 5 микросервисов, прежде, чем вернуться с ответом. Что если на третьем микросервисе запрос завис? Что если там была ошибка? Что если на втором шаге должно было создаться сообщение в очередь, но оно не появилось? Возникает сложность с разбором проблем.
  2. Предыдущий пункт усложняется, если у микросервиса много экземпляров. Тогда возникает ситуация, что запрос пришел на экземпляр, который завис.
  3. Архитектуру сложно понять и, чем больше сервисов вы добавляете, тем запутанней всё становится. В целом, добавление новых сервисов нелинейно повышает сложность архитектуры.
  4. Неизвестно, кто потребители вашего API, что добавляет сложности в проектировании API и его изменении.
Если на пути рефакторинга монолита вы остановитесь на этом этапе, то, вполне резонно, сделаете вывод, что с монолитом было лучше и дешевле.

2.3 Как перейти на следующий этап


Основные идеи: локализовать точки интеграции и контролировать все потоки данных. Чтобы этого добиться, надо использовать:

  1. API Gateway для локализации синхронных взаимодействий и мониторинг/логирование трафика между микросервисами. В идеале, надо иметь визуализацию трассировки любого запроса.
  2. Service Discovery для отслеживания работоспособности экземпляров микросервиса и перенаправление трафика на «живые» экземпляры.
  3. Запретить прямые вызовы между микросервисами.
Чтобы избежать типовых проблем и упростить разработку, рекомендую взять на вооружение подходы по повышению отказоустойчивости:

  1. Circuit Breaker
  2. Tolerant Reader
  3. Embracing Failure
  4. The Timeout AntiPattern
  5. Graceful Degradation
  6. Use versioning only as a last resort

Этап №3. Микросервисы


3.1 Характеристики


Микросервисы ничего не знают о существовании друг друга: работают со своей базой данных, API и сообщениями в очереди. Каждый микросервис решает только одну бизнес-задачу и старается делать это максимально эффективно, за счет выбора технологий, стратегии масштабирования.



Становится заметна главная черта хорошей архитектуры: сложность системы растет линейно с увеличением количества микросервисов.





Погружение в контекст:


  1. Pattern: Microservice Architecture
  2. Microsoft Dev School — Микросервисы, чистый PaaS и конкурс мисс Россия
  3. Microservices, a definition of this new architectural term

3.2 Проблемы


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


  1. Среди сотен микросервисов и разных API бизнес не может понять, какие инструменты есть у него в руках. Пазл складывается в стройные картинки только у энтерпрайз архитекторов, а их, как известно, очень мало на Земле.
  2. Бизнес хочет увидеть лес за деревьями, чтобы понимать, какие есть детали и как из них можно собирать новые продукты, не прибегая к разработке.
  3. Сборку новых продуктов из существующих кубиков, хочется совместить с продуктовой разработкой, чтобы Владелец продукта сам ориентировался, какие ему доступны ресурсы.

3.3 Как перейти на следующий этап


Многие компании не идут дальше, потому что на текущем этапе бизнес-задачи могут решаться уже достаточно быстро и эффективно. Тем, кто решают двигаться дальше:


  1. Изучите концепцию Citizen Integrator. Для наглядного примера заведите себе пару процессов в Zapier.
  2. Опишите микросервисы в виде блоков, решающих бизнес-задачу, и сделайте из них конструктор. Это можно сделать: 1) на готовых инструментах, 2) обернуть BPM-движки типа Camunda, 3) написать всё самим с нуля. Все три подхода жизнеспособны. Выбор подхода зависит от стратегии вашей компании и наличии у вас ИТ-архитекторов и хороших программистов.





Погружение в контекст:


  1. The Microservices Workflow Automation Cheat Sheet
  2. Clouds, iPaaS, Citizen Integrator and Why India’s Outsourcing Is Losing Money

Этап №4. Оркестратор бизнес-сервисов


4.1 Характеристики


Оркестратор бизнес-сервисов обычно является визуальной платформой, где соединяются сервисы, выставляются триггеры и условия ветвления, контролируются все потоки данных: реализована трассировка запросов, логирование событий, автомасштабирование по условиям. Сам оркестратор ничего не знает о специфике бизнес-процессов, которые на нем крутятся.



На этом этапе можете решить задачу создания продукта в визуальном редакторе. Если нужных «квадратиков» не хватает, то программисты создают микросервис, учитывая правила описания сервиса для оркестратора, публикуют API и «кубик» появляется в визуальном редакторе, готовый соединяться с другими участниками бизнес-задачи.





4.2 Проблемы


  1. Создание, внедрение и развитие оркестратора бизнес-процессов является дорогим удовольствием.
  2. Если ослабить архитектурный контроль, оркестратор может превратиться в узкое место систем, созданных на нем.
  3. Чем больше систем создается на оркестраторе, тем больше бизнес зависит от этого решения. В целом, это начинает напоминать проблемы монолита.

4.3 Как перейти на следующий этап


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



Заключение


Эти четыре этапа показывают, как мне кажется, естественный ход вещей:


  1. Вначале приложение небольшое и решает одну бизнес-задачу. Со временем в него добавляют много всего и оно превращается в неповоротливый монолит.
  2. При первой попытке разделить монолит многие команды не готовы к возрастающей сложности. Монолит делится на много микросервисов, но из-за большого количество взаимосвязей получается тот же монолит, только с новыми проблемами: простейшие задачи типа трейсинга запроса или мониторинга инфраструктуры становятся вызовом для команды разработки.
  3. Когда сложности решаются, получается стройная и масштабируемая архитектура. Добавление новых микросервисов линейно повышает сложность.
  4. На последнем этапе приходит бизнес и резонно говорит, что раз есть готовые решения бизнес-задач, то давайте делать новые продукты без разработки. Будем соединять готовые независимые блоки в новые бизнес-процессы через оркестратор.