В последние месяцы в англоязычных инженерных блогах всё чаще мелькает слово «microservices». В марте Джеймс Льюис и Мартин Фаулер выпустили развёрнутую заметку, которая закрепила термин. Разберём, что за ним стоит и стоит ли корпоративному заказчику присматриваться к подходу уже сейчас.
Что такое микросервис
Микросервисный подход – это способ строить приложение как набор небольших самостоятельных сервисов. Каждый сервис отвечает за одну бизнес-функцию, разворачивается отдельно и общается с соседями по сети через простые протоколы, чаще всего HTTP и обычный REST.
Ключевое отличие от привычной нам трёхзвенки – не размер, а границы. Монолит мы собираем в один артефакт и катим целиком: ради одной правки в расчёте отпуска пересобирается и тестируется всё приложение. Микросервис живёт своим циклом. Команда меняет логику начисления, выкатывает только этот сервис, остальная система продолжает работать.
Это не магия и не бесплатно. Вместо вызовов внутри одного процесса вы получаете сетевые вызовы со всеми их отказами и задержками. Поэтому подход оправдан там, где цена независимой поставки выше цены распределённости.
Чем это отличается от SOA и ESB
Резонный вопрос: мы это уже проходили под вывеской SOA. Отчасти да. Микросервисы наследуют идею сервисной декомпозиции, но расходятся в деталях интеграции.
Классическая SOA тяготеет к тяжёлой шине (ESB) с маршрутизацией, оркестрацией и преобразованием форматов внутри самой шины. Микросервисный стиль выносит ум на концы: умные сервисы, простые каналы передачи. О том, почему централизованная шина не всегда выигрывает у прямых соединений, мы подробно писали в разборе ESB против point-to-point – многие аргументы оттуда применимы и здесь.
Второй важный момент – данные. В микросервисах каждый сервис владеет своей базой и никто не лезет в чужую схему напрямую. Это снимает главный тормоз монолита, общую базу, в которую вцепились все модули. Но это же требует пересмотра привычки к единой реляционной СУБД на всё: для отдельных сервисов уместнее специализированные хранилища, в том числе NoSQL.
Кому это нужно прямо сейчас
Честный ответ для большинства корпоративных и государственных систем – пока присматриваться, а не переписывать. Подход требует зрелой эксплуатации: автоматического развёртывания, мониторинга десятков процессов, дисциплины версионирования контрактов. Без этого вы меняете один большой понятный артефакт на россыпь мелких, за которыми некому уследить.
Базу под такую эксплуатацию мы уже обсуждали, когда разбирали приход Docker и практик DevOps. Изоляция сервиса в контейнере и воспроизводимая сборка – ровно тот фундамент, без которого дробить монолит преждевременно.
Где подход оправдан уже в 2014 году: системы с разной нагрузкой по модулям (личный кабинет живёт иначе, чем ночной расчётный движок), долгие продукты с несколькими командами, интеграционные контуры, где части развиваются разными темпами и подрядчиками.
Границы сервисов разумнее проектировать от бизнес-функций и реальной нагрузки, а не от моды на архитектуру. Иногда верный ответ – аккуратный модульный монолит, который позже можно резать по живому.
Вывод
Микросервисы – не революция, а очередной виток сервисной декомпозиции с акцентом на независимую поставку и владение данными. Термин новый, идеи знакомые. Внедрять стоит там, где у вас уже есть автоматизация эксплуатации и реальная боль от связанности монолита. В остальных случаях достаточно держать руку на пульсе и проектировать чистые границы – чтобы перейти к сервисам, когда они действительно понадобятся.
