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

Очевидно, недостаточно лишь запустить несколько копий Redis — нам также необходимы имена, по которым к ним мож-но обращаться. Воспользуемся для этого Kubernetes Service, который назначит DNS-имена созданным репликам. Он будет выглядеть следующим образом:

apiVersion: v1

kind: Service

metadata:

name: redis

labels:

app: redis

spec:

ports:

- port: 6379

name: redis

clusterIP: None

selector:

app: redis

Сохраните этот код в файле redis-shards.yaml и разверните полученный файл командой kubectl create -f redis-shards. yaml . Теперь у вас должны появиться DNS-записи для sharded-redis-0.redis , sharded-redis-1.redis и т. д. Воспользуем-ся этими именами для настройки прокси-сервера twemproxy.

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

Это легковесный, высокопроизводительный прокси-сервер для memcached и Redis, который изначально был разработан в Twitter. Его исходный код теперь доступен на GitHub ( https:// github.com/twitter/twemproxy ).

Следующая конфигурация настроит twemproxy на использова-ние созданных нами копий Redis.

redis:

listen: 127.0.0.1:6379

hash: fnv1a_64

distribution: ketama

auto_eject_hosts: true

redis: true

timeout: 400

server_retry_timeout: 2000

server_failure_limit: 1

servers:

- sharded-redis-0.redis:6379:1

- sharded-redis-1.redis:6379:1

- sharded-redis-2.redis:6379:1

Из конфигурационного файла видно, что запросы к Redis об-служиваются по адресу localhost:6379 , так что контейнер прило-жения может получить доступ к контейнеру-послу. Его можно развернуть в «посольскую» группу контейнеров, используя Kubernetes-объект ConfigMap , который можно создать такой командой:

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 — реализация экспериментов и других видов раз-деления запросов. В эксплуатируемых системах важно иметь возможность разделения запросов, когда некоторая часть запро-сов обрабатывается не основным рабочим сервисом, а его аль-тернативной реализацией. Чаще всего его используют, чтобы проводить эксперименты с новыми или бета-версиями сервиса для определения степени надежности и производительности новой версии сервиса по сравнению с существующей. Кроме того, разделение запросов иногда используется для ду-блирования или деления трафика таким образом, что он рас-пределяется как на рабочую версию ПО, так и на новую, еще не развернутую.