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

Azure

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

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

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

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

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

Решение

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

Diagram of the Ambassador pattern

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

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

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

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

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

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

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

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

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

Пример

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

Example of the Ambassador pattern