Паттерны распределённых систем

Условия, которые они налагают

19 апреля 2026

Распределённые системы - не архитектурный стиль, к которому стремятся ради красоты. Это решение конкретных бизнес-проблем: независимый deploy разных команд, изолированное масштабирование, контроль failure domains, регуляторное разделение. Выбор распределённости осознанный и принимается, когда монолит перестаёт решать задачу. После выбора дороги назад почти нет: эксплуатация накладывает жёсткие условия - ненадёжная сеть, eventual consistency, observability как обязательное требование. Паттерны - ответы на эти условия, не украшения.

Почему распределённые системы: осознанный выбор, не дефолт Условия, которые распределённость накладывает Декомпозиция: где проводить границы Стили коммуникации Data management: consistency модели SAGA: транзакции через границы сервисов Transactional messaging: надёжная доставка событий CQRS и Event Sourcing - когда действительно нужно API Gateway и External API Service discovery и маршрутизация Reliability patterns: обязательные условия эксплуатации Observability: не опция, а условие работы Deployment и operational complexity Частые антипаттерны Источники и смежные статьи

Почему распределённые системы: осознанный выбор, не дефолт

Распространённая ошибка - начинать проект с микросервисов потому что «так делают». Cargo cult. Распределённость оправдана, когда решает конкретную проблему, которую монолит не может решить.

Что оправдывает переход.

Независимый deploy команд. Организация выросла до 40-50+ инженеров, несколько команд пишут в один артефакт, релиз-цикл стал узким местом. Team Topologies требует автономии Stream-aligned команд в доставке. Распределение даёт deployment boundary, совпадающий с team boundary.

Нюанс: это не значит, что монолит стал legacy и его можно не развивать. Монолит остаётся core-артефактом для части команд; за его CI/CD, deployment SLA, временем сборки, качеством тестов нужно постоянно следить и достигать нужных показателей. Выносить стоит то, что действительно хорошо отделимо - по доменам, командам, профилю изменений. Остальное продолжает жить в монолите и должно иметь здоровый pipeline, а не деградировать.

Второй нюанс: не путать deploy (доставку кода в production) и release (открытие функционала пользователям). Это разные вещи независимо от архитектуры. Со здоровым pipeline deploy происходит постоянно - изменения катятся в production несколько раз в день. Release же происходит on-demand: функционал скрыт за feature toggles и открывается по команде продукта, отдельно от deploy. Это снимает страх релиза, позволяет постепенную раскатку, A/B-тесты, и быстрый откат функционала без отката кода. Разделение deploy и release полезно и в монолите, и в распределённой системе.

Независимое масштабирование. Причину часто называют, но срабатывает она не всегда в том виде, как ожидают. Ту же кодовую базу можно запускать в разных сетапах под разные профили нагрузки - классика в Ruby-on-Rails-подобных фреймворках: общая бизнес-логика, но отдельные deployment-units для web-слоя, sidekiq (background jobs), websockets, cron. Они масштабируются независимо, хотя кодовая база одна. То же с БД: шардирование и партиционирование решают вопрос масштабирования данных без разделения на сервисы.

Не стоит путать «монолит» с «одним способом запуска под одну нагрузку». Монолит масштабируется гибче, чем часто кажется. Разделение на независимые сервисы оправдано, когда профили нагрузки радикально разные и разделение на deploy-units монолита не решает задачу: CPU-heavy (видеокодирование) vs IO-bound (поиск) vs memory-heavy (ML-inference) с разным runtime. Но большая распределённая система становится сложной сама по себе - больше компонентов, больше точек отказа, больше взаимного влияния.

Изоляция failure domains. Критичный сценарий (платежи) не должен падать из-за проблем в некритичном (рекомендации). В монолите они делят ресурсы и валят друг друга.

