В книге Building Microservices подробно описаны стили, упомянутые @RogerAlsing в его ответе.
На странице 43 под оркестровке против Хореография книги говорит:
Как мы начинаем моделировать все более и более сложной логики, мы имеем дело с проблема управления бизнес-процессами, которые простираются через границы индивидуальных услуг. И с микросервисами мы нажмем этот предел раньше обычного. [...] Когда дело доходит до фактического , реализующего этот поток, есть два стиля архитектуры, которые мы могли бы выполнить . С оркестровкой мы полагаемся на центральный мозг для руководства, и управляют процессом, очень похожим на дирижера в оркестре. С хореографией мы сообщаем каждую часть системы своей работы, и давайте расскажем подробности, как танцоры, которые все находят свой путь, и реагируют на окружающих вокруг себя в балете.
Затем в книге объясняется два стиля. Стиль оркестровки больше соответствует идее SOA orchestration/task services, тогда как стиль хореографии соответствует dumb pipes and smart endpoints, упомянутому в статье Мартина Фаулера.
аранжировка Стиль
В соответствии с этим стилем, книга выше упоминает:
Давайте подумаем о том, что оркестровка решение будет выглядеть для этого потока. Здесь, вероятно, самой простой задачей было бы иметь наш сервис обслуживания клиентов как центральный мозг. При создании он рассказывает банку лояльности, почтовому сервису и почтовому сервису [...], через серию запросов/ответов. Служба сама может отслеживать, где находится клиент в этом процессе . Он может проверить, была ли установлена учетная запись клиента , или отправленное электронное письмо, или отправленное сообщение.Мы получаем блок-схему [...] и моделируем ее непосредственно в коде. Мы могли бы даже использовать оснастку , которая реализует это для нас, возможно, используя соответствующий механизм правил . Коммерческие инструменты существуют для этой цели в форме программного обеспечения для моделирования бизнес-процессов. Предполагая, что мы используем синхронный запрос/ответ , мы могли бы даже знать, работал ли каждый этап [...] Недостатком этого подхода оркестровки является то, что сервис может стать слишком большим авторитетом центрального органа управления. Он может стать центром в центре сети и центральной точкой, где начинается логика . Я видел этот подход в небольшом количестве умных сервисов «бог», рассказывающих анемичные службы на основе CRUD, что делать.
Примечание: Я полагаю, что, когда автор упоминает набор инструментов, он имеет в виду что-то вроде BPM (например Activity, Apache ODE). На самом деле у Workflow Patterns Website есть удивительный набор шаблонов для такого рода оркестровки, а также подробные сведения об оценках различных инструментов поставщика, которые помогают реализовать его таким образом. Я не думаю, что автор предполагает, что один из этих инструментов должен использовать один из этих инструментов для реализации этого стиля интеграции, хотя можно использовать другие легкие структуры оркестровки, например. Spring Integration, Apache Camel или Mule ESB
Однако other books я прочитал на тему Microservices и в целом большинство статей, которые я нашел в Интернете, кажется, disfavor this approach оркестровки и вместо этого предлагают использовать следующий.
Хореография Стиль
Под стилем хореографии автор говорит:
С хореографией подходом, мы могли бы вместо того, чтобы просто иметь обслуживание клиентов испускает событие в асинхронном режиме, говоря Клиент создано. Почтовый сервис, почтовая служба и лояльность точек банка затем просто подпишитесь на эти события и отреагируйте соответственно [...] Этот подход значительно более развязан. Если какой-либо другим службам необходимо связаться с созданием клиента, ему просто нужно подписаться на мероприятия и выполнять свою работу по мере необходимости. Недостатком является то, что явный вид бизнес-процесса, который мы видим в [рабочий процесс], теперь неявно отражается в нашей системе [...] Это означает, что необходима дополнительная работа, чтобы вы могли контролировать и отслеживать, что правильные вещи произошли. Например, знаете ли вы, что у банка лояльности есть ошибка, и почему-то не установили правильную учетную запись? Один из подходов, который мне нравится в работе с этим , заключается в создании системы мониторинга, которая явно соответствует представлению бизнес-процесса в [рабочем процессе], но затем отслеживает, что каждый из услуг выполняет как независимые объекты, позволяя вам видеть нечетные исключения отображаются на более явный поток процесса. [Блок-схема] [...] не является движущей силой, а только одним объективом через , который мы видим, как система ведет себя. В общем, я нашел , что системы, которые больше стремятся к хореографическому подходу, более слабо связаны и более гибки и пригодны для изменения. Вы делаете необходимо сделать дополнительную работу для мониторинга и отслеживания процессов в системе границ.Я обнаружил, что наиболее интенсивно реализовано реализаций, чтобы быть чрезвычайно хрупкими, с более высокой стоимостью изменений. Имея это в виду, я решительно настроен на создание хореографической системы , где каждая услуга достаточно умна, чтобы понять ее роль в танце .
Примечание: Это очень похоже на CQRS и EvenSourcing. По сей день я все еще не уверен, что хореография - это просто другое имя для event-driven architecture (EDA), но если EDA - это всего лишь один способ сделать это, каковы другие способы? (См. Также What do you mean by "Event-Driven"? и The Meanings of Event-Driven Architecture)
Теперь, после этого, начинается веселье. Книга Microservices не предполагает, что микросервисы будут реализованы с помощью REST. По сути, в следующем разделе книги они приступают к рассмотрению решений RPC и SOA и, наконец, REST. Важным моментом здесь является то, что Microservices не подразумевает REST.
Итак, что относительно HATEOAS?
Теперь, если мы хотим следовать подходу RESTful, мы не можем игнорировать HATEOAS, или Рой Филдинг будет очень рад сообщить в своем блоге, что наше решение не является действительно REST. Посмотрите на его блоге на REST API Must be Hypertext Driven:
Я получаю разочарование по количеству людей, призывающих любой HTTP на основе интерфейс REST API. Что нужно сделать, чтобы сделать архитектурный стиль REST понятным тем, что гипертекст - это ограничение ? Другими словами, если двигатель состояния приложения (и , следовательно, API) не управляется гипертекстом, то он не может быть RESTful и не может быть REST API. Период. Есть ли какая-то неисправная инструкция где-то, что нужно исправить?
Итак, как вы можете видеть, Филдинг считает, что без HATEOAS вы действительно не строите приложения RESTful. Для полетов HATEOAS - это способ пойти, когда дело доходит до организации сервисов. Я просто изучаю все это, но для меня HATEOAS не ясно определяет, кто или что является движущей силой, фактически завязанной по ссылкам. В пользовательском интерфейсе, который может быть пользователем, но в взаимодействиях между компьютерами, я полагаю, что это должно выполняться службой более высокого уровня.
Согласно HATEOAS, единственной ссылкой, которую действительно должен знать пользователь API, является тот, который инициирует связь с сервером (например, POST/order). С этого момента REST собирается провести поток, потому что в ответе этой конечной точки возвращаемый ресурс будет содержать ссылки на следующие возможные состояния. Затем пользователь API решает, какую ссылку следовать и переместить приложение в следующее состояние.
Несмотря на то, что это звучит круто, клиенту все еще нужно знать, должна ли быть ссылка на POSTED, PUTED, GETED, PATCHED и т. Д. И клиент все равно должен решить, какую полезную нагрузку передать. Клиент все равно должен знать, что делать, если это не удается (повторите попытку, компенсируйте, отмените и т. Д.).
Я довольно новичок в этом, но для меня, с точки зрения HATEOAs, этот клиент или пользователь API - это сервис высокого уровня. Если мы думаем об этом с точки зрения человека, вы можете представить конечного пользователя на веб-странице, решив, какие ссылки следовать, но тем не менее программист веб-страницы должен был решить, какой метод использовать для вызова ссылок, и что полезная нагрузка. Итак, на мой взгляд, при взаимодействии компьютера с компьютером компьютер выполняет роль конечного пользователя. Еще раз это называется услугой оркестровки.
Предположим, мы можем использовать HATEOAS с оркестровкой или хореографией.
API-интерфейс шлюза шаблон
Еще один интересный образец предлагается Крис Ричардсон, который также предложил, что он назвал API Gateway Pattern.
В монолитной архитектуры, клиенты приложения, такие как веб-браузеры и нативных приложений, сделать HTTP запросы через нагрузки балансира к одному из N идентичных экземпляров приложения. Но в архитектуре микросервиса монолит был заменен набором услуг . Следовательно, ключевым вопросом, который нам нужно ответить , является то, с чем клиенты взаимодействуют?
Клиент приложения, такой как родное мобильное приложение, может сделать RESTful HTTP-запросы к отдельным услугам [...] На поверхности это может показаться привлекательным. Тем не менее, вероятно, будет значительное несоответствие между API API отдельных и данными, требуемыми клиентами. Например, при отображении одной веб-страницы потенциально могут потребоваться вызовы для большого количества услуг. Amazon.com, например, describes Как некоторые страницы требуют звонков в 100+ сервисов. Создание большого количества запросов, даже , по высокоскоростному подключению к Интернету, не говоря уже о более низкой пропускной способности, мобильной сети с более высокой задержкой, было бы очень неэффективным и приводило бы к плохой работе пользователя в .
Более удобный подход заключается в том, чтобы клиенты могли сделать небольшое количество запросов на странице, возможно, всего лишь один, через Интернет до интерфейсного сервера, известного как шлюз API.
Шлюз API расположен между клиентами приложения и микросервисами . Он предоставляет API-интерфейсы, адаптированные к клиенту. Маршрутизатор API предоставляет крупнозернистый API для мобильных клиентов и более тонкий API для настольных клиентов, которые используют высокопроизводительную сеть . В этом примере клиенты настольных компьютеров выполняют множественные запросы для получения информации о продукте, где в качестве мобильного клиента делает один запрос.
Шлюз API обрабатывает входящие запросы, отправляя запросы на некоторое количество микросервисов на высокопроизводительную локальную сеть с . Netflix, для пример, describes Как каждый запрос отправляется в среднем на шесть бэкэнд-услуг. В этом примере мелкозернистые запросы от настольного клиента - это просто , проксированные соответствующей службе, тогда как каждый крупнозернистый запрос от мобильного клиента обрабатывается путем агрегирования результатов , вызывающих несколько сервисов.
Не только шлюз API оптимизирует связь между клиентами и приложение, но также инкапсулирует детали микросервисов . Это позволяет микросервисам развиваться без , влияющих на клиентов.Например, два микросервиса могут быть объединены в . Другой микросервис может быть разделен на две или более услуг. Необходимо обновить только шлюз API, чтобы отразить эти изменения . Клиенты не подвержены влиянию.
Теперь, когда мы рассмотрели, как шлюз API обеспечивает посредничество между приложением и его клиентами , давайте теперь рассмотрим, как реализовать связь между микросервисами.
Это звучит очень похоже на стиль оркестровки, упомянутый выше, только с немного отличающимся намерением, в этом случае, похоже, речь идет о производительности и упрощении взаимодействий.
Дальнейшее чтение
Существует большая серия статей недавно опубликованных в NGINX Blog, что я рекомендую глубже вникать все эти понятия:
.
Хороший ответ! Один вопрос: если я объединю Microservices в стиле хореографии с API-шлюзом, разве API-шлюз не превратится в центральный орган управления, который вы описываете как недостаток микросервисов в стиле оркестрового? Или, другими словами, где именно заключается разница между «Стиль оркестровки» и API-Gateway Pattern? –
@FritzDuchardt не совсем. Хотя api-gateway становится единственной точкой отказа, он не обязательно является управляющим органом любого рода. Очень простой api-gateway может просто аутентифицировать запросы и прокси-серверы их целевой службе. Шаблон api-gateway предназначен, в основном, для упрощения взаимодействия клиент-бэкэнд с помощью единой службы, он не решает проблему организации или хореографии служб, к которым доверяет API-шлюз (который сам является сервисом). – Porlune
Отличный ответ! Только один вопрос относительно шлюзов API: Является ли GraphQL шлюзом API следующего поколения и может очень хорошо заменить шлюзы API? – kenneho