Монолит и микросервисы

01Три формы: монолит, модульный монолит, микросервисы

Представьте ресторан. Монолит — одна кухня, где любой повар может схватить любой продукт с любой полки: поначалу быстро, потом хаотично. Модульный монолит — та же кухня, но разделённая на станции (гриль, кондитерская, салаты), у каждой свои полки и стойка, через которую передают заказы. Микросервисы — отдельные рестораны, которые отправляют друг другу заказы курьером: каждый может открыться, закрыться или уйти на ремонт независимо, но теперь каждая передача занимает время и может потеряться. В терминах софта монолит — это одна кодовая база, один тип процесса и обычно одна база данных. Модульный монолит сохраняет один деплой, но делит код на модули с публичными интерфейсами, и каждый модуль владеет своими таблицами. Микросервисы — независимо деплоящиеся процессы, у каждого своё хранилище данных, и общаются они через HTTP, gRPC или сообщения.

• Монолит: проще всего строить, тестировать, деплоить и отлаживать; риск — «большой ком грязи».
• Модульный монолит: один деплой, принудительные границы, вызовы внутри процесса, одна транзакция, когда она нужна.
• Микросервисы: независимые деплои и масштабирование каждого сервиса; цена — сложность распределённых систем.

02Реальная цена микросервисов

Микросервисы переносят сложность из кода в сеть. Вызов функции, который никогда не падал, становится запросом, который может упасть по таймауту, прийти дважды или выполниться так, что вы об этом не узнаете. Одна транзакция в базе превращается в распределённый процесс, которому нужны саги, outbox'ы и идемпотентность. Владение данными становится строгим: сервис заказов не может читать таблицу клиентов, значит, нужны API, события или локальные копии — а копии могут устаревать. Для отладки нужны распределённый трейсинг, связанные логи и дашборды для каждого сервиса, иначе одно медленное оформление заказа превращается в детективную историю. Для деплоя нужны CI-пайплайны, версионированные контракты, service discovery и обычно оркестратор. И каждому сервису нужны свой мониторинг, алерты, секреты и обновления. Ничего из этого не невозможно, но это постоянный налог, который вы платите каждую неделю.

• Распределённые транзакции: нет общей ACID-транзакции между сервисами.
• Сбои сети: таймауты, повторы, частичные отказы, каскадные падения.
• Владение данными: никаких join'ов между сервисами; дублированные данные с eventual consistency.
• Observability и стоимость: трейсинг, больше инфраструктуры, больше зона ответственности дежурных.

03Поиск границ через bounded context'ы

Самое сложное в любом разделении — где резать. Domain-Driven Design даёт практичный инструмент: bounded context — область бизнеса, где слова имеют одно точное значение. «Товар» в каталоге — это описание с фотографиями; на складе — это остатки; в биллинге — строка с ценой. Каждый контекст получает свою модель и свой модуль. У хороших границ высокая связность внутри (что меняется вместе, живёт вместе) и слабое зацепление снаружи (узкий стабильный интерфейс). Полезный тест: может ли команда неделю менять этот модуль, ни с кем не согласовываясь? Если нет — граница проведена неправильно. Режьте по бизнес-возможностям (заказы, платежи, лояльность), а не по техническим слоям («сервис базы данных» или «сервис валидации»): это только порождает болтливые и хрупкие зависимости.

1// eslint.config.mjs: modules may import each other only through a public index
2export default [
3  {
4    files: ["src/modules/**/*.ts"],
5    rules: {
6      "no-restricted-imports": ["error", {
7        patterns: [{
8          group: ["@/modules/*/internal/*", "@/modules/*/db/*"],
9          message: "Use the other module's public index.ts, not its internals.",
10        }],
11      }],
12    },
13  },
14];

04Как построить модульный монолит, который останется модульным

Границы, которые существуют только на диаграмме, размываются за несколько месяцев. Закрепляйте их в коде. Дайте каждому модулю папку с публичной точкой входа (сервисы, DTO, события), а всё остальное держите внутренним. Пусть каждый модуль владеет своими таблицами, и запретите другим модулям обращаться к ним напрямую; чтение между модулями идёт через сервис модуля-владельца. Используйте доменные события внутри процесса для побочных эффектов («заказ оплачен» начисляет баллы лояльности), чтобы модули не вызывали друг друга длинными цепочками. Добавьте правила линтера или архитектурные тесты, которые роняют сборку при запрещённых импортах. Во фреймворках с системой модулей, например в NestJS, экспортируйте только то, что можно использовать другим модулям. Награда: когда одному модулю действительно понадобится отдельное масштабирование или деплой, у вас уже есть его интерфейс, его данные и его события, и извлечение становится проектом на недели, а не переписыванием.

05Миграция по паттерну strangler fig

Когда существующий монолит нужно разделить, никогда не пытайтесь переписать всё разом: это замораживает фичи на месяцы и обычно проваливается. Используйте паттерн strangler fig, названный в честь фикуса-душителя, который медленно обрастает вокруг дерева. Поставьте перед монолитом слой маршрутизации (reverse proxy или API gateway). Выберите одну хорошо очерченную возможность, постройте её как новый сервис и направьте туда только её эндпоинты, а всё остальное по-прежнему идёт в монолит. На время перехода синхронизируйте данные через события или change data capture, а затем передайте владение данными новому сервису. Повторяйте по одной возможности за раз и удаляйте старый код после каждого шага. Каждый шаг маленький, обратимый и готовый к выкатке, так что бизнес продолжает двигаться, пока архитектура меняется под ним.