Нюанс: не стоит жить в иллюзии, что разделение на сервисы гарантирует работу критичной части при падении некритичной. При неправильно проведённых границах получаете каскадную деградацию: некритичный сервис падает, критичный синхронно в него ходит, критичный тоже деградирует, а отлаживать становится тяжелее - падение произошло внутри, через несколько движущихся частей. Изоляция даёт потенциал, но реализуется только при строгой дисциплине: circuit breakers, таймауты, fallback-поведение, асинхронные зависимости где возможно. Без этой дисциплины получаете distributed monolith с той же связанностью, но более сложным debug.

Важное следствие: границы бизнес-операций можно и нужно выстраивать уже в монолите - так, как будто система распределённая. Независимые бизнес-операции, явные контракты между модулями, изоляция падений на уровне бизнес-логики (одна операция не валит другую даже в рамках одного процесса). Это решает сразу две задачи. Первая - готовность к возможному выносу в отдельный сервис, когда потребуется: границы уже на месте, контракты определены, зависимости понятны. Вторая - убирает связанность прямо сейчас, не добавляя операционной сложности. Контракты синхронизированы by design (один репозиторий, один релиз), легко меняются; границы, пока они внутри одного процесса, заметно легче двигать при эволюции бизнес-модели. Когда бизнес-изменение требует пересобрать границу - в монолите это refactoring за несколько часов, в распределённой системе - миграция данных и координация команд на недели.

Регуляторные требования. PCI, PII, GDPR, медицинские данные часто проще изолировать на уровне сервиса, чем на уровне кода. Обычно разумнее вынести compliance-зону в отдельный сервис с тонким явным контрактом и сосредоточить compliance-усилия там, чем пытаться привести всю основную систему к максимальному compliance-состоянию. Отдельный сервис даёт ясные границы для аудита, отдельный security-периметр, проще доказывать соответствие регулятору.

Что распределённость не оправдывает:

Детальное сравнение с монолитом - в статье «Монолит vs Микросервисы». Ключевое: распределённость - инструмент решения бизнес-проблем, не самоцель.

Условия, которые распределённость накладывает

Выбор сделан - система распределённая. С этого момента действуют условия, которые невозможно игнорировать. Peter Deutsch в 1994 году сформулировал восемь fallacies of distributed computing - заблуждений, регулярно совершаемых инженерами, переходящими от локального к распределённому:

  1. Сеть надёжна.
  2. Latency равна нулю.
  3. Bandwidth бесконечен.
  4. Сеть безопасна.
  5. Топология не меняется.
  6. Есть один администратор.
  7. Transport cost равен нулю.
  8. Сеть гомогенна.

Каждое заблуждение - не программистская ошибка, а свойство модели. Сеть будет падать - нужны таймауты и retries. Latency будет расти - нужны асинхронные флоу и кэши. Порядок сообщений не гарантирован - нужна идемпотентность и упорядочивание. Топология меняется - нужен service discovery.

Паттерны ниже - ответы на конкретные условия. Игнорирование условия даёт production-инциденты, повторяющиеся одинаково, пока условие не учтено.

Декомпозиция: где проводить границы

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

Decompose by business capability

Границы проходят по тому, что делает бизнес как функции: приём платежей, управление подписками, формирование отчётов, отправка уведомлений. Каждая capability - кандидат в сервис или группу сервисов.

Подход ориентирован на внешний продукт: что пользователь получает от системы как отдельные функции. Работает, когда business capabilities стабильны и различимы в терминологии бизнеса. Хорошо подходит для организаций с устоявшимся доменом, где структура функций меняется редко.

Ограничение: capabilities могут быть разной зрелости. Новая capability в ранней стадии продукта часто ещё не определилась как отдельная - её границы двигаются. Выделять в отдельный сервис преждевременно - дорого: через полгода придётся перерисовывать границы.

Decompose by subdomain

Границы совпадают с bounded contexts из DDD. Каждый bounded context - один сервис или группа связанных сервисов. Доменная согласованность: один сервис = одна модель, один язык предметной области.

Это обычно самый надёжный подход. Bounded contexts отражают структуру домена, которая более стабильна, чем текущие capabilities. Когда бизнес добавляет новые capabilities, они чаще ложатся на существующие bounded contexts как расширения, чем требуют создания новых. Подробно о стратегическом DDD и bounded contexts - в статье «Domain-Driven Design».

