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

Вот некоторые из более ранних блогов серии 101:

API 101
Асинхронная связь 101 Базы данных 101 Проектирование баз данных 101 Стратегии развертывания 101

Что такое паттерн «Амбассадор»?

Ambassador — это особый случай шаблона s side-car, который разгружает общие функции подключения клиента, такие как мониторинг, ведение журнала, маршрутизация, безопасность, отказоустойчивость, с помощью общего совмещенного сервиса/контейнера (в случае развертываний на основе Kubernetes/Docker). Посольская служба действует как многоразовое прокси-решение для устаревших служб, написанных на нескольких языках и платформах, предлагая функции L7, такие как повторная попытка HTTP, шаблон прерывателя цепи, изменение заголовков запросов и т. д. Посольские версии и инфраструктура могут быть выпущены и масштабированы независимо от бизнеса. приложения/контейнеры, что делает его подходящим выбором для закрытия нефункциональных потребностей бизнес-доменов.

Амбассадор в качестве коляски

Последовательность операций

1. Контейнер приложения отправляет запрос удаленной службе B/службе C через прокси-сервер Ambassador .
2. Proxy SideCar добавляет информацию о трассировке в заголовки запроса. Также шифрует запрос, добавляя сертификаты для взаимного TLS . Дополнительно начинает измерять задержку запроса.
3. Удаленная служба B/служба C получает запрос и проверяет заголовки запроса перед отправкой ответного сообщения.
4. Дополнительный автомобиль Ambassador получает ответ и регистрирует задержку запроса.
5. Контейнер приложения получает окончательный ответ обратно.

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

Ограничения

1. Запросы приложений, которые имеют критические требования к задержке и туда и обратно, могут быть затронуты дополнительным прокси-сервером.
2. Приложения, которые имеют возможность подключения, должны быть глубоко интегрированы с клиентским кодом/языком, а изоляция запросов через прокси-сервер не масштабируется.

Мы обсудили основы шаблона Ambassador, который является популярным шаблоном проектирования, который помогает модернизировать потребности устаревших приложений без создания интегрированного решения на основе сервисной сетки end-2-end. В мире Kubernetes прокси-сервер Ambassador можно развернуть, используя в качестве файла манифеста службы, и масштабировать вместе с модулями приложений.

Чтобы оставить отзыв, отправьте сообщение на адрес amit[dot]894[at]gmail[dot]com или воспользуйтесь любой из ссылок на странице https://about.me/amit_raj .