Микросервисы: когда и зачем
В последнее время я часто читаю статьи о том, как использовать микросервисы, но редко встречаю ситуации, где принятие решения об их использовании имеет правильное обоснование. В этой статье я попробую показать, как должно приниматься такое решение - шаг за шагом для каждого домена. Важно понимать, что решение принимается по каждому домену в отдельности, в зависимости от его особенностей, его связей и команды, которая его реализует.
Постарался создать простой чек лист для принятия решения о выделения в микросервис конкретного домена.
Вопрос изоляции доменов (программной части и данных). Изоляция может быть реализована в виде микросервисов, service-based архитектуры, CQRS и других подходов. Выбор подхода зависит от логики, оценки положительных и отрицательных сторон изоляции по отношению к конкретному домену. К одному домену может быть применен один подход, к другому - другой, в зависимости от содержания домена и от способа взаимодействия команд ответственных за домены.
Статья - идейное продолжение моей статьи Борьба со сложностью
Доводы за изоляцию и альтернативы
Основные технологические доводы за изоляцию:
Масштабирование: для обеспечения масштабирования есть множество иных, более дешевых способов: (шардирование, репликация или выделение аналитической части в CQRS). И только если они не помогли, то можно прибегнуть к паттерну микросервисов для обеспечения требований по масштабируемости.
Безопасность: для таких доменов, как платежный модуль, изоляция в виде микросервиса является необходимостью ввиду требований к безопасности данных. Альтернативных подходов практически нет.
Мультитехнологичность: альтернатив распределенным архитектурам (микросервисам или иным) чтобы обеспечить это требование почти что и нет. Но такая потребность возникает не так уж часто. Впрочем, если основная часть приложения написана на скриптовых языках (Python или PHP), а остальную часть для ускорения быстродействия необходимо переписать на Go, C# или Rust, то изоляция этой части кода будет хорошей идеей. Наличие или отсутствие требований изоляции данных определит будет ли это микросервис или иная архитектура, к примеру service-based architecture.
Организационные доводы за:
Микросервисы эффективны для Agile, когда количество команд превышает 5-10, и взаимодействие между командами становится затруднительным. При численности команды около 10 человек (по правилу двух пицц) и общей численности 50-100 человек на продукт имеет смысл изолировать практически каждый домен.
При росте сложности требований, кодовой базы и поведения программы изоляция уменьшает риск веерного изменения в зависимых модулях - усложнения разработки и тестирования. Да, через изоляцию доменов DDD на уровне логики можно добиться положительного эффекта, но для крупных программ может оказаться предпочтительней кардинальная изоляция зависимостей, предоставляемая микросервисами. В книге "Чистая архитектура" показано, насколько драматично может быть падение производительности разработки с ростом кодовой базы и усложнением требований, если не гарантировать изоляцию модулей.
Против
Технологические доводы против изоляции:
Изоляция баз данных приводит к проблемам с распределенными транзакциями:
Потеря консистентности данных
Для устранения этого необходимо применять сложные техники (например, паттерн Saga)
Сетевая изоляция вызывает:
Увеличение длительности запросов по сети
Ненадежность из-за вероятности сетевых ошибок
Для устранения этого необходимо примерять техники повторов и реакции на сетевые ошибки. А против высоких задержек по сети поможет разве что расположить их близко по сети, далее в одной ноде, далее и вовсе объединить.
Организационные доводы против:
Если вы неверно определили границу домена или она изменилась вместе с бизнес процессом перенести эту границу будет уже значительно сложнее. Особенно не рекомендуется начинать с микросервисов или выбирать их "навырост". Monolith first!
При использовании Waterfall модели с вертикальным взаимодействием между командами или при небольшом количестве команд, когда взаимодействие еще не очень сложное, микросервисы не являются лучшим вариантом решения. При наличии статических анализаторов зависимостей и при надзоре техлида за зависимостями модульный монолит станет отличным решением! Для быстрого развертывания изменений можно посмотреть такие решения как Blue-Green Deployment, Feature Flags и т.д.
Микросервисы дают существенную нагрузку на DevOps и падение средней производительности в условных фичах на человека в день. Падение раза в 2-3.
Если одна команда отвечает за несколько доменов, можно попробовать макросервисы - несколько доменов в одном сервисе с одним кодом и базой. Границей макросервиса станет граница ответственности команды
Решение
И вот, когда вы взвесили по этому домену все за и против его изоляции, решили изолировать только программную часть или вместе с данными, выбрали вариант отделения, тогда режте, но потихоньку.
Изоляция доменов в виде модульного монолита, микросервисов, CQRS, EDA или Service Based Architecture — это мощный инструмент для обеспечения масштабируемости, безопасности и гибкости архитектуры, но её применение требует взвешенного подхода с учётом организационных и технических особенностей проекта.
Изначально хотел написать большую статью, но все достоинства и недостатки микросервисов и распределенной архитектуры уже разобраны до костей.
Интересные статьи на хабре про микросервисы из моих закладок
Как перейти от монолита к микросервисам без сложностей и рисков? Четыре проверенных паттерна
Проектирование отказоустойчивости IT-систем
Микросервисы в представлении среднего разработчика, и как всё на самом деле
Композитная архитектура: возвращение к монолиту на новом уровне
Заметки об основах программной архитектуры
