Какова стандартная схема оркестровки микросервисов?

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

Допустим, у нас есть что-то вроде этого:

• инвойсирование
• отгрузка

И в качестве аргумента, скажем, после отправки заказа необходимо создать счет-фактуру.

Где-то кто-то нажимает кнопку в GUI: «Я сделал, давайте сделаем это!» В классической архитектуре монолитного сервиса, я бы сказал, что есть или ESBобработка этого, или служба отгрузки знает об услуге счета-фактуры и просто вызывает это.

Но как люди справляются с этим в этом дивном новом мире микросервисов?

Я понимаю, что это можно считать высоко основанным на мнении. но есть и конкретная сторона, так как микросервисы не должны делать вышеперечисленное. Таким образом, должно быть «что должно по определению делать», которое не основано на мнении.

Shoot.

Книга Building Microservices подробно описывает стили, упомянутые @RogerAlsing в его ответе.

На странице 43 в разделе «Оркестровка против хореографии» говорится:

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

Затем книга переходит к объяснению двух стилей. Стиль оркестровки больше соответствует идее SOA об услугах оркестровки / задач , тогда как стиль хореографии соответствует тупым каналам и умным конечным точкам, упомянутым в статье Мартина Фаулера.

Стиль оркестровки

Под этим стилем книга выше упоминает:

Давайте подумаем о том, как будет выглядеть решение для оркестровки для этого потока. Здесь, вероятно, самое простое, что нужно сделать, - это сделать так, чтобы наша служба поддержки клиентов выступала в качестве центрального мозга. При создании он разговаривает с банком пунктов лояльности, почтовой службой и почтовой службой [...] через серию запросов / ответных звонков. Затем сама служба поддержки клиентов может отслеживать, где находится клиент в этом процессе. Он может проверить, настроена ли учетная запись клиента, отправлено ли электронное письмо или доставлено ли сообщение. Мы берем блок-схему [...] и моделируем ее непосредственно в коде. Мы могли бы даже использовать инструменты, которые реализуют это для нас, возможно, используя соответствующий механизм правил. Для этой цели существуют коммерческие инструменты в виде программного обеспечения для моделирования бизнес-процессов. Предполагая, что мы используем синхронный запрос / ответ, мы могли бы даже знать, сработал ли каждый этап [...]. Недостатком этого подхода к оркестровке является то, что обслуживание клиентов может превратиться в центральный орган управления. Это может стать центром в середине сети и центральной точкой, где логика начинает жить. Я видел, как этот подход приводил к тому, что небольшое количество умных «божьих» сервисов сообщали анемичным службам на основе CRUD, что делать.

Примечание: я предполагаю, что когда автор упоминает инструментарий, он ссылается на что-то вроде BPM (например, Activity , Apache ODE , Camunda ). На самом деле, на сайте шаблонов рабочих процессов есть потрясающий набор шаблонов для такого рода оркестровки, а также он предлагает подробные сведения об оценке различных инструментов вендоров, которые помогают реализовать его таким образом. Я не думаю, что автор подразумевает, что для реализации этого стиля интеграции необходимо использовать один из этих инструментов, хотя можно использовать и другие облегченные структуры оркестровки, например Spring Integration , Apache Camel или Mule ESB.

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

Стиль хореографии

В стиле хореографии автор говорит:

Используя хореографический подход, мы могли бы просто сделать так, чтобы служба поддержки клиентов отправляла событие асинхронно, говоря, что Клиент создан. Почтовый сервис, почтовый сервис и банк баллов лояльности затем просто подписываются на эти события и соответственно реагируют [...]. Этот подход значительно более разъединен. Если какой-то другой сервис нужен для создания клиента, ему просто нужно подписаться на события и выполнять свою работу, когда это необходимо. Недостатком является то, что явное представление бизнес-процесса, которое мы видим в [рабочем процессе], теперь только неявно отражается в нашей системе [...] Это означает, что требуется дополнительная работа, чтобы гарантировать, что вы можете отслеживать и отслеживать, что правильные вещи имеют получилось. Например, Вы знаете, если в банке баллов лояльности была ошибка и по какой-то причине не был настроен правильный аккаунт? Один подход, который мне нравится для решения этой проблемы, заключается в создании системы мониторинга, которая явно соответствует представлению бизнес-процесса в [рабочем процессе], но затем отслеживает, что каждая из служб выполняет как независимые объекты, позволяя вам видеть странные исключения, отображаемые на более явный процесс. [Блок-схема] [...] не движущая сила, а всего лишь один объектив, через который мы можем видеть, как ведет себя система. В общем, я обнаружил, что системы, которые больше склоняются к хореографическому подходу, более слабо связаны и более гибки и поддаются изменению. Однако вам необходимо проделать дополнительную работу для мониторинга и отслеживания процессов через границы системы. Я обнаружил, что наиболее сильно организованные реализации являются чрезвычайно хрупкими, с более высокой стоимостью изменений. Имея это в виду, я настоятельно предпочитаю стремиться к хореографической системе, где каждый сервис достаточно умен, чтобы понять его роль в танце.

