Оркестрация и хореография в микросервисной архитектуре

В микросервисной архитектуре для организации взаимодействия микросервисов между собой используют два подхода: оркестрацию и хореографию.
Оркестрация
Оркестрация – это подход, при котором есть центральный сервис (оркестратор), который координирует и управляет всеми остальными сервисами. Оркестратор знает всю логику бизнес-процесса и вызывает нужные сервисы в нужном порядке, передавая им необходимые данные и получая от них ответы. Оркестратор может использовать разные способы коммуникации с сервисами, например, REST, RPC, очереди сообщений и т.д. Пример "коробочного" решения для оркестрации: Camunda.
Плюсы оркестрации
- Можно быстрее понять и прозрачнее отследить логику бизнес-процесса, так как она сосредоточена в одном месте, а не размыта по всем сервисам сразу.
- Легче вносить изменения в бизнес-процесс, так как достаточно изменить только оркестратор.
- Легче обрабатывать ошибки и альтернативные сценарии, так как оркестратор контролирует выполнение всех шагов.
Минусы оркестрации
- Высокая связанность между сервисами, так как оркестратор зависит от интерфейсов и доступности всех сервисов, а сервисы зависят от того, что оркестратор передает им в качестве входных данных.
- Оркестратор становится узким местом и единой точкой отказа.
- Добавление новых сервисов или изменение порядка вызовов требует изменения оркестратора.
Хореография
Хореография – это подход, при котором нет центрального сервиса, который управляет всеми остальными. Вместо этого каждый сервис самостоятельно решает, что и когда делать, на основе событий, которые он получает от других сервисов. Сервисы публикуют события в общий канал (например, топик в Kafka) и подписываются на события, которые их интересуют. Таким образом, формируется цепочка реакций на события, которая реализует бизнес-процесс.
Плюсы хореографии
- Низкая связанность между сервисами, так как сервисы не знают друг о друге и общаются только через события, а не через прямые вызовы.
- Высокая масштабируемость и отказоустойчивость, так как нет единой точки отказа и каждый сервис может работать независимо от других.
- Гибкость, так как можно легко добавлять новые сервисы или изменять поведение существующих, не затрагивая другие.