Как событийно-ориентированная архитектура помогает отделить ваше приложение

Микросервисы сейчас в моде.

Они позволяют разделить ваше приложение на небольшие части с четкими границами домена. Микросервисы отделены друг от друга, что позволяет изменять и развертывать их независимо друг от друга, что обеспечивает большую автономию командам, работающим над каждым микросервисом.

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

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

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

Два режима сотрудничества

Что вы делаете, когда микросервисам нужно общаться друг с другом? В идеале все коммуникации должны быть асинхронными. Кроме того, любое взаимодействие между микросервисами не должно тесно связывать их друг с другом. В противном случае вы потеряете преимущества независимых изменений и развертываний.

Мы можем использовать два основных режима сотрудничества: организация (запрос/ответ) или хореография (управляемая событиями).

При оркестровке — или схеме «запрос/ответ» — центральная служба сообщает все, что нужно делать. Он отправляет запросы другим нижестоящим службам, чтобы убедиться, что все происходит правильно, и нижестоящие службы отвечают на эти запросы.

При хореографии — или архитектуре, управляемой событиями — первый сервис просто генерирует событие. Различные сервисы могут подписываться на эти каналы событий, и когда они видят определенное событие, они могут реагировать так, как им хочется.

Пример: оплата электронной коммерции

Давайте рассмотрим пример, чтобы лучше понять эти две парадигмы.

Представьте, что у нас есть сайт электронной коммерции. Когда покупатель завершает процесс оформления заказа, должно произойти несколько вещей:

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

Важно отметить, что после размещения заказа следующие три задачи не обязательно должны выполняться в каком-то определенном порядке. Они просто должны произойти.

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

Итак, как будет выглядеть процесс оркестровки и хореографии?

Оркестровка

При организованном процессе служба оформления заказа будет действовать как наша центральная служба. Когда клиент отправляет свой заказ, служба оформления заказа отправляет три запроса API к службе электронной почты, службе склада и службе вознаграждений. Служба оформления заказа сообщит службе электронной почты отправить электронное письмо, службе склада — начать подготовку к отправке, а службе вознаграждений — создать новый баланс баллов.

В этом смысле касса выступает в роли дирижера оркестра, говорящего всем игрокам, что и когда делать.

Хореография

В управляемой или управляемой событиями архитектуре бизнес-процесс тот же, но то, как наши службы обрабатывают его, немного отличается. Когда клиент отправляет свой заказ, служба проверки будет генерировать событие. Это даже будет называться что-то вроде «OrderCreated» и будет включать детали заказа.

Наши три нисходящие службы (электронная почта, склад и вознаграждения) будут подписаны на канал событий и будут прослушивать события. Когда генерируется событие «OrderCreated», наши три службы увидят это событие и отреагируют соответствующим образом, отправив электронное письмо, подготовив отправку и создав новый баланс баллов.

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

Недостатки оркестровки

Вы уловили здесь разницу? Это тонко, но важно. Основное отличие состоит в том, что хореография или архитектура, управляемая событиями, дает нам больше гибкости, когда наше приложение нуждается в изменении.

Что, если, например, позже мы создадим четвертый сервис, и он тоже должен что-то делать при размещении заказа? В организованной модели, чтобы изменить наше приложение, нам нужно изменить нашу службу проверки, чтобы сделать четвертый запрос API к этой новой службе.

Или что, если конечная точка API для одной из наших трех существующих служб изменилась? Может быть, вместо того, чтобы вызывать исходную конечную точку, нам нужно, чтобы она вызывала другую конечную точку? Или, может быть, нам нужно сделать два API-запроса к сервису, а не один?

В организованной модели изменения такого рода снова потребовали бы от нас изменения службы проверки.

Мы непреднамеренно соединили наши микросервисы вместе!

Преимущества хореографии

Теперь вернемся к хореографической архитектуре. Служба проверки просто генерирует событие, а все последующие службы просто реагируют на это событие.

Итак, нужно добавить четвертую услугу? Нет проблем, просто подпишитесь на это событие.

Нужно изменить реакцию существующего сервиса на событие? Без проблем. Мы можем изменить поведение нижестоящего сервиса, не затрагивая другие сервисы, такие как сервис оформления заказа.

Хореография дает нам большую гибкость и помогает нам не связывать наши услуги.