Большинство из нас знакомы с основными концепциями микросервисов и их преимуществами; однако зачастую нет единого мнения о том, как их правильно реализовать. При создании приложения, использующего микросервисы, вам нужно будет принимать решения о том, как микросервисы взаимодействуют друг с другом. В ходе этих обсуждений часто возникает вопрос: Следует ли мне использовать оркестровку или реактивный подход в моем приложении? И можно ли использовать и то, и другое?

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

Преимущества и недостатки оркестровки

Оркестровка - это традиционный способ обработки взаимодействий между различными сервисами в сервис-ориентированной архитектуре (SOA). При оркестровке обычно есть один контроллер, который действует как «оркестратор» всех взаимодействий сервисов. Обычно это соответствует шаблону типа запрос / ответ.

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

Преимущества

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

Компромиссы

  • Объединяет сервисы вместе, создавая зависимости. Если служба A не работает, службы B и C никогда не будут вызваны.
  • Если для всех запросов существует центральный общий экземпляр оркестратора, то оркестратор является единственной точкой отказа. Если он выйдет из строя, вся обработка остановится.
  • Использует синхронную обработку, которая блокирует запросы. В этом примере общее время сквозной обработки - это сумма времени, которое требуется для вызова службы A + службы B + службы C.

Реактивные преимущества и компромиссы

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

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

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

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

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

Преимущества

  • Обеспечивает более быструю сквозную обработку, поскольку службы могут выполняться параллельно / асинхронно.
  • Легче добавлять / обновлять сервисы, так как их можно легко подключать / отключать от потока событий.
  • Хорошо согласуется с гибкой моделью доставки, поскольку команды могут сосредоточиться на определенных услугах, а не на всем приложении.
  • Управление распределено, поэтому больше нет единого оркестратора, служащего центральной точкой отказа.
  • Для получения дополнительных преимуществ с реактивной архитектурой можно использовать несколько шаблонов. Например, Источник событий - это когда поток событий сохраняет все события и включает воспроизведение событий. Таким образом, если служба выйдет из строя, пока события все еще создавались, когда она вернется в оперативный режим, она сможет воспроизвести эти события, чтобы их восстановить. Кроме того, Разделение ответственности за запросы команд (CQRS) может применяться для разделения операций чтения и записи. Это позволяет масштабировать каждый из них независимо. Это удобно, если у вас есть приложение, которое требует большого количества операций чтения и легких операций записи, или наоборот.

Компромиссы

  • Асинхронное программирование часто является серьезным сдвигом для разработчиков. Я склонен думать об этом как о рекурсии, когда вы не можете понять, как будет выполняться код, просто взглянув на него, вы должны продумать все возможности, которые могут быть верными в определенный момент времени.
  • Сложность сдвинута. Вместо централизованного управления потоком в оркестраторе, управление потоком теперь разбито на отдельные службы. У каждой службы будет своя собственная логика потока, и эта логика будет определять, когда и как она должна реагировать на основе конкретных данных в потоке событий.

Гибриды

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

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

Гибрид №1 - Реактивное взаимодействие и внутренняя оркестровка

Первый гибридный шаблон использует реактивное взаимодействие между сервисами и оркестровку внутри сервиса. В этом примере службы A, B и C реагируют друг на друга. Служба A использует событие, которое запускает ее для организации вызовов дополнительных служб D, E и F. Эти дополнительные вызовы службы могут быть асинхронными или синхронными. Затем служба A создает событие с результатом этих трех вызовов службы.

Преимущества

  • Услуги разделены (но не услуги в рамках услуги A).
  • Асинхронная обработка обеспечивается за счет использования событий между службами.
  • Общий поток распределяется. Каждая служба содержит свою собственную логику потока.

Компромиссы

  • В рамках услуги A существует связь со службами D, E и F.
  • В зависимости от конструкции в службе A может выполняться синхронная обработка, блокирующая запросы.

Гибрид №2 - Реагирующий между и координатором для управления потоком

Второй гибридный шаблон использует реакцию между сервисами и координатором для управления потоком. В этом примере координатор подобен реактивному оркестратору. Он использует концепции команд и событий: команды - это то, что нужно сделать, а события - это уже выполненные действия. Координатор создает команды для потока событий, а соответствующие микросервисы, которые предварительно запрограммированы для команд, используют команду, выполняют некоторую обработку, а затем создают события для потока событий. В этом примере службы A и C запускаются одновременно. Координатор получает события из потока событий и реагирует на события, о которых он заботится, по мере необходимости.

Преимущества

  • Службы разделены (но между службами и координатором существует определенная взаимосвязь).
  • Асинхронная обработка обеспечивается за счет использования событий между службами.
  • Общий поток можно увидеть в одном месте координатора реакции.

Компромиссы

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

Когда использовать оркестровку vs. Реактивные Vs. Гибриды

Так должно ли все быть реактивным в будущем? Ушла ли оркестровка в прошлое? Прорабатывая различные варианты использования, я обнаружил, что существуют допустимые сценарии, в которых каждый шаблон имеет смысл. Здесь мы рассмотрим некоторые гипотетические условия, в которых может применяться чистая реактивная, чистая оркестровка или гибридный паттерн.

Реактивные варианты использования

  • Если вся или большая часть вашей обработки может выполняться асинхронно. Шаблон реактивной архитектуры отлично подходит для параллельной обработки. Если минимальная или нулевая обработка может выполняться асинхронно, то реактивный шаблон может быть чрезмерным.
  • Если децентрализовать поток в каждую службу можно. Идентификаторы корреляции можно использовать для воссоздания централизованного представления для мониторинга и аудита.
  • Если скорость выхода на рынок является приоритетом. Сочетание микросервисов с реактивным подходом помогает максимизировать разделение и минимизировать зависимости, позволяя продуктам быстрее выходить на рынок.

Примеры использования чистой оркестрации

  • Если все или большая часть ваших шагов должна выполняться последовательно, с минимальными или нулевыми возможностями для параллельной обработки.
  • Если есть желание сохранить централизованное управление общим потоком. Это может быть сложно, но я вижу сценарий, в котором централизация потока может иметь смысл. В частности, если возможность видеть сквозной поток в одном месте является высоким приоритетом как во время разработки, так и во время выполнения. Одно из условий, при котором это может быть правдой, - это если у вас есть сотни служб, каждая из которых имеет несколько различных потоков в зависимости от того, что обрабатывается. В этом случае может быть проще управлять потоком в одном месте, чем распределять его.
  • Развязка не является приоритетом.

Варианты гибридного использования

Когда использовать реактивное взаимодействие между сервисами и оркестровку внутри сервиса

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

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

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

Заключение

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

ЗАЯВЛЕНИЕ О РАСКРЫТИИ ИНФОРМАЦИИ: это мнение автора. Если в этом посте не указано иное, Capital One не связан и не одобрен ни одной из упомянутых компаний. Все используемые или отображаемые товарные знаки и другая интеллектуальная собственность являются собственностью соответствующих владельцев. Эта статья © Capital One, 2018.