Схема агрегирования на шлюзе

Использование шлюза для объединения нескольких отдельных запросов в один общий. Этот шаблон полезен, если клиент должен выполнять несколько вызовов к разным внутренним системам для выполнения операции.

Контекст и проблема

Чтобы выполнить одну задачу, клиенту может потребоваться выполнить несколько вызовов к различным внутренним службам. Приложение, которое использует несколько служб для выполнения задачи, тратит ресурсы на каждый такой запрос. При добавлении новых функций или служб в приложение требуются дополнительные запросы, что повышает требования к ресурсам и сетевые вызовы. Это взаимодействие между клиентом и серверной частью может негативно повлиять на производительность и масштаб приложения. Архитектуры микросервисов сделали эту проблему более распространённой, поскольку приложения, построенные на множестве небольших сервисов, имеют большее число межсервисных вызовов.

На следующей схеме клиент отправляет запросы к каждой службе (нумерованный 1, 2 и 3). Каждая служба обрабатывает запрос и возвращает ответ на приложение (нумерованный 4, 5 и 6). Отправка отдельных запросов таким образом по сотовой сети с высокой задержкой неэффективна и может привести к потере подключения или неполным ответам. Каждый запрос может выполняться параллельно. Однако приложение по-прежнему должно отправлять, ждать и обрабатывать данные для каждого запроса по отдельным подключениям, что повышает вероятность сбоя.

Схема, на которую показан клиент, выполняющий отдельные вызовы к нескольким внутренним службам и получающий отдельные ответы. Стрелки подключают приложение к службам 1, 2 и 3 в обоих направлениях.

Solution

Используйте шлюз, чтобы сократить число вызовов между клиентом и службами. Шлюз получает клиентские запросы, отправляет запросы в различные внутренние системы и объединяет результаты, прежде чем отправлять их клиенту.

Этот шаблон может уменьшить количество запросов, выполняемых приложением для внутренних служб, и повысить производительность приложений по сравнению с сетями с высокой задержкой.

На следующей схеме приложение отправляет запрос к шлюзу (1). Запрос содержит пакет дополнительных запросов. Шлюз раскомпозирует эти запросы и обрабатывает каждый запрос, отправляя его в соответствующую службу (2). Каждая служба возвращает ответ шлюзу (3). Шлюз собирает все ответы служб и отправляет объединенный ответ в приложение (4). Приложение выполняет только один запрос и получает от шлюза только один ответ.

На схеме показано приложение, отправляющее один запрос в шлюз, который вызывает несколько внутренних служб и возвращает агрегированный ответ. Три стрелки указывают от шлюза к сервисам 1, 2 и 3. Три стрелки указывают от служб обратно к шлюзу. Одна стрелка от приложения к шлюзу, а другая стрелка — из шлюза в приложение.

Проблемы и рекомендации

Учитывайте следующие моменты при принятии решения о том, как реализовать этот шаблон.

• Шлюз не должен создавать связанность между внутренними сервисами.

• Шлюз должен находиться рядом со службами серверной части, чтобы уменьшить задержку как можно больше.

• Служба-шлюз может создать единую точку отказа (SPoF). Убедитесь, что шлюз правильно разработан для удовлетворения требований к доступности приложения.

• Шлюз может привести к узким местам. Убедитесь, что шлюз имеет достаточную производительность для обработки текущей нагрузки и может масштабироваться в соответствии с ожидаемым ростом.

• Выполните нагрузочное тестирование шлюза, чтобы не вводить каскадные сбои для служб.

• Реализуйте отказоустойчивую архитектуру, используя такие методы, как bulkhead, размыкание цепи, повторные попытки и тайм-ауты.

• Если один или несколько вызовов служб занимают слишком много времени, можно допустить прерывание по тайм-ауту и вернуть неполный набор данных. Решите, как приложение должно вести себя в этом случае.

• Используйте асинхронные входные и выходные данные (ввода-вывода), чтобы гарантировать, что задержка в серверной части не приводит к проблемам с производительностью в приложении.

• Реализуйте распределенную трассировку с помощью идентификаторов корреляции для отслеживания каждого отдельного вызова.

• Контролируйте метрики запросов и размеры ответов.

• Оцените, можно ли возвращать кэшированные данные в качестве резервной меры при возникновении сбоев.

• Вместо того чтобы создать агрегирование в шлюзе, рассмотрите возможность размещения службы агрегирования за шлюзом. Агрегирование запросов, вероятно, требует иных ресурсов, чем другие службы шлюза, и может повлиять на функции маршрутизации и разгрузки шлюза.

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

• Для выполнения операции клиент должен взаимодействовать с несколькими внутренними службами.

• Клиент может использовать сети, которые имеют значительную задержку, например сотовые сети.