Decompose by business capability и decompose by subdomain не противоречат: часто дают близкие границы, но subdomain даёт более доменно-обоснованные решения.

Self-contained service

Сервис работает автономно, минимально зависит от других. Если зависимость неизбежна - через асинхронные события, не синхронные вызовы. Критерий: падение соседнего сервиса не валит этот.

Self-containment достигается не декомпозицией границ, а дизайном взаимодействий. Два bounded contexts могут быть хорошо разделены концептуально, но их реализации взаимно синхронно дёргать друг друга по каждому чиху - это уже не self-contained сервисы. Нужна дисциплина: default - async, synchronous только когда действительно необходимо (user-facing read).

Полезный тест: выключить соседний сервис и посмотреть, что сломается в твоём. Если ломается много - self-containment под вопросом.

Service per team

Границы сервисов совпадают с границами ответственности команд. Каждая Stream-aligned команда владеет одним или несколькими сервисами end-to-end - от кода до production, включая on-call и SLA.

Это прямое следствие закона Конвея и Team Topologies: структура команд отражается в структуре системы, и наоборот. Если команда A владеет сервисом X, а команда B - сервисом Y, коммуникация между сервисами превращается в коммуникацию между командами. Проектировать команды и сервисы отдельно - значит создавать постоянный конфликт ownership. Подробнее в статье «Team Topologies».

На практике decompose by subdomain и service per team чаще всего дают одинаковые границы, потому что Team Topologies рекомендует Stream-aligned команды по bounded contexts.

Правило: границы только через публичный API, без shared resources

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

Это значит:

Почему это принципиально. Общий ресурс - это скрытый контракт. Команда, владеющая «своим» сервисом, на самом деле не владеет им полностью: любое изменение структуры в общем ресурсе задевает всех, кто к нему обращается. Независимый deploy становится невозможен - нужно координировать изменения. Независимое масштабирование ограничено - один ресурс становится bottleneck. Failure isolation исчезает - падение общего ресурса валит всех его клиентов.

Небольшие исключения допустимы:

Во всех остальных случаях - общение через API. Это превращает коммуникацию в явный контракт, который можно версионировать, ограничивать, защищать и изменять осознанно.

Антипаттерн: декомпозиция по техническим слоям

Сервисы «Auth», «Database», «API layer», «Business logic» - разделение по функциям в технической системе, не по бизнес-доменам. Любое бизнес-изменение задевает все сервисы, independent deploy невозможен, получается distributed monolith с максимальной операционной сложностью и минимальной выгодой.

Стили коммуникации

После разделения - вопрос как сервисы общаются. Выбор стиля определяет не только технику передачи данных, но и степень связанности между сервисами. Транспорт и семантика - разные вещи: один транспорт может нести разные виды коммуникации с разным уровнем coupling.

Синхронная коммуникация (request-response, RPI)

REST, gRPC, GraphQL. Клиент отправляет запрос, блокируется, ждёт ответа. Просто в debug - путь запроса можно проследить в обычном стектрейсе или distributed trace. Подходит для user-facing запросов с требованием немедленного ответа: запрос статуса заказа, поиск, авторизация.

Связанность: runtime + logical. Сервис A знает, что вызывает сервис B, знает интерфейс B, зависит от доступности B в момент вызова. B недоступен - A не может выполнить операцию.

Trade-off: в цепочке сервисов доступность падает как произведение. 99.9% × 99.9% × 99.9% = 99.7% - три девятки на каждом сервисе дают менее трёх девяток на сценарии. Плюс latency суммируется.

Отдельная категория - цепочки мутирующих синхронных вызовов. Это один из самых сложных и проблематичных классов в распределённых системах, потому что падение на любом шаге оставляет систему в неопределённом состоянии. Наивный подход - «просто вызовем сервисы по порядку» - ломается на первой же проблеме: платёж прошёл, но заказ не создался; заказ создан, но склад не зарезервировал товар; пользователь зарегистрирован, но маркетинг-сервис не получил данные. Debug становится мучительным: нужно восстановить, на каком шаге упало, что уже произошло, что нужно компенсировать, что оставить.

