Шаблон посредника

Создайте службы поддержки, которые отправляют сетевые запросы от имени службы обслуживания клиентов или приложения. Службу посредника проще всего представить как самостоятельный прокси-сервер, размещенный в одной сети с клиентом.

Этот шаблон позволяет перенести общие задачи подключения клиентов, такие как мониторинг, ведение журналов, маршрутизация, обеспечение безопасности (например, поддержка TLS) и шаблоны устойчивости, не ограничиваясь в выборе языка реализации. Он часто используется с устаревшими приложениями или другими приложениями, которые трудно изменить, чтобы расширить их сетевые возможности. Также он позволяет создать команду специалистов в узкой области для реализации таких возможностей.

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

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

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

Решение

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

Переданные посреднику функции доступны для управления независимо от приложения. Посредник можно легко обновить и (или) изменить, не вмешиваясь в работу существующих компонентов приложения. Кроме того, вы сможете создать отдельные команды специалистов для внедрения и обслуживания функций безопасности, сети и (или) аутентификации, которые переданы посреднику.

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

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

• Использование посредника сопровождается дополнительной задержкой. Возможно, рациональнее будет использовать клиентскую библиотеку, которую приложение вызывает напрямую.
• Определите, как обобщение компонентов, перемещаемых в посредник, может повлиять на работу. Например, если в посреднике реализован механизм повторных попыток, это может быть небезопасно для операций, не являющихся идемпотентными.
• Рассмотрим механизм, позволяющий клиенту передавать определенный контекст прокси-серверу и вернуться клиенту. Например, добавьте специальный заголовок HTTP-запроса, позволяющий запретить повторные попытки или ограничить их количество.
• Рассмотрим, как упаковывать и развертывать прокси-сервер.
• Выберите количество экземпляров: один общий для всех клиентов или по одному для каждого клиента.

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

Используйте эту схему в следующих случаях:

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

Эту схему не стоит применять в следующих случаях:

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

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

Архитектор должен оценить, как шаблон посла можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

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

Пример

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

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

• Sidecar pattern (Шаблон расширения)