Оркестрирующие микросервисы

Question

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

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

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

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

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

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

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

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

Стрелять.

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь, после этого наступает веселье. В книге "Микросервисы" не предполагается, что микросервисы будут реализованы с помощью 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-шлюза

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

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

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

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

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

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

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

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

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

Дальнейшее чтение

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

• Введение в микросервисы
• Создание микросервисов: использование API-шлюза
• Создание микросервисов: IPC в архитектуре микросервисов
• Обнаружение услуг в архитектуре микросервисов
• Управляемое событиями управление данными для микросервисов
• Выбор стратегии развертывания микросервисов
• Реорганизация монолита в микросервисы

Answer 2

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

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

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

полномочие

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

,

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

HTH, Марк

Answer 5

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

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

Answer 6

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

Шаги

1. Добавьте ниже зависимость к вашему проекту (если вы используете Maven)

            <dependency>
        <groupId>org.springframework.statemachine</groupId>
        <artifactId>spring-statemachine-core</artifactId>
        <version>2.2.0.RELEASE</version>
    </dependency>
   

2. Определите состояния и события, например, состояние 1, состояние 2, событие 1 и событие 2.

3. Обеспечьте реализацию конечного автомата в методе buildMachine() .

           configureStates
   configureTransitions
   

4. Отправлять события в конечный автомат

См. Полный на странице документации.код

Answer 7

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

Etsy использует Kubernetes для организации сложной архитектуры из сотен микросервисов для своей платформы электронной коммерции.

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

Answer 8

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

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

Шаблон 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 может включать различные технологии и протоколы связи, в то время как грубо абстрагировать их в единый поток. при проектировании системы учитывайте и то, и другое, потому что не существует золотого подхода, который решает все, и для каждого есть свой компромисс. Грубые детали особенно подходят в качестве услуг, которые будут использоваться в других бизнес-контекстах, таких как другие приложения, бизнес-направления или даже другими организациями за пределами собственных границ предприятия (типичные сценарии B2B).

Answer 9

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