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