Этот шаблон может быть не подходит, если:

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

• Клиент или приложение находится рядом со службами серверной части и задержкой не является значительным фактором.

Проектирование рабочей нагрузки

Оцените, как использовать шаблон агрегации шлюза при проектировании рабочей нагрузки, чтобы реализовать цели и принципы, рассматриваемые в основных принципах платформы Azure Well-Architected. В следующей таблице приведены рекомендации по использованию этого шаблона для целей каждого компонента.

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и гарантировать, что она восстанавливается до полнофункционального состояния после сбоя.	С помощью этой топологии можно переместить временную обработку сбоев из распределенной реализации между клиентами в централизованную реализацию. - Рекомендации по обработке временных сбоев
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки.	Эта топология часто уменьшает количество точек касания, которые клиент имеет с системой, что сокращает общедоступную область поверхности и точки проверки подлинности. Агрегированные серверные части могут оставаться полностью изолированными от клиентских систем на сетевом уровне. - SE:04 Сегментация - SE:08 Защита ресурсов
Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды.	Этот шаблон позволяет внутренней логике развиваться независимо от клиентов. Такая развязка обеспечивает гибкость, позволяя изменять реализации связанных сервисов или даже источники данных без необходимости менять точки взаимодействия с клиентом. - Инструменты и процессы OE:04
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Эта схема может обеспечивать меньшую задержку, чем схема, в которой клиент устанавливает несколько подключений. Кэширование в реализациях агрегирования сводит к минимуму вызовы внутренних систем. - PE:03 Выберите услуги - PE:08 производительность данных

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Example

Рассмотрим приложение на основе микрослужб, которое предоставляет сводку заказов для клиента. Когда пользователь открывает страницу заказа, приложение должно получить данные из нескольких внутренних служб, таких как служба заказа, служба доставки и служба профилей клиентов.

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

Для решения этой проблемы приложение использует Azure API Management в качестве уровня агрегирования шлюза. Клиент отправляет один запрос в операцию управления API, которая выступает в качестве сборщика сведений о заказе. Затем управление API вызывает вспомогательные интерфейсы API и возвращает единый ответ клиенту.

Эту облегчённую композицию можно реализовать, используя в API Management политику send-request для получения данных из нескольких служб и формирования объединённого ответа. В этом примере серверные службы выполняются в среде Контейнеры приложений Azure и развертывают каждую серверную службу как приложение-контейнер, которое остается скрытым от прямого клиентского доступа.

На схеме стрелка указывает от клиента к управлению API. Другая стрелка идёт от API Management и разветвляется на три стрелки, указывающие на заказ, отгрузку и профиль клиента. Среда приложения показана ниже и справа от профиля клиента. Стрелка указывает от сводки полезной нагрузки к управлению API.

Скачайте файл Visio для этой архитектуры.

Поток запроса выполняет следующие действия.

1. Клиент отправляет запрос в конечную точку сводки заказа, доступную через управление API.

2. Управление API применяет политику, которая собирает данные о заказе, доставке и профиле клиента из внутренних служб.

3. API Management объединяет ответы серверной части в единую полезную нагрузку со сводкой заказа.

4. Управление API возвращает агрегированный ответ клиенту.

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

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

Этот подход хорошо работает, когда шлюз выполняет простую компоновку, преобразование и сборку ответа. Если агрегирование требует специфической бизнес-логики, сложных преобразований или длительно выполняемой оркестрации, вынесите эту функциональность в выделенный специализированный сервис за шлюзом.

Для мониторинга соберите данные телеметрии по полному пути запроса, чтобы можно было сопоставить поведение управления API с задержкой серверной части. Эта видимость важна в шаблоне агрегирования шлюза, так как одна клиентская операция зависит от нескольких внутренних вызовов, а сбои или медленные ответы в любой отдельной зависимости могут повлиять на окончательный агрегированный результат. Используйте Azure Monitor как центральную платформу наблюдения. Собирайте журналы и метрики API Management для шлюза и пути выполнения политик, а также включите мониторинг для приложений-контейнеров, чтобы собирать журналы и метрики приложений из внутренних контейнерных приложений. Направляйте данные телеметрии API Management и серверной части в рабочую область Log Analytics для единых запросов, оповещений и устранения неполадок. С помощью этой телеметрии можно обнаружить шаблоны времени ожидания, определить, какая серверная зависимость вызвала частичный или неудачный ответ, а также создать оповещения для повышенной задержки или скорости ошибок.

Дальнейшие действия

• Использование внешних служб из службы управления API
• Политика отправки запросов
• Документация по контейнерным приложениям

Связанные ресурсы

• Паттерн "Backends for Frontends" (отдельные серверные части для каждого интерфейса)
• Схема разгрузки шлюза
• Схема маршрутизации шлюза