Именно поэтому критичны правильные границы. Одна бизнес-операция, требующая мутации в нескольких сервисах, - это сигнал, что границы, возможно, проведены неверно, или что операцию нужно перестроить в async-события с компенсациями (см. SAGA ниже).

Ключевое: паттерны решения здесь часто не инженерные, а бизнесовые. Архитектор не может просто «добавить try/catch» - нужно решение, которое примет бизнес:

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

Асинхронная коммуникация (messaging)

Kafka, RabbitMQ, AWS SNS/SQS, NATS. Отправитель публикует сообщение в брокер и продолжает работу, не дожидаясь обработки. Получатель читает из брокера в своём темпе.

Главное различие с синхронной: на уровне эксплуатации отправитель не зависит от доступности получателя в момент отправки. Получатель может быть временно недоступен - сообщения копятся в брокере. Нет каскадной деградации, нет суммирования latency, нет ожидания синхронного ответа.

Но асинхронность транспорта не равна независимости сервисов. Через брокер можно передавать принципиально разные виды сообщений с разной семантикой и разным уровнем связанности.

Async commands vs async events

Это два разных паттерна, часто путаемые.

Асинхронная команда - отправитель говорит получателю, что сделать. «Отправь email», «спиши средства», «зарезервируй товар». Получатель известен отправителю по имени (queue, topic). Контракт команды определён обеими сторонами: какие поля, какие значения, какие ошибки.

Связанность: logical, хотя и не runtime. Отправитель знает про получателя - знает, что этот конкретный сервис должен выполнить операцию. При изменении контракта команды менять логику нужно и там, и там. Получатель падает - команды не обрабатываются, но отправитель продолжает их класть в очередь.

Асинхронное событие - отправитель сообщает факт, который произошёл у него. «Заказ создан», «платёж получен», «пользователь зарегистрирован». Отправитель не знает, кто слушает и что будет делать. Может никого не быть. Может быть десять подписчиков с разными реакциями.

Связанность: минимальная. Отправитель не зависит от наличия или поведения подписчиков. Новый подписчик добавляется без изменений в отправителе. Отсутствие подписчиков не останавливает работу отправителя.

Практическое правило: если при смене контракта нужно знать всех, кого это затронет, и синхронизировать с ними изменение - это команда (возможно, замаскированная под событие). Если контракт расширяется без уведомления потребителей - это событие.

Сравнение связанности

Тип Runtime coupling Logical coupling
Sync request-response Высокий Высокий
Async command Низкий Высокий
Async event Низкий Низкий

Выбор стиля

Смешанный подход - норма. Одна и та же система использует все три стиля в разных местах.

Антипаттерны

Data management: consistency модели

В монолите - одна БД, ACID, strong consistency по дефолту. В распределённой системе выбор есть.

CAP theorem на практике. При network partition P обязательна - partitions случаются. Остаётся выбор C vs A:

Database per service. Каждый сервис владеет своей БД. Коммуникация - через API сервиса. Основной паттерн.

Антипаттерн: shared database. Несколько сервисов пишут в общую БД. Изменение схемы задевает всех, lock contention, нельзя менять БД без согласования. Скрытая связанность без преимуществ распределения.

SAGA: транзакции через границы сервисов

Бизнес-процесс «оформить заказ» затрагивает несколько сервисов: инвентарь, платёж, заказ, уведомление. В монолите - одна ACID-транзакция. В распределённой - несколько шагов в разных сервисах.

Почему 2PC не работает на практике. Distributed transactions технически существуют, но в production редки. Требуют доступности всех участников, держат locks, чувствительны к partitions. Низкая throughput и частые отказы.

SAGA как альтернатива. Длинный процесс разбивается на последовательность локальных транзакций. Если шаг падает - запускаются компенсирующие транзакции.

Choreography

