Б Бёрнс - Распределенные системы. Паттерны проектирования

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;

server experiment;

}

server {

listen localhost:80;

location / {

proxy_pass http://backend;

}

}

Глава 3. Паттерн Ambassador 61

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

вать с приложением единообразно.

Весовой коэффициент используется, чтобы 90 % трафика при-ходилось на основное приложение, а 10 % — на тестовую версию. Как и в других примерах, мы будем разворачивать данную кон-фигурацию как объект ConfigMap в Kubernetes. kubectl create configmaps --from-file=nginx.conf Она исходит из того, что сервисы web и experiment уже опре-делены. Если это не так, то вам необходимо их создать до создания контейнера-посла, поскольку nginx не запустится корректно, если не сможет найти сервисы, которым он про-ксирует запросы.

Вот несколько примеров конфигурации:

# Сервис 'experiment'

apiVersion: v1

kind: Service

metadata:

name: experiment

62Часть I. Одноузловые паттерны проектирования

labels:

app: experiment

spec:

ports:

- port: 80

name: web

selector:

# Установите значение данного селектора в соответствии # с метками вашего приложения

app: experiment

---

# Сервис 'prod'

apiVersion: v1

kind: Service

metadata:

name: web

labels:

app: web

spec:

ports:

- port: 80

name: web

selector:

# Установите значение этого селектора в соответствии # с метками вашего приложения

app: web

Затем разворачиваем nginx в роли посла в рамках контейнера: apiVersion: v1

kind: Pod

metadata:

name: experiment-example

spec:

containers:

# Сюда необходимо подставить имя контейнера приложения, # например: