Ответ 1

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

На странице 43 в разделе Orchestration vs Choreography в книге говорится:

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

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

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

В этом стиле в приведенной выше книге упоминается:

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

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

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

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

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

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

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

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

Итак, что о HATEOAS?

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

Меня расстраивает количество людей, вызывающих любые 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 Gateway Pattern.

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

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

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

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

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

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

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

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

Дополнительная литература

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

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

Ответ 2

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

События домена

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

Proxy

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

.

Ответ 3

Итак, у вас есть две службы:

• Микрофонная служба счета
• Отправка микросервиса

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

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

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

HTH, Mark

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

Я написал несколько сообщений по этой теме:

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

Шаблон API-шлейфа - Курсорный api vs мелкозернистый apis

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

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

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