Каждый сервис слушает события других и реагирует. Заказ создан → inventory списывает → публикует «списано» → payment списывает деньги → и т. д. Нет центрального координатора.

Orchestration

Центральный координатор знает процесс и явно управляет переходами. Вызывает сервисы по очереди, ловит ошибки, запускает компенсации.

Техники «изоляции без ACID»

SAGA не даёт isolation - другие процессы могут увидеть промежуточное состояние.

Когда SAGA оправдана. Длинные бизнес-процессы с понятной логикой компенсации. Антипаттерн - SAGA на каждый чих. Об экспоненциальной сложности - в статье «Domain-Driven Design».

Transactional messaging: надёжная доставка событий

Сервис меняет состояние в БД и хочет опубликовать событие. Проблема: операция в БД и отправка в брокер - разные действия, атомарно нельзя без distributed transactions.

Варианты без transactional messaging - все плохие:

Outbox pattern. События пишутся в той же транзакции, что и бизнес-изменения, но в таблицу outbox. Отдельный процесс читает outbox и публикует в брокер. 

BEGIN TRANSACTION;
  UPDATE orders SET status = 'paid' WHERE id = 123;
  INSERT INTO outbox (event_type, payload)
    VALUES ('OrderPaid', '{"order_id": 123, "amount": 99.00}');
COMMIT;

Публикация из outbox:

At-least-once + идемпотентность. Outbox гарантирует доставку «хотя бы раз», но публикация может повторяться (retries). Consumer должен быть идемпотентным: обработка того же события дважды даёт тот же результат. Хранение ID обработанных событий, отклонение дубликатов. Подробно в статье «Idempotency Keys».

CQRS и Event Sourcing - когда действительно нужно

Часто упоминаются вместе, но применяются отдельно. Оба мощные, оба дорогие в поддержке.

CQRS - разделение модели записи и чтения. Write-side - сложные агрегаты с инвариантами. Read-side - денормализованные проекции под конкретные запросы. Write публикует события, read слушает и обновляет проекции.

Триггер: read и write имеют радикально разные требования. Без CQRS либо read-модели размазываются по write, либо read-запросы - дорогие join-ы. Подробнее в «Domain-Driven Design».

Event Sourcing - состояние сервиса хранится как последовательность событий, не как снимок. Текущее состояние - результат проигрывания. Даёт аудит, temporal queries, replay для пересчёта проекций.

Триггер: аудит критичен (финансы, медицина, compliance), бизнес оперирует историей как сущностью, temporal queries - требование продукта.

Осторожно с cargo cult. Оба паттерна часто вводят «потому что красиво». Обслуживание: две модели синхронизировать, event schema как неизменяемый контракт, snapshots, versioning, repro. Бизнес-польза должна быть явной.

API Gateway и External API

Пользователь не должен знать внутреннюю структуру. Для него - единый продукт. Между клиентом и внутренними сервисами стоит Gateway.

API Gateway - единая точка входа. Делает: роутинг, auth, rate limiting, transformation, кэширование, логирование, tracing, protocol translation (внешний HTTPS/JSON → внутренний gRPC/protobuf). Готовые: AWS API Gateway, Kong, Traefik.

Backend for Frontend (BFF). Один gateway неудобен, когда разные клиенты (web, iOS, Android, партнёрское API) имеют разные потребности. BFF - отдельный gateway на тип клиента. Каждая клиентская команда владеет своим BFF. Netflix - известный пример.

API composition vs CQRS для сложных запросов. Пользователю нужны данные из нескольких сервисов:

Выбор по частоте запроса. Редкий admin-запрос - composition. Горячий user-facing dashboard - CQRS.

Service discovery и маршрутизация

В распределённой системе сервисы запускаются динамически, IP-адресов заранее нет. Нужен механизм узнавания текущего местоположения.

Service registry - общий компонент. Хранит доступные инстансы сервисов. Инстансы либо сами регистрируются (self-registration), либо третьей стороной (orchestrator при запуске).

В современных стеках (Kubernetes) discovery решён платформой. Переизобретать - трата ресурсов, если нет экзотических требований.

