В книге Создание микросервисов подробно описаны стили, упомянутые @RogerAlsing в своем ответе.
На странице 43 в разделе «Оркестровка против хореографии» в книге говорится:
По мере того, как мы начинаем моделировать все более и более сложную логику, нам приходится иметь дело с проблемой управления бизнес-процессами, которые выходят за рамки отдельных сервисов. А с микросервисами мы достигнем этого предела раньше, чем обычно. [...] Когда дело доходит до фактической реализации этого потока, есть два стиля архитектуры, которым мы могли бы следовать. В оркестровке мы полагаемся на центральный мозг, который направляет и управляет процессом, как дирижер в оркестре. С помощью хореографии мы информируем каждую часть системы о ее работе и позволяем ей прорабатывать детали, как будто все танцоры находят свой путь и реагируют на окружающих в балете.
Затем книга переходит к объяснению двух стилей. Стиль оркестрации больше соответствует идее SOA служб оркестровки / задач, тогда как стиль хореографии соответствует < href = "http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes" rel = "noreferrer"> тупые каналы и интеллектуальные конечные точки, упомянутые в статье Мартина Фаулера.
Стиль оркестровки
В соответствии с этим стилем в книге выше упоминается:
Давайте подумаем, как будет выглядеть решение для оркестрации этого потока. Здесь, вероятно, проще всего было бы сделать так, чтобы наша служба поддержки клиентов действовала как центральный мозг. При создании он обращается к банку бонусных баллов, электронной почте и [...] почтовой службе посредством серии запросов / ответов. После этого служба поддержки клиентов может отслеживать, где находится клиент в этом процессе. Он может проверить, настроена ли учетная запись клиента, отправлено ли электронное письмо или доставлено ли сообщение. Мы должны взять блок-схему [...] и смоделировать ее прямо в коде. Мы могли бы даже использовать инструменты, которые реализуют это за нас, возможно, используя соответствующий механизм правил. Для этого существуют коммерческие инструменты в виде программного обеспечения для моделирования бизнес-процессов. Предполагая, что мы используем синхронный запрос / ответ, мы могли бы даже знать, работает ли каждый этап [...] Обратной стороной этого подхода к оркестровке является то, что служба поддержки клиентов может превратиться в центральный управляющий орган. Он может стать центром сети и центральной точкой, в которой начинает жить логика. Я видел, как этот подход привел к тому, что небольшое количество умных «божьих» сервисов указывало анемичным сервисам на основе CRUD, что им делать.
Примечание. Я полагаю, что, когда автор упоминает инструменты, он имеет в виду что-то вроде BPM (например, Activity, Apache ODE , Камунда). На самом деле, на веб-сайте шаблонов рабочих процессов есть отличный набор шаблонов для такого рода оркестровки, а также предлагается оценка подробности о различных инструментах поставщиков, которые помогают реализовать это таким образом. Я не думаю, что автор подразумевает, что для реализации этого стиля интеграции требуется использовать один из этих инструментов, хотя можно использовать и другие легкие структуры оркестровки, например. Spring Integration, Apache Camel или ESB Mule
Тем не менее, другие книги, которые я прочитал по теме микросервисов и в целом большинство статей, которые я нашел в Интернете, кажутся в нежелании этот подход оркестровки и вместо этого предлагаем использовать следующий.
Стиль хореографии
О стиле хореографии автор говорит:
При хореографическом подходе мы могли бы вместо этого просто заставить службу поддержки клиентов генерировать событие асинхронно, говоря, что Клиент создан. Служба электронной почты, почтовая служба и банк баллов лояльности затем просто подписываются на эти события и реагируют соответствующим образом [...] Этот подход значительно более разделен. Если какой-то другой сервис нужен для создания клиента, ему просто нужно подписаться на события и выполнять свою работу, когда это необходимо. Обратной стороной является то, что явное представление бизнес-процесса, которое мы видим в [рабочем процессе], теперь только неявно отражается в нашей системе [...] Это означает, что требуется дополнительная работа, чтобы вы могли контролировать и отслеживать, что нужные вещи произошло. Например, знаете ли вы, есть ли в банке бонусных баллов ошибка и по какой-то причине не создается правильный аккаунт? Один из подходов, которые мне нравятся для решения этой проблемы, - это создание системы мониторинга, которая явно соответствует представлению бизнес-процесса в [рабочем процессе], но затем отслеживает, что каждая из служб делает как независимые объекты, позволяя вам видеть нечетные исключения, отображаемые на более явный поток процесса. [Блок-схема] [...] - это не движущая сила, а всего лишь одна линза, через которую мы можем увидеть, как ведет себя система. В целом, я обнаружил, что системы, которые больше склоняются к хореографическому подходу, более слабо связаны, более гибки и поддаются изменениям. Однако вам нужно проделать дополнительную работу, чтобы контролировать и отслеживать процессы, происходящие за пределами системы. Я обнаружил, что наиболее сильно оркестрированные реализации являются чрезвычайно хрупкими и требуют более высоких затрат на изменение. Имея это в виду, я настоятельно предпочитаю стремиться к хореографической системе, в которой каждая услуга достаточно умна, чтобы понимать свою роль во всем танце.
Примечание. Я до сих пор не уверен, что хореография - это просто другое название для архитектура, управляемая событиями (EDA), но если EDA - это всего лишь один из способов сделать это, каковы другие способы? (Также см. Что вы имеете в виду под "управляемым событиями"? и Значения событийно-ориентированной архитектуры). Кроме того, кажется, что такие вещи, как CQRS и EventSourcing, сильно перекликаются с этим архитектурным стилем, верно?
А теперь самое интересное. Книга «Микросервисы» не предполагает, что микросервисы будут реализованы с помощью REST. Фактически, в следующем разделе книги они перейдут к рассмотрению решений на основе RPC и SOA и, наконец, REST. Важным моментом здесь является то, что микросервисы не подразумевают 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 решает, по какой ссылке перейти, и переводит приложение в следующее состояние.
Несмотря на то, как это круто звучит, клиенту все равно нужно знать, должна ли ссылка быть размещена, помещена, получена, исправлена и т. Д. И клиент все еще должен решить, какую полезную нагрузку передать. Клиент по-прежнему должен знать, что делать в случае неудачи (повторить попытку, компенсировать, отменить и т. Д.).
Я новичок во всем этом, но для меня, с точки зрения HATEOAs, этот клиент или потребитель API - это услуга высокого уровня. Если мы рассмотрим это с точки зрения человека, вы можете представить себе конечного пользователя на веб-странице, решающего, по каким ссылкам переходить, но все же программист веб-страницы должен был решить, какой метод использовать для вызова ссылок. и какую полезную нагрузку передать. Итак, на мой взгляд, при взаимодействии компьютера с компьютером компьютер играет роль конечного пользователя. И снова это то, что мы называем услугой оркестровки.
Я полагаю, мы можем использовать HATEOAS как с оркестровкой, так и с хореографией.
Шаблон шлюза API
Другой интересный шаблон предложил Крис Ричардсон, который также предложил то, что он назвал шаблоном шлюза API.
В монолитной архитектуре клиенты приложения, такие как веб-браузеры и собственные приложения, отправляют HTTP-запросы через балансировщик нагрузки к одному из N идентичных экземпляров приложения. Но в микросервисной архитектуре монолит был заменен набором сервисов. Следовательно, ключевой вопрос, на который нам нужно ответить, - с чем взаимодействуют клиенты?
Клиент приложения, например собственное мобильное приложение, может выполнять HTTP-запросы RESTful к отдельным службам [...] На первый взгляд это может показаться привлекательным. Однако, вероятно, будет существенное несоответствие в гранулярности между API-интерфейсами отдельных служб и данными, требуемыми клиентами. Например, для отображения одной веб-страницы потенциально может потребоваться обращение к большому количеству служб. Amazon.com, например, описывает, как некоторые страницы требуют обращения к более чем 100 службам. Выполнение такого количества запросов даже через высокоскоростное интернет-соединение, не говоря уже о мобильной сети с низкой пропускной способностью и большими задержками, было бы очень неэффективным и привело бы к неудовлетворительному взаимодействию с пользователем.
Намного лучший подход заключается в том, чтобы клиенты отправляли небольшое количество запросов на страницу, возможно, всего один, через Интернет на интерфейсный сервер, известный как шлюз API.
Шлюз API находится между клиентами приложения и микросервисами. Он предоставляет API-интерфейсы, адаптированные к клиенту. Шлюз API предоставляет крупнозернистый API для мобильных клиентов и более детальный API для настольных клиентов, использующих высокопроизводительную сеть. В этом примере настольные клиенты делают несколько запросов для получения информации о продукте, тогда как мобильный клиент делает один запрос.
Шлюз API обрабатывает входящие запросы, отправляя запросы определенному количеству микросервисов через высокопроизводительную локальную сеть. Netflix, например, описывает, как каждый запрос распространяется на в среднем шесть серверных сервисов. В этом примере подробные запросы от настольного клиента просто проксируются соответствующей службе, тогда как каждый крупномасштабный запрос от мобильного клиента обрабатывается путем агрегирования результатов вызова нескольких служб.
Шлюз API не только оптимизирует обмен данными между клиентами и приложением, но также инкапсулирует детали микросервисов. Это позволяет микросервисам развиваться, не влияя на клиентов. Например, можно объединить два микросервиса. Другой микросервис может быть разделен на две или более службы. Необходимо обновить только шлюз API, чтобы отразить эти изменения. Клиенты не пострадают.
Теперь, когда мы рассмотрели, как шлюз API является посредником между приложением и его клиентами, давайте посмотрим, как реализовать связь между микросервисами.
Это звучит очень похоже на упомянутый выше стиль оркестровки, только с немного другим намерением, в данном случае, похоже, все дело в производительности и упрощении взаимодействий.
person
Edwin Dalorzo
schedule
25.05.2015
.