Хореография и оркестрация

Уже достаточно много постов в канале написано на темы, связанные с проектированием сервисов/микросервисов. В частности о том, как проектировать их методы, описывать документацию и примеры различных best-practices, которые я почерпнул из собственного (и не только) опыта.

Настало время подняться на уровень, а то и на два, выше и поговорить про архитектуру. А именно про различные популярные подходы к проектированию систем, которые используют микросервисную архитектуру.

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

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

Оркестрация - разработка системы, в которой взаимодействие между подсистемами происходит под управлением центрального контроллера (сервиса-оркестратора), который координирует выполнение процессов, отдавая подсистемам команды на основе заранее определенных правил.

В общем, это когда у вас в центре системы притаился большой паук, который дергает за ниточки по наступлению каких-то событий или при обращении к нему с вопросами из разряда "А что мне делать дальше, у меня есть такие исходные данные?" (в одной из команд, у нас даже был огромный блок в ТЗ, который так и назывался "Данные получил, что дальше?", в котором описывалось, куда оркестратор должен пойти, чтобы понять, что он должен скомандовать).
И только он один владеет всей логикой процесса.

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

Из минусов:
➖Самый очевидный минус в том, что когда у тебя весь процесс завязан на одно управляющее звено - он становится более уязвим примерно ко всему.

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

P.S. В комментарии вложу абстрактный пример концепции оркестрации.