Reliability patterns: обязательные условия эксплуатации

Не украшения. Без них распределённая система падает регулярно и предсказуемо.

Timeouts везде. Любой cross-service вызов имеет максимальное время ожидания. Без таймаута поток клиента блокируется на минуты. TCP default - 2-3 минуты, для user-facing неприемлемо. Явные 1-10 секунд - норма.

Circuit breaker. Если сервис B падает, сервис A не должен дёргать его миллионы раз. Circuit breaker отслеживает ошибки: если процент выше порога - «размыкается», запросы моментально возвращают ошибку без вызова. Через N секунд пробует снова (half-open). При успехе - замыкается обратно. Реализации: Hystrix (deprecated), resilience4j, Polly, встроено в service mesh.

Bulkheads. Отдельные пулы ресурсов для разных типов запросов. Один пул перегружается - страдает только он. Пулы для critical/non-critical, для разных клиентов, premium/free.

Retries с backoff и jitter. Повтор упавшего запроса:

Rate limiting. Защита от абьюза. Алгоритмы: token bucket (токены тратятся по запросу, пополняются со скоростью), sliding window (счётчик в скользящем окне), fixed window (счётчик за период).

Load shedding. При перегрузке отказывать в части запросов заранее. 503 для неприоритетных, критичные продолжают обрабатываться.

Fail-fast. Быстрый отказ лучше медленного. 100ms-ошибка обрабатывается (retry, fallback). 30 секунд ожидания блокирует тред, таймаут по цепочке.

SLA-инверсия. Общий SLA не может быть выше произведения SLA зависимостей. Сервис 99.99%, вызывающий сервис 99%, не может быть доступнее 99%. Слабое звено определяет прочность цепи.

Service mesh как инфраструктурный слой reliability. Многое из описанного выше автоматизируется service mesh - sidecar-прокси рядом с каждым сервисом (Envoy, Linkerd) реализуют timeouts, retries с backoff, circuit breakers, bulkheads, rate limiting на уровне инфраструктуры. Это закрывает часть класса ошибок сервисов без участия кода приложения: политики применяются единообразно, меняются централизованно через control plane, не дублируются в каждом сервисе на каждом языке. Одновременно mesh даёт чистое наблюдение за сетевой связанностью: стандартизованные метрики (RPS, latency percentiles, error rates по каждому edge), трассировки через все границы, видимая топология взаимодействий. Это смещает часть reliability из application layer в infrastructure layer и освобождает разработку от повторения одних и тех же паттернов. Подробнее в статье «Service Mesh».

Observability: не опция, а условие работы

Распределённая система без observability неотлаживаема. Любой инцидент - расследование без улик.

Distributed tracing. Каждый запрос получает уникальный trace ID. Все операции в рамках запроса (сервисы, DB, kafka) логируются с этим ID и образуют span-ы. Восстановить путь запроса - задача минут. Стандарты: OpenTelemetry, W3C Trace Context. Инструменты: Jaeger, Zipkin, Tempo, Honeycomb.

Metrics. Два классических набора:

Инструменты: Prometheus + Grafana, Datadog, New Relic.

Log aggregation. Централизованные логи со всех сервисов. ELK (Elasticsearch + Logstash + Kibana), Loki + Grafana, Splunk.

Health check API. /health, /readiness endpoints для orchestrator. Liveness vs readiness: liveness - «процесс жив», readiness - «готов принимать трафик».

Exception tracking. Ошибки со стектрейсом в Sentry / Rollbar. Частота, затронутые пользователи, регрессии между релизами.

Correlation ID через всю систему. Critical. Запрос приходит на gateway, получает ID, ID проходит через все async-границы (включая Kafka, Redis, сторонние API). Без этого связать события одного запроса - нерешаемая задача.

Deployment и operational complexity

Распределённая система требует зрелой инфраструктуры развертывания. Без неё operational overhead убивает выигрыш от распределения.

Частые антипаттерны

Источники и смежные статьи

Первоисточники

Связанные темы

Смежные статьи блога