Примечание: по сей день я до сих пор не уверен, является ли хореография просто еще одним названием для архитектуры, управляемой событиями (EDA), но если EDA - это только один из способов сделать это, каковы другие способы? (Также см. Что вы подразумеваете под «управляемой событиями»? И «Значения управляемой событиями архитектуры» ). Кроме того, кажется, что такие вещи, как CQRS и EventSourcing, сильно резонируют с этим архитектурным стилем, верно?

Теперь, после этого наступает веселье. В книге «Микросервисы» не предполагается, что микросервисы будут реализованы с помощью REST. На самом деле, в следующем разделе книги они рассмотрят решения на основе RPC и SOA и, наконец, REST. Важным моментом здесь является то, что Microservices не подразумевает REST.

Итак, что насчет HATEOAS? (Гипермедиа как двигатель состояния приложения)

Теперь, если мы хотим следовать подходу RESTful, мы не можем игнорировать HATEOAS, или Рой Филдинг будет очень рад сказать в своем блоге, что наше решение не является действительно REST. См. Его сообщение в блоге о REST API. Должно быть на основе гипертекста :

Я разочарован количеством людей, которые называют любой интерфейс на основе HTTP REST API. Что необходимо сделать, чтобы сделать архитектурный стиль REST понятным для понятия, что гипертекст является ограничением? Другими словами, если механизм состояния приложения (и, следовательно, API) не управляется гипертекстом, то он не может быть RESTful и не может быть REST API. Период. Есть ли где-нибудь сломанное руководство, которое нужно починить?

Итак, как вы можете видеть, Филдинг считает, что без HATEOAS вы на самом деле не создаете RESTful-приложения. Для Филдинга HATEOAS - это путь, когда дело доходит до организации сервисов. Я только учусь всему этому, но для меня, HATEOAS не дает четкого определения, кто или что является движущей силой на самом деле по ссылкам. В пользовательском интерфейсе, который может быть пользователем, но при взаимодействии между компьютерами, я полагаю, что это должно быть сделано службой более высокого уровня.

Согласно HATEOAS, единственная ссылка, которую действительно должен знать потребитель API, - это та, которая инициирует связь с сервером (например, POST / order). С этого момента REST будет выполнять поток, потому что в ответе этой конечной точки возвращаемый ресурс будет содержать ссылки на следующие возможные состояния. Потребитель API затем решает, по какой ссылке следовать, и переводит приложение в следующее состояние.

Несмотря на то, как это круто звучит, клиент все равно должен знать, должны ли ссылки быть POSTed, PUTed, GETed, PATCHed и т. Д. И клиенту все еще нужно решить, какую полезную нагрузку передать. Клиент по-прежнему должен знать, что делать в случае сбоя (повторить попытку, компенсировать, отменить и т. Д.).

Я довольно новичок во всем этом, но для меня, с точки зрения HATEOA, этот клиент или потребитель API является сервисом высокого порядка. Если мы думаем об этом с точки зрения человека, вы можете представить конечного пользователя на веб-странице, решающего, по каким ссылкам следовать, но программисту веб-страницы все же пришлось решать, какой метод использовать для вызова ссылок, и какую полезную нагрузку передать. Так что, на мой взгляд, во взаимодействии между компьютерами компьютер играет роль конечного пользователя. Еще раз это то, что мы называем сервисом оркестровки.

Я полагаю, мы можем использовать HATEOAS с оркестровкой или хореографией.

Шаблон шлюза API

Крис Ричардсон предложил еще один интересный паттерн, который также предложил то, что он назвал паттерном шлюза API .

