Распределённый монолит

Что делает систему distributed monolith

Distributed monolith — набор сервисов, выглядящих независимыми, но тесно связанных в рантайме и во время деплоя. Он объединяет худшие свойства обеих архитектур:

• От монолита: изменение одного сервиса требует изменений и скоординированных деплоев в нескольких сервисах; кодовую базу сложно понять целиком, потому что зацепление неявное (сетевые вызовы и общая схема, а не видимые импорты).
• От распределённых систем: сетевая задержка на каждом межсервисном вызове, режимы частичного отказа сложнее для отладки, чем исключения уровня процесса, и операционные накладные расходы нескольких деплойных юнитов.

Диагностический вопрос — не «сколько у нас сервисов?» — а «может ли каждый сервис деплоиться и отказывать независимо?». Если нет — distributed monolith, сколько бы сервисов ни показывала архитектурная диаграмма.

Три структурных симптома определяют паттерн:

1. Lockstep-деплой. Сервисы должны деплоиться вместе или в определённой последовательности, потому что разделяют схему данных или API-контракт без версионирования. Изменение таблицы orders требует координации OrderService, BillingService и InventoryService в одном деплойном окне.

2. Болтливые синхронные цепочки вызовов. Один клиентский запрос разворачивается в N синхронных хопов через сервисы, не способные ответить, пока не ответят нижестоящие. Каждый хоп добавляет задержку и вероятность отказа. Под нагрузкой медленный сервис в конце цепочки производит таймауты, каскадирующиеся вверх.

3. Shared database. Несколько сервисов читают и пишут в одни и те же таблицы через общую ORM или общий пул соединений. Никакой сервис не владеет своими данными эксклюзивно; изменения схемы затрагивают каждый сервис, обращающийся к изменённой таблице.

Проблема dual-write

Shared database производит структурный дефект, проявляющийся как несогласованность данных: dual-write problem.

Рассмотрим создание BillingService записи о списании и обновление статуса заказа последовательно:

1. INSERT INTO charges (order_id, amount) VALUES (123, 450.00)
2. UPDATE orders SET status = 'charged' WHERE id = 123

Оба оператора успешно выполняются локально. Но в orders также пишет OrderService. Если OrderService конкурентно пишет status = 'cancelled' после шага 1, но до шага 2, заказ оказывается в состоянии charged, хотя был отменён. BillingService и OrderService каждый написал своё локальное представление истины в одну и ту же таблицу без владельца, принудительно соблюдающего согласованность.

Проблему dual-write нельзя полностью решить транзакцией, охватывающей записи обоих сервисов: такая транзакция является распределённой — она требует координатора для блокировки записей через соединения обоих сервисов одновременно. Это 2PC, который повторно вводит единственную точку отказа координатора, удержание блокировок между сервисами и зависимость доступности от всех участников (урок 09). Правильное исправление — дать каждому сервису эксклюзивное владение его таблицами, структурно исключив конкурентные записи от разных сервисов в одну запись.

Временно́е зацепление: скрытое зацепление синхронных цепочек

Temporal coupling (временно́е зацепление) — форма рантаймового зацепления, возникающего когда один сервис может завершить свою работу только при доступности другого сервиса в тот же момент. Каждый синхронный вызов сервиса создаёт temporal coupling.

В пятисервисной цепочке биллинговой платформы OrderService временно́ связан с InventoryService, BillingService и NotificationService. Если любой из них недоступен во время размещения заказа — даже ненадолго, во время деплоя или GC-паузы — вся операция размещения заказа завершается с ошибкой. Отказ сервиса уведомлений (низкий бизнес-приоритет) вызывает отказ размещения заказа (высокий бизнес-приоритет). Это инвертированный профиль риска temporal coupling: критически важная бизнес-операция падает при недоступности наименее критичного сервиса.

Temporal coupling также усложняет независимый деплой. Если OrderService должен вызывать InventoryService синхронно на каждом запросе, их нельзя тестировать независимо. Поведение OrderService при сбоях InventoryService нужно тестировать с живым InventoryService или тщательно созданными тест-дублями. На практике команды пропускают такое тестирование из-за сложности, производя характерную хрупкость distributed monolith.

Диагностика distributed monolith

Контрольный список архитектурного ревью биллинговой платформы для distributed monolith:

Изменил один сервис — нужно менять три. Если добавление поля в доменный объект Order требует изменений кода в OrderService, BillingService и InventoryService — даже если поле вводит только один из них — сервисы структурно связаны. Настоящая граница сервиса означает, что изменение поля внутреннее для кодовой базы одного сервиса.

Один запрос разворачивается в N sync-хопов. Если диаграмма последовательностей для одного пользовательского действия показывает каскад синхронных вызовов через четыре сервиса, каждый из которых должен завершиться до ответа предыдущего, сервисы — деталь реализации одного воркфлоу, а не автономные возможности.

Деплои требуют координационного треда. Если деплой BillingService требует треда в Slack для подтверждения с командой OrderService совместимости миграции общей схемы, зацепление деплоев явное. Автономные сервисы деплоятся в любое время без межкомандной координации.

Ни один сервис не может отказать изолированно. Если отключение InventoryService на обслуживание приводит к сбою размещения заказов, размещение заказов не изолировано от инвентаря. Автономные сервисы деградируют gracefully при недоступности зависимостей — они не распространяют сбой вверх.

Как исправить distributed monolith

Distributed monolith исправляется тем же подходом, что его предотвращает: декомпозиция по бизнес-возможности по швам bounded context (урок 02), принудительное соблюдение владения данными, замена болтливых синхронных цепочек асинхронным событийным взаимодействием там, где бизнес допускает eventual consistency (урок 09).

Инкрементальное исправление:

1. Определить болтливейшую синхронную цепочку. Цепочка с наибольшим числом хопов — самое срочное temporal coupling для разрыва.
2. Определить, какие вызовы блокирующие, а какие — уведомления. Отправка уведомления-подтверждения не должна блокировать транзакцию заказа. Резервирование инвентаря должно — бизнес требует знать о наличии товара до фиксации заказа.
3. Заменить уведомления событиями. OrderService публикует событие OrderPlaced; NotificationService подписывается и отправляет email асинхронно. Транзакция размещения заказа завершается без ожидания уведомлений.
4. Адресовать владение данными. Определить, какими таблицами фактически владеет каждый сервис. Перенести эксклюзивный write-доступ к владеющему сервису. Заменить весь остальной доступ API-вызовами к владеющему сервису.
5. Версионировать API, не схемы. Когда двум сервисам нужно разделить концепцию (статус заказа), они делают это через API с версионированным контрактом — не через общую таблицу, в которую оба пишут.