• Начинайте с возможности, у которой ясное владение данными и мало входящих зависимостей.
• Запускайте старый и новый пути параллельно и сравнивайте результаты, прежде чем переключать трафик.
• Измеряйте: если новый сервис не упрощает деплой или масштабирование — остановитесь.

06Как выбрать: размер команды, предметная область и потребности в масштабировании

Закон Конвея гласит, что системы повторяют структуру коммуникаций команд, которые их строят. Одна-две небольшие команды почти ничего не выигрывают от микросервисов — они и так легко договариваются, — а вот эксплуатационную цену платят полностью. Микросервисы начинают окупаться, когда несколько автономных команд блокируют друг друга на общем релизе, когда у частей системы очень разные требования к масштабированию или надёжности (видеоэнкодер против админки) или когда требования регуляторов диктуют жёсткую изоляцию. Сам по себе трафик редко бывает причиной: хорошо построенный монолит горизонтально масштабируется за load balancer'ом до очень больших нагрузок. Разумный вариант по умолчанию для большинства компаний — начать с модульного монолита, вкладываться в границы, тесты и observability и выделять сервис только тогда, когда это оправдывает конкретная, измеренная боль.

07Связанность, которую не видно: временная, по данным и по деплою

Правила импортов ловят связанность в коде, но успех разделения решают три более тихих вида. Временная связанность: сервис A может завершить запрос, только пока B работает, потому что вызывает его синхронно. Тогда доступность перемножается: три сервиса по 99.9 процента в цепочке дают для всего потока примерно 99.7 процента. Связанность по данным: два модуля читают или пишут одни и те же таблицы, поэтому изменение схемы в одном ломает другой без единого импорта между ними. Связанность по деплою: изменение требует согласованных релизов, потому что контракт поменялся без обратной совместимости. Измерьте всё это до разделения. Посмотрите, каких таблиц касается каждый модуль, на граф вызовов из трейсинга и на то, какие папки меняются в одних и тех же коммитах за несколько месяцев (change coupling по истории Git). Модули, которые постоянно меняются вместе, должны жить вместе, что бы ни говорила диаграмма.

• Доступность цепочки: перемножьте SLO каждого синхронного шага.
• Общие таблицы нарушают границу даже при чистых импортах.
• Анализ совместных изменений в Git дёшево показывает реальную связанность.

08Контракты между сервисами: версионирование и consumer-driven тесты

Как только граница становится сетевой, её интерфейс превращается в опубликованный контракт, и независимый деплой зависит от его стабильности. Следуйте правилу tolerant reader: потребители игнорируют незнакомые поля, а производители только добавляют необязательные. Ломающие изменения идут через expand and contract: добавьте новое поле или эндпоинт, переведите потребителей, затем удалите старое, когда его использование упадёт до нуля. Consumer-driven contract тесты (например, с Pact) позволяют каждому потребителю зафиксировать запросы и поля ответа, на которые он опирается; CI провайдера проигрывает эти ожидания и падает до того, как ломающее изменение уйдёт в прод, без подъёма всей системы. Это заменяет медленные и нестабильные end-to-end окружения в роли основной страховки. Так же версионируйте события и закрепите за каждым API письменно указанного владельца, чтобы вопросам было куда идти.

09Механика выделения: branch by abstraction и anti-corruption layer

Внутри монолита branch by abstraction готовит модуль к выделению без долгоживущей ветки. Введите интерфейс для этой возможности, проведите через него всех вызывающих, затем добавьте вторую реализацию, которая ходит в новый сервис и включается feature flag по тенанту или по проценту. Двигайтесь постепенно и держите in-process реализацию как fallback, пока удалённая не докажет свою надёжность. Если у нового сервиса модель чище, чем у legacy-кода, поставьте между ними anti-corruption layer: переводчик, который отображает старые понятия на новые, чтобы legacy-названия и причуды не протекали в новый дизайн. Данные переезжают поэтапно: сначала новый сервис читает реплицированную копию, затем становится писателем, а монолит читает из него, и в конце старые таблицы удаляются.

1// Branch by abstraction: callers depend on the interface, not the location
2export interface PricingPort {
3  quote(cartId: string): Promise<Quote>;
4}
5 
6export function pricingFor(tenantId: string, deps: Deps): PricingPort {
7  return deps.flags.isOn("pricing-service", tenantId)
8    ? new RemotePricing(deps.http)      // new service, behind timeouts and retries
9    : new InProcessPricing(deps.db);    // existing module, kept as fallback
10}

10Топология команд и inverse Conway manoeuvre

Если системы повторяют структуру общения команд, можно спроектировать организацию так, чтобы получить нужную архитектуру: это inverse Conway manoeuvre. Дайте каждой stream-aligned команде сквозное владение одним или несколькими bounded context, включая данные, деплои и on-call. Платформенная команда даёт «мощёные дороги» (шаблоны CI, observability, scaffolding сервисов), чтобы каждый новый сервис не изобретал их заново. Следите за когнитивной нагрузкой: команда, владеющая большим числом сервисов, чем способна удержать в голове, начнёт срезать углы во всех. Грубая проверка — отношение деплоимых единиц к инженерам: когда оно превышает единицу, эксплуатация начинает вытеснять работу над фичами. Перерисовывайте границы при изменении структуры команд: сервис, которым владеют три команды, становится узким местом координации, а бесхозный тихо гниёт.