В монолитной архитектуре клиенты приложения, такие как веб-браузеры и собственные приложения, отправляют HTTP-запросы через балансировщик нагрузки одному из N идентичных экземпляров приложения. Но в микросервисной архитектуре монолит был заменен набором сервисов. Следовательно, ключевой вопрос, на который мы должны ответить, - это то, с чем взаимодействуют клиенты?

Клиент приложения, такой как собственное мобильное приложение, может отправлять запросы RESTful HTTP отдельным службам [...] На первый взгляд это может показаться привлекательным. Однако существует вероятность существенного несоответствия гранулярности между API отдельных сервисов и данными, требуемыми клиентами. Например, для отображения одной веб-страницы могут потребоваться вызовы большого количества служб. Amazon.com, например, описывает, как некоторые страницы требуют звонков на 100+ услуг. Выполнение такого большого количества запросов, даже через высокоскоростное подключение к Интернету, не говоря уже о мобильной сети с более низкой пропускной способностью и высокой задержкой, будет очень неэффективным и приведет к ухудшению качества обслуживания пользователей.

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

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

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

Шлюз API не только оптимизирует связь между клиентами и приложением, но также инкапсулирует детали микросервисов. Это позволяет микросервисам развиваться, не влияя на клиентов. Например, два микросервиса могут быть объединены. Другой микросервис может быть разделен на две или более служб. Только шлюз API необходимо обновить, чтобы отразить эти изменения. Клиенты не пострадали.

Теперь, когда мы рассмотрели, как шлюз API является посредником между приложением и его клиентами, давайте теперь посмотрим, как реализовать связь между микросервисами.

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

Попытка объединить различные подходы здесь.

Доменные события

Доминирующий подход для этого, кажется, использует доменные события, где каждый сервис публикует события, касающиеся произошедшего, а другие сервисы могут подписаться на эти события. Это, кажется, идет рука об руку с концепцией умных конечных точек, тупых каналов, которая описана Мартином Фаулером здесь: http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

полномочие

Другим распространенным явлением является завершение бизнес-процесса в собственном сервисе. Где прокси-сервер координирует взаимодействие между микросервисами, как показано на рисунке ниже:

,

Другие образцы композиции

Эта страница содержит различные образцы композиции.

Итак, чем отличается оркестрация микросервисов от оркестрации старых сервисов SOA, которые не являются «микро»? Совсем немного.

Микросервисы обычно общаются с использованием http (REST) ​​или обмена сообщениями / событиями. Orchestration часто ассоциируется с платформами оркестровки, которые позволяют создавать сценарии взаимодействия между службами для автоматизации рабочих процессов. В старые времена SOA эти платформы использовали WS-BPEL. Современные инструменты не используют BPEL. Примеры современных продуктов для оркестровки: Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker.

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

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

Итак, у вас есть две услуги:

1. Микросервис счета
2. Микросервис отгрузки

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

• Простой графический интерфейс, знающий все ваши услуги и реализующий варианты использования («Я готов» вызывает службу доставки)
• Механизм бизнес-процесса, который ожидает события «Я закончил». Этот двигатель реализует варианты использования и поток.
• Микро сервис оркестровки, скажем, сам сервис обработки заказов, который знает потоки / варианты использования вашего домена
• Что-нибудь еще, о чем я еще не думал

Суть в том, что управление является внешним. Это потому, что все компоненты вашего приложения являются отдельными строительными блоками, слабо связанными. Если ваши варианты использования меняются, вы должны изменить один компонент в одном месте, который является компонентом оркестровки. Если вы добавите другой поток заказов, вы можете легко добавить другого оркестратора, который не мешает первому. Микросервисное мышление - это не только масштабируемость и функциональность REST API, но и четкая структура, уменьшенные зависимости между компонентами и повторное использование общих данных и функций, которые совместно используются в вашем бизнесе.

HTH, Марк

Если государство нуждается в управлении , то Sourcing события с CQRS является идеальным способом общения. Иначе, асинхронная система обмена сообщениями (AMQP) может использоваться для межсервисной связи.

Из вашего вопроса ясно, что ES с CQRS должен быть правильным сочетанием. Если вы используете Java, взгляните на Axon Framework. Или создайте собственное решение, используя Kafka или RabbitMQ.

я написал несколько постов на эту тему:

Может быть, эти сообщения также могут помочь:

Шаблон API Gateway - API с курсом и API

https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/

Крупно-гранулированный и мелкозернистый сервис API

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

ответ на оригинальный вопрос - шаблон SAGA.