Spring Cloud, Netflix OSS — оркестровка микросервисов

Недавно я начал проект, который включает в себя разработку архитектуры микросервисов с помощью Spring Cloud и Netflix OSS. Микросервисы поддерживают RESTful и генерируют ответы JSON.

Цель состоит в том, чтобы скомпоновать результаты JSON каждого микросервиса (они могут быть зависимостями между ними, например, Service_B нужны выходные данные Service_A для завершения своих вычислений) и представить их конечному пользователю с помощью пользовательского интерфейса (т. е. Angular.js single страница).

В качестве справки я следовал руководству callista enterprise, в котором состав трех типовых микросервисов (продукт, рекомендация, обзор) выполняется другим микросервисом под названием "product-composite", который в основном выполняет последовательность HTTP-вызовов. к другим микросервисам.

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

Возникает вопрос: каков наилучший/подходящий подход к созданию/аранжировке микросервисов в структурированном потоке?

Я искал компоновку каждой службы на одной странице Angular.js, но меня беспокоит раскрытие каждой микрослужбы снаружи, поскольку желательно вызвать одну конечную точку API (скажем, /report) и получить все необходимые вычисления.

Другой вариант кажется Spring Integration, но я не могу найти документацию, в которой разъясняется, как сопоставить эту архитектуру с этой технологией.

Любые советы, руководства, ссылки и предложения будут действительно оценены. Спасибо за вашу поддержку.

Лука


comment
Почему вы считаете, что он не масштабируется и нужно много менять, когда приходит сервис?   -  person daniel.eichten    schedule 17.06.2016
comment
Да, пожалуйста, опишите, как это не масштабируется.   -  person spencergibb    schedule 17.06.2016
comment
Привет, ребята, спасибо за ответ. На самом деле меня беспокоит этот подход в том смысле, что в руководстве, которому я следовал, служба составления продуктов выполняет последовательность блокирующих http-запросов к другим микрослужбам, прежде чем дать результат. Не является ли этот подход неэффективным в случае сложной цепочки вызовов (этакое узкое место)? С другой стороны, если включается новая служба, мне нужно изменить код службы композиции. Вы считаете, что мои рассуждения ошибочны?   -  person Luca    schedule 18.06.2016
comment
Есть новости по этому поводу? :)   -  person Luca    schedule 21.06.2016


Ответы (1)


Ваш вопрос больше касается оркестровки служб, а не масштабирования. Нельзя отрицать, что если вы добавите больше сервисов, вы в конечном итоге измените уровень оркестровки — этого никак не избежать. Для оркестровки служб, привязанной к конкретным требованиям пользовательского интерфейса, см. шаблон BFF (бэкенд для интерфейса). Масштабирование - это другой аспект - это больше касается системы, настраивающей себя по мере того, как становится доступным больше экземпляров с минимальным вмешательством или без вмешательства.

person Sabapathy Paramasivan    schedule 12.01.2017