Микросервисы: когда и зачем
В последнее время я часто читаю статьи о том, как использовать микросервисы, но редко встречаю ситуации, где принятие решения об их использовании имеет правильное обоснование. В этой статье я попробую показать, как должно приниматься такое решение - шаг за шагом для каждого домена. Важно понимать, что решение принимается по каждому домену в отдельности, в зависимости от его особенностей, его связей и команды, которая его реализует.
Постарался создать простой чек лист для принятия решения о выделения в микросервис конкретного домена.
Вопрос изоляции доменов (программной части и данных). Изоляция может быть реализована в виде микросервисов, 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-систем
Микросервисы в представлении среднего разработчика, и как всё на самом деле
Композитная архитектура: возвращение к монолиту на новом уровне
Комментарии (8)
AlexunKo
26.01.2025 18:05Реально не понимаю, когда говорят микросервисы - это просто про отдельные сервисы или что-то еще? Хочется определить о чем мы говорим. В этом понятии столько шума что хочется его оставить однажды в покое.
Dhwtj Автор
26.01.2025 18:05Микросервисы по простому это распределенная архитектура, когда отдельно от остального один или несколько экземпляров сервиса и его данные тоже отдельно.
И вот теперь сервис взаимодействует с остальной частью по сети.
Здравствуйте, сетевые задержки
Здравствуйте, сетевые ошибки
Здравствуйте, очереди и повторы
Зато можно отключить сервис, заменить и включить, использовать несколько версий одновременно
Зато можно задать потолок ОЗУ на каждый запрос, чтобы вся система не рухнула при котором запросе
Зато можно вкатить новый сервис без сложного интеграционного тестирования (но это можно и на монолите)
И вот теперь база данных отдельно
Здравствуйте, сложные и долгие изменения в нескольких БД сразу, ака распределенные транзакции.
Здравствуйте, некосистентность данных чтобы хоть как-то это ускорить
dersoverflow
на сегодняшний день, микросервисы - некогда и незачем!
как я уже здесь цитировал:
https://www.linkedin.com/pulse/past-constraints-you-never-thought-sergey-derevyago-ien3f
Dhwtj Автор
Ну вы статью то мою прочитали?
Я же написал, что требование по высокой производительности / масштабируемости реализуется множеством способов. И масштабируемость становится доводом за микросервисы только если вы уже исчерпали остальные возможности.
Ок, я добавлю туда вертикальное масштабирование.
c0r3dump
Сервер хорош, конечно, но предположу, что покупать такой вот сразу себе мало кто решится - нужно дорасти по нагрузке и с микросервисами проще её наращивать постепенно. Да ещё часто не хочется вовсе владеть никаким железом тк нужно же его обслуживать, резервирование учесть, держать запасные части, а то умрёт рейд-контроллер - что будем делать? Тоже горячая замена есть? Да и географически в разных дата-центрах тоже имеет смысл размещаться, а так с одним большим сервером может всякое произойти, например его могут забрать просто как вещдок и увезти, и для этого даже не нужно доказать вину - достаточно наличия дела.
dersoverflow
а зачем его покупать сразу? сервер может расти за Прибылью.
в общем, парадигма ИЗМЕНИЛАСЬ! еще лет 10 назад каждая первая статья о Масштабировании вполне резонно отмечала, что Вертикальное Масштабирование вас НЕ вывезет...
но!
на сегодняшний день ваш Бизнес сдохнет раньше, чем вы исчерпаете возможности одного Хорошего Сервера.
ЗЫ расчлененка - дополнительная Сложность! зачем себе портить Жизнь, если можно не портить?
Dhwtj Автор
Кстати, да. На момент написания книг по микросервисам, в которых масштабируемость как главная цель, мощности одного сервера были значительно слабее. То есть рекомендации устарели.
Но остальные плюсы не потеряли актуальность, как и минусы.
Dhwtj Автор
Обычно, несколько серверов одновременно. Но их сложнее синхронизировать