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

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

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

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

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

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

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

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

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

в хореографическом стиле автор говорит:

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

примечание: по сей день я все еще не уверен, что хореография - это просто другое название для архитектура, управляемая событиями (EDA), но если EDA-это только один способ сделать это, каковы другие способы? (См. также что вы подразумеваете под "событийным"? и значения архитектуры, управляемой событиями). Также кажется, что такие вещи, как CQRS и EvenSourcing resonate a lot with this architectural style, right?

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

Итак, что насчет HATEOAS?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более Дальнеишее Чтение

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

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