В марте 2014 года Мартин Фаулер и Джеймс Льюис опубликовали статью «Microservices», где собрали девять признаков нового архитектурного стиля. Термин уже год гуляет по конференциям, но именно эта работа дала ему рамку. Разберём характеристики Фаулера и посмотрим, что они дают командам, которые строят корпоративные и государственные системы в России.

Девять признаков по Фаулеру

Фаулер не даёт строгого определения – он описывает набор общих свойств. Кратко по пунктам:

  • Компонентизация через сервисы. Компонент – отдельный процесс, а не библиотека внутри монолита. Заменить или развернуть его можно независимо.
  • Организация вокруг бизнес-возможностей. Команда отвечает за продукт целиком – от базы данных до интерфейса, а не за «слой».
  • Продукты, а не проекты. Команда живёт с сервисом весь его жизненный цикл по принципу «you build it, you run it».
  • Умные конечные точки, тупые каналы. Логика – в сервисах, а шина передаёт сообщения и не знает о бизнес-правилах. Это прямой ответ на тяжёлые ESB и WS-* стек.
  • Децентрализованное управление. Каждый сервис волен выбирать свой язык и инструменты.
  • Децентрализованные данные. У каждого сервиса своя база. Общей схемы на всех нет.
  • Автоматизация инфраструктуры. Непрерывная поставка и развёртывание – обязательное условие, иначе количество сервисов парализует эксплуатацию.
  • Проектирование под отказ. Сервис обязан переживать недоступность соседей.
  • Эволюционный дизайн. Границы сервисов меняются по мере того, как меняется понимание предметной области.

Что это даёт корпоративным и государственным системам

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

Децентрализация данных при этом упирается в требования закона. ФЗ-242 закрепил локализацию персональных данных граждан РФ на территории страны – норма вступит в силу, и каждый сервис со своим хранилищем придётся проверять отдельно. Мы разбирали методику в материале про аудит размещения данных. С микросервисами проверка дробится по границам сервисов, и это скорее плюс: проще локализовать ровно те хранилища, где лежат ПДн, не трогая остальные.

Цена входа

Фаулер честно предупреждает: микросервисы – это «налог на распределённость». Сетевые вызовы ненадёжны, согласованность данных становится итоговой, а отладку приходится вести по логам нескольких процессов. Без зрелой автоматизации развёртывания этот стиль не взлетает. Инфраструктура должна поднимать и гасить сервисы без ручных операций – отсюда интерес к контейнерам и оркестраторам. Amazon на прошлой неделе анонсировал сервис управления контейнерами ECS, и это часть того же сдвига: индустрия достраивает инструменты под архитектуру, которую Фаулер только что описал.

Для госзаказчика есть и организационная цена. Принцип «команда владеет продуктом» плохо ложится на проектную модель с приёмкой по этапам и сменой подрядчика. Прежде чем дробить систему, оцените, готов ли заказчик к продуктовому циклу сопровождения.

Вывод

Девять характеристик Фаулера – не чек-лист «как правильно», а описание компромиссов. Микросервисы окупаются там, где нужна частая независимая поставка и понятны границы предметной области, и проигрывают монолиту на малых системах с редкими релизами. Выбор между ними – это решение, которое определяет весь дальнейший цикл разработки бизнес-систем и стоимость их сопровождения.