Крупная корпоративная система годами растёт как единый монолит: один процесс, одна база, один релиз. Сначала это удобно. Через три-четыре года любая правка задевает половину кода, релиз превращается в ночное дежурство, а новый разработчик месяц разбирается, где что лежит. На горизонте всё чаще звучит другой подход – разбить монолит на набор небольших самостоятельных сервисов, каждый из которых отвечает за свою бизнес-функцию. Это развитие идей SOA, но с упором на мелкую гранулярность и независимый выпуск.
Где проходят границы
Главный вопрос декомпозиции – не «на сколько частей резать», а «по каким швам». Резать стоит по бизнес-возможностям, а не по техническим слоям. Расчёт тарифов, реестр контрагентов, документооборот, начисления – каждый из этих блоков имеет свою логику, свой темп изменений и часто свою команду. Удачная граница – та, где между двумя кусками проходит минимум вызовов и где у каждого куска своя зона данных.
Отсюда жёсткое правило: один сервис – одна база. Если два сервиса лезут в одну таблицу, вы не разделили систему, а только размазали монолит по сети. Сервисы общаются через явные контракты – REST поверх HTTP или обмен сообщениями через очередь. Контракт фиксируется и версионируется отдельно от внутренней реализации, чтобы соседний сервис можно было переписать целиком, не трогая остальных.
Что это даёт корпоративной и государственной системе
Выгода считается в темпе изменений. Команда расчётов выкатывает свою правку, не дожидаясь команды отчётности. Нагруженный модуль масштабируется отдельно – добавляете экземпляры только там, где упёрлись в потолок, а не клонируете весь монолит ради одной горячей функции. Отказ одного сервиса локализуется: реестр недоступен, но приём заявлений продолжает работать.
Для госсектора это особенно заметно на интеграционных узлах. В системах межведомственного электронного документооборота разные подсистемы живут по разным регламентам и срокам ввода. Отдельный сервис под каждую внешнюю интеграцию переживает изменение чужого формата, не ломая внутренний контур. К декомпозиции монолита на самостоятельные сервисы обычно приходят тогда, когда заказчик упирается в потолок монолита и не может выпускать изменения в нужном темпе.
Цена входа
Распределённая система – это не бесплатно. Появляется сетевая граница со своими таймаутами и сбоями, транзакция на несколько сервисов перестаёт быть простой, а отладка требует сквозной трассировки запроса через половину контура. Растёт и эксплуатационная нагрузка: вместо одного процесса вы катите в продакшен десяток.
Здесь критична зрелая инфраструктура развёртывания. Каждый сервис должен подниматься одинаково и предсказуемо, в изолированном окружении. Поэтому интерес к контейнерам и микросервисам идёт рука об руку – недавний перевод Docker в open source делает упаковку и доставку отдельного сервиса дешёвой операцией, а не отдельным проектом. О том, чем такая изоляция отличается от полноценной виртуализации, мы писали в разборе контейнеров против виртуальных машин.
Вывод
Дробить монолит ради моды не нужно. Декомпозиция оправдана там, где разные части системы меняются с разной скоростью, требуют независимого масштабирования или принадлежат разным командам. Начните с одного-двух швов, вынесите самый болезненный модуль, отладьте контракты и развёртывание и только потом продолжайте. Микросервисы пока на горизонте, но инструменты, чтобы идти к ним без героизма, уже появились.
