Оркестрированная сервис-ориентированная архитектура
Основная идея такой архитектуы заключается в многократном переиспользовании сервисов. Задача архитектора и разработчиков такой системы - провести её техническое разбиение на компоненты ("кубики", "кирпичики"), которые затем можно будет сочетать и использовать в любом порядке для построения различных систем.
Интересна история возникновения идеи создания систем с такой архитектурой. Это были 1990-е годы. Серверное ПО стоило очень дорого, лицензии на это ПО были очень хитрыми. Первое, что видел бизнес при создании новых компонентов - это потеря больших денег. Поэтому идея "создания один раз и использования везде" была очень популярной в то время. Если разработчики смогут создать узкоспециализированные переиспользуемые сервисы, то бизнесу не придется для создания новой системы писать бизнес-логику с чистого листа. Постепенно бизнес будет создавать коллекцию повторно используемых сервисов.
Основными компонентами такой архитектуры являются:
Бизнес-сервисы - точки входа, не содержащие практчески ничего, кроме ввода-вывода и информации о схеме системы. Эти сервисы создавались под конкретные потребности бизнеса (1 потребность - 1 сервис), что отражалось на их названиях: PlaceOrder, ExecuteTrade и т.д.
Корпоративные сервисы - содержат узкоспециализированные, подлежащие многократному переиспользованию реализации. Такие сервисы выполняют атомарные задачи в конкретных бизнес-областях. Например: создать клиента, посчитать проценты и т.д.
Наборы корпоративных сервисов в разных сочетаниях используются для нужд бизнес-сервисов.
Сервисы приложения - как правило, это однократно используемые сервисы, которые нет необходимости разбивать на более мелкие или делать их переиспользуемыми как корпоративные сервисы.
Инфраструктурные сервисы - обеспечивают задачи: мониторинга, логирования, аутентификации и авторизации.
Механизм оркестрации - центральная часть данной архитектуры. Его задачи - сшивать вместе бизнес-сервисы и корпоративные сервисы, выполнять координацию транзакций и преобразование сообщений.
Недостатки оркестрированной сервис-ориентированной архитектуры:
- команда архитекторов, ответсвенная за механизм оркестрации становится наболее сильным политическим местом внутри организации и, в конечном итоге, узким бюрократическим местом,
- найти правильный уровень гранулярности транзакций на уровне оркестратора сервисов со временем становится все труднее. Отсюда - сложности с объединением наборов копоративных сервисов для нужд бизнес-сервисов и усложнение архитектуры
- абсолютно все потоки сообщений между компонентами системы идут через оркестратора (шина корпоративных сервисов). Типичный поток исполнения одного бизнес-процесса будет выглядеть примерно так:
- связывание.
На схеме показан сервис Customer, в который выделено всё, что связано с клиентами. Этот сервис подлежит многократному использованию другими сервисами, которые оказываются связанными между собой.
При внесении каких-либо изменений в сервис Customer есть большой риск навредить всей системе - каждое изменение сервиса Customer вызовет цепную реакцию в остальных сервисах.
- сервисы обмениваются данными (через Шину), которые им не нужны. Ни одна из имеющихся частей архитектуры не может иметь архитектурные свойства, отличающиеся от свойств оркестратора, управляющего всем поведением. Например, сервис Customer будет содержать все сведения о пользователях: пенсионное удостоверение, водительское удостоверение и другие данные, которые он будет предоставлять всем сервисам, так как является сервисом, многократно переиспользуемым через единую точку сопряжения (Шину), с универсальным API,
- необходимость скоординированных развертываний множества сервисов,
- необходимость комплексного тестирования всей системы,
- низкая производительность системы, т.к. один бизнес-запрос оказывался распределённым по множеству сервисов,
- координация транзакций вынесена на уровень оркестратора и это усложняет работу по выявлению её границ. Часто, при изменении бизнес-требований разработчикам приходилось либо менять дизайн сервисов, либо создавать новый, почти такой же сервис, чтобы изменить транзакционное поведение. В итоге, разработчики оказывались вынужденными делать то, от чего хотели уйти, используя такой архитектурный стиль - писать новые сервисы под изменяющиеся задачи бизнеса.
Все перечисленные недостатки снижают скорость и эффективность разработки.
Оркестрированная сервис-ориентированная архитектура, выполнив задачи своей эпохи, уступила место микросервисной архитектуре.