Что такое хорошая практика по продвижению микросервиса в открытый API?

Question

Микросервисы, похоже, очень хорошо подходят для моего программного обеспечения после просмотра и чтения статей статей от Мартина Фаулера, Сэма Ньюмена, Адриана Кокрофта и Sudhir Tones. Однако, если глубже думать о реализации, существует ряд проблем:

1. У моего программного обеспечения есть пользовательский интерфейс, назовем его веб-компонентом. Этот компонент должен будет координировать/организовывать вызовы на 10-20 различных микросервисов внутри (назовем это «частными микросервисами») и вернуть данные на вызов AJAX. Это хороший дизайн для объединения логики оркестровки в этом компоненте? Или я должен создать еще один микросервис, который выполняет задание, и веб-компонент должен быть очень тонким, чтобы делегировать вызов этому микросервису?
2. Мне нужно будет открыть некоторые общедоступные API. Должен ли я иметь отдельный слой для делегирования вызова, как в случае выше?

Я думаю, что это может быть более или менее о шаблоне проектирования для государственных/частных микросервисов.

Что было бы хорошим образцом для решения вышеуказанных проблем?

Обновлено 9 апреля 2015:

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

Чтобы больше узнать о моих выводах, я думаю, что архитектура Netflix имеет так называемый «краевой сервис», который является передним уровнем, который обслуживает запросы, поступающие с веб-устройств или устройств, а службы среднего уровня на самом деле ваши микросервисы. Поэтому я считаю, что продвигать услугу среднего уровня, чтобы быть краевым сервисом, это должен быть делегат. Он будет поддерживать средний уровень и быть последовательным.

Посмотрите на https://github.com/cfregly/fluxcapacitor#project-overview, чтобы иметь больше идей.

Answer 1

Шаблон API Шлюз является хорошим способом для реализации публичного API перед набором microservices: http://microservices.io/patterns/apigateway.html

Answer 2

Эти решения будут определяться двумя проблемами: состоянием и безопасностью (что является конкретным случаем государства).
Состояние: Как вы собираетесь сохранять переходное состояние (т. Е. Материал, который вы запихнули в данные сеанса)? Если вы хотите попытаться сохранить их в пользовательском интерфейсе, тогда вы можете подумать о том, чтобы хранить чистые микросервисы, иначе вам понадобится координирующая «служба» для хранения этого состояния, и это, по необходимости, станет диспетчерским центром.

Безопасность: Аутентификация - это особый случай состояния, который обычно не может быть сохранен в клиенте. Обычно это приводит людей к заявлению, основанному на состоянии. Он также станет движущим фактором для уровня API и уровня веб-приложения. Уровни API должны быть защищены, возможно, с помощью какой-либо схемы токена Auth (посмотрите на OAuth или аналогичный). Проверка этого токена и извлечение пользовательских учетных данных могут быть довольно медленными (сравнительно). Обычно это делается наиболее эффективно при централизованном обслуживании, а не при каждом вызове микросервиса.

Answer 3

Вы можете поместить все логические схемы между длинными транзакциями в Process Manager. Менеджер процессов может подписаться на события, вывести команды из событий и делегировать эту команду другой вашей MS. Все неудачи, с которыми вы можете справиться в Саге. Сага должна выполнять действие компенсации, когда ваша длинная логика вызывает какое-то исключение.

Подробнее о: Process Manager модель и Saga модель.