Распределенные системы. Паттерны проектирования - [16]
kubectl create configmap twem-config --from-file=./nutcracker.yaml Подготовительные мероприятия завершены, и можно развер-нуть наш пример реализации паттерна Ambassador. Определяем группу контейнеров следующим образом:
apiVersion: v1
kind: Pod
metadata:
name: ambassador-example
Глава 3. Паттерн Ambassador 57
spec:
containers:
# Сюда необходимо подставить имя контейнера приложения, например: # - name: nginx
# image: nginx
# Здесь указываем имя контейнера-посла
- name: twemproxy
image: ganomede/twemproxy
command:
- "nutcracker"
- "-c"
- "/etc/config/nutcracker.yaml"
- "-v"
- "7"
- "-s"
- "6222"
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: twem-config
Сначала в группе объявляется контейнер-посол, а конкретный контейнер приложения может быть внедрен в нее позже. Использование паттерна Ambassador для реализации сервиса-посредника В попытке обеспечить переносимость приложения между раз-ными средами (публичным облаком, физическим центром об-работки данных либо частным облаком) основной проблемой становится обнаружение и конфигурирование сервисов. Чтобы понять, что это значит, представьте себе клиентский модуль, хранящий данные в базе данных MySQL. В публичном об-лаке такая база предоставлялась бы по схеме «ПО как сервис» (software-as-a-service, SaaS). В частном облаке, однако же, может 58 Часть I. Одноузловые паттерны проектирования
потребоваться динамически «поднять» новую виртуальную машину или контейнер с MySQL.
Следовательно, переносимое приложение должно иметь воз-можность изучить свое окружение и найти подходящий MySQL-сервер. Такой процесс называется обнаружением сервисов (service discovery), а система, которая выполняет обнаружение и стыковку, называется сервисом-посредником (service broker). Как и в преды-дущих примерах, использование паттерна Ambassador позволяет отделить логику контейнера приложения от логики контейнера-посла сервиса-посредника. Приложение просто подключается к экземпляру сервиса (например, MySQL), работающему на ло-кальном компьютере. Обязанность контейнера-посла сервиса-по-средника заключается в обследовании окружения и опосредова-нии подключения к конкретному экземпляру целевого сервиса. Данный процесс показан на рис. 3.3.
Рис. 3.3. Контейнер-посол сервиса-посредника создает экземпляр MySQL-сервиса
Глава 3. Паттерн Ambassador 59
Использование пат терна Ambassador для проведения экспериментов и разделения запросов
Последний пример приложения с использованием паттерна Ambassador — реализация экспериментов и других видов раз-деления запросов. В эксплуатируемых системах важно иметь возможность разделения запросов, когда некоторая часть запро-сов обрабатывается не основным рабочим сервисом, а его аль-тернативной реализацией. Чаще всего его используют, чтобы проводить эксперименты с новыми или бета-версиями сервиса для определения степени надежности и производительности новой версии сервиса по сравнению с существующей. Кроме того, разделение запросов иногда используется для ду-блирования или деления трафика таким образом, что он рас-пределяется как на рабочую версию ПО, так и на новую, еще не развернутую.
Ответы рабочей системы возвращаются пользователю, а ответы новой версии сервиса игнорируются. Чаще всего такое деление запросов применяется, когда необходимо сымитировать реаль-ную рабочую нагрузку на сервис, не рискуя повлиять на работу пользователей текущей версии.
С учетом предыдущих примеров становится очевидным то, как делитель запросов может взаимодействовать с контейнером приложения для выполнения своей функции. Как и ранее, контейнер приложения просто подключается к сервису, работающему на локальном компьютере. Контей-нер-посол, в свою очередь, получает запросы, проксирует их как рабочей, так и экспериментальной системам, а затем воз-вращает ответы рабочей системы так, как будто сам сделал всю работу.
60 Часть I. Одноузловые паттерны проектирования
Такое разделение ответственности позволяет четко ограничить функциональность и размер кода приложений, содержащихся в контейнерах. Разделение приложения на модули дает возмож-ность использовать контейнер с делителем запросов во многих разных приложениях и с различными настройками. Практикум. Реализация 10%-ных экспериментов
Для эксперимента с разделением запросов воспользуемся веб-сервером nginx. Nginx — мощный, многофункциональный веб-сервер с открытым исходным кодом. Чтобы сконфигурировать nginx для применения в контейнере-после, воспользуемся сле-дующей конфигурацией (обратите внимание, что она рассчита-на на HTTP, но ее легко адаптировать под HTTPS): worker_processes 5;
error_log error.log;
pid nginx.pid;
worker_rlimit_nofile 8192;
events {
worker_connections 1024;
}
http {
upstream backend {
ip_hash;
server web weight=9;