Выполнение запросов с помощью объединения API¶

Рассмотрим в качестве примера запрос findOrder(). Он принимает orderId в качестве параметра и возвращает объект orderDetails с информацией о заказе. К примеру, операция вызывается неким клиентским модулем для представления Order Status — это основная информация о состоянии заказа, включая статус платежа, статус выполнения заявки с т.з. ресторана, а также местоположении и предполагаемым временем доставки, если заказ уже в пути.

В микросервисной архитектуре эта информация разбросана по таким сервисам:

• Order — основная информация
• Kitchen — статус заказа с т.з. ресторана и то, когда он должен быть готов к доставке
• Delivery — состояние доставки заказа, предполагаемое время доставки, координаты курьера
• Accounting — состояние оплаты заказа

Для реализации такого запроса используем шаблон объединение API.
Логично предположить, что у каждого сервис-провайдера есть ручка для извлечения нужных данных по orderId. API-Композитор обращается к четырём сервисам, каждый из которых отдаёт данные своего агрегата и объединяет полученные результаты.

Архитектурные проблемы¶

При использовании этого шаблона нужно решить две проблемы, а именно:

• Какой компонент будет выступать API-композитором
• Как написать эффективную логику агрегации

Кто играет роль API-композитора¶

Есть три кандидата на эту роль.
1. Клиент, такой как веб-приложение. Этот вариант имеет смысл, когда клиент находится в той же сети, что и сервис-провайдеры, и может не подойти для клиентов, использующих медленную сеть.
2. API-шлюз, реализующий внешний API приложения. Этот вариант подходит, если операция запроса входит в состав внешнего API. Вместо перенаправления запросов к другому сервису шлюз реализует логику объединения API.
3. Отдельный сервис. Этот вариант следует использовать для запросов от внутренних сервисов, либо если логика агрегации слишком сложна для того, чтобы делать ее частью API-шлюза.

Важно! По возможности API-композитор должен распараллеливать запросы к сервис-провайдерам. Однако, иногда требуется использовать результат одного запроса для построения другого, что усложняет логику композитора.
Для того, чтобы композитор, был прост в обслуживании, но при этом быстро работал и хорошо масштабировался, нужно использовать реактивную модель программирования.

Комментарии

Комментарии