Книга 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 является посредником между приложением и его клиентами, давайте теперь посмотрим, как реализовать связь между микросервисами.
Это звучит очень похоже на стиль оркестровки, упомянутый выше, только с немного другим намерением, в данном случае, похоже, все дело в производительности и упрощении взаимодействия.
,