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

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

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

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

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

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

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

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

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

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

Под стилем хореографии автор говорит:

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

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

Теперь, после этого наступает самое интересное. В книге "микросервисы" не предполагается, что микросервисы будут реализованы с помощью ОСТАЛЬНОЕ. На самом деле в следующем разделе книги они переходят к рассмотрению решений на основе RPC и SOA и, наконец, отдыхают. Важным моментом здесь является то, что микросервисы не подразумевают отдыха.

Так что насчет ХАТЕОАСА?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• введение в микрослужбы
• построение микросервисов: использование API Шлюз
• построение микросервисов: IPC в архитектуре микросервисов
• обнаружение служб в архитектуре микросервисов
• событийное управление данными для микросервисов
• выбор стратегии развертывания микросервисов
• рефакторинг Монолита в микросервисы