Розділіть усе. Дозвольте сервісам спілкуватися за допомогою подій, а не очікувань щодо доступності один одного.

Ваш моноліт стає вузьким місцем розгортання — кожна зміна вимагає координації між командами, а помилка у виставленні рахунків виводить з ладу весь додаток. Або ви створюєте нову систему, де різні можливості розвиваються з різною швидкістю: управління замовленнями змінюється щотижня, а логіка інвентаризації — щокварталу. Вам потрібні сервіси, які можна розробляти, розгортати та масштабувати незалежно, спілкуючись за допомогою подій, а не синхронних викликів API, що створюють ланцюги каскадних відмов.
Explore more design patterns and system architectures
Наші архітектори можуть допомогти вам проектувати та будувати системи, використовуючи цей шаблон для ваших конкретних вимог.
Зв'яжіться з намиМікросервіси, керовані подіями, декомпозують систему на незалежно розгортані сервіси, які спілкуються переважно за допомогою асинхронних подій. Кожен сервіс володіє своїми даними, публікує доменні події при зміні стану та реагує на події від інших сервісів. Це усуває часове зв'язування — Сервісу A не потрібно, щоб Сервіс B був запущений для виконання своєї роботи. Патерн включає CQRS (Command Query Responsibility Segregation) для розділення моделей запису та читання, event sourcing для захоплення повної історії змін стану та saga orchestration для управління транзакціями між кількома сервісами без розподілених блокувань.
Архітектура зосереджена на основі подій (Kafka, EventBridge або NATS), яка маршрутизує доменні події між сервісами. Кожен сервіс має три межі: обробник команд, який обробляє вхідні запити та генерує події; обробник запитів, який обслуговує оптимізовані для читання проекції; та обробник подій, який реагує на події від інших сервісів. Saga orchestrator координує багатоетапні бізнес-процеси (наприклад, виконання замовлення), слухаючи події та видаючи компенсуючі команди у разі збою кроків.
| Рівень | Технології |
|---|---|
| Обчислення | Node.js (NestJS), Python (FastAPI), Go — для кожного сервісу залежно від характеристик робочого навантаження |
| Обмін повідомленнями | Apache Kafka (MSK), AWS EventBridge, NATS JetStream, RabbitMQ |
| Дані | PostgreSQL (транзакційний), DynamoDB (ключ-значення), Redis (кешування/блокування), EventStoreDB |
| Оркестрація | Temporal (оркестрація робочих процесів), AWS Step Functions, користувацький координатор саг |
| Спостережуваність | OpenTelemetry (розподілене трасування), Datadog, Jaeger, структуроване логування з ідентифікаторами кореляції |
| Використовувати, коли | Уникати, коли |
|---|---|
| Кілька команд мають розгортати незалежно з різним темпом | Ваша команда складається з < 5 інженерів — добре структурований моноліт простіший в експлуатації |
| Різні частини системи мають різні характеристики масштабування | Ви створюєте MVP і вам потрібно швидко випустити продукт — розподілені системи будуються повільно |
| Вам потрібні надійні аудиторські сліди та можливості відтворення подій | Кожна операція вимагає синхронних, сильно узгоджених відповідей |
| Домен має природні обмежені контексти (замовлення, платежі, запаси) | Домен тісно пов'язаний — його поділ створює розподілений моноліт |
MW не декомпозує на мікросервіси за технічними рівнями (API service, data service, auth service). Ми декомпозуємо за доменними межами, використовуючи DDD (Domain-Driven Design) bounded contexts. Перед написанням коду ми проводимо семінар з event storming, щоб відобразити доменні події, команди та агрегати — це визначає межі сервісів, а не технологічні переваги. Ми мігрували моноліти на архітектури, керовані подіями, для корпоративних клієнтів, і найпоширеніший урок такий: починайте з меншої кількості більших сервісів і розділяйте їх пізніше, а не навпаки.
Моделі не працюють самі по собі. Конвеєр, що навчає, валідує, розгортає та моніторить ваші моделі, є фактичним продуктом — модель є лише одним артефактом.
MicrocosmWorks розробляє подієво-орієнтовані системи з надійними брокерами повідомлень, такими як Apache Kafka або Amazon EventBridge, які зберігають події, доки споживачі успішно їх не оброблять, забезпечуючи відсутність втрати даних під час збоїв. Ми впроваджуємо dead-letter queues, exponential backoff retry policies та circuit breakers, щоб мікросервіс, що відмовляє, не блокував весь конвеєр подій. Як тільки підпорядкований сервіс відновлюється, він автоматично наздоганяє необроблені події без ручного втручання.
Подієво-орієнтована комунікація є кращим вибором, коли ваші сервіси не потребують негайної відповіді, коли вам потрібно роз'єднати цикли розгортання, або коли одна дія запускає декілька наступних процесів. MicrocosmWorks зазвичай рекомендує подієво-орієнтовані патерни для обробки замовлень, конвеєрів сповіщень та прийому аналітичних даних, зберігаючи при цьому синхронні API для запитів, орієнтованих на користувача, які потребують відповідей менш ніж за секунду. Багато виробничих систем, які ми створюємо, використовують гібридний підхід із синхронним читанням та асинхронним записом.
MicrocosmWorks використовує partition-key-based ordering у темах Kafka, щоб гарантувати, що всі події для певної сутності (наприклад, конкретного замовлення або користувача) обробляються послідовно тим самим consumer instance. Для сценаріїв, що вимагають cross-entity ordering, ми впроваджуємо saga orchestrators з idempotent event handlers, які можуть безпечно повторно обробляти повідомлення, що надійшли не по порядку. Ми також вбудовуємо vector clocks або sequence numbers у event payloads, щоб споживачі могли виявляти та узгоджувати ordering conflicts.
MicrocosmWorks реалізує шаблон Saga з компенсуючими транзакціями, де кожен мікросервіс публікує доменні події після завершення своєї локальної транзакції, а нижчі сервіси відповідно реагують або запускають компенсації відкату в разі збою. Ми поєднуємо це з шаблоном Outbox, який атомарно записує події до локальної таблиці outbox разом з бізнес-даними, а потім надійно публікує їх у брокер повідомлень. Це досягає кінцевої узгодженості без штрафів за продуктивність і надійність двофазних коммітів.
MicrocosmWorks інструментує кожну подію за допомогою ідентифікаторів кореляції та заголовків розподіленого трасування, використовуючи OpenTelemetry, що дозволяє нам візуалізувати повний життєвий цикл бізнес-транзакції через усі задіяні мікросервіси в таких інструментах, як Jaeger або Grafana Tempo. Ми також створюємо дашборди потоку подій у реальному часі, які показують пропускну здатність, затримку споживача та затримку обробки для кожної служби, що дозволяє легко виявляти вузькі місця. Наш стандартний стек спостережуваності включає структуроване логування з метаданими подій, завдяки чому будь-яку окрему подію можна відстежити від виробника до кожного споживача за лічені секунди.