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

server_retry_timeout: 2000

server_failure_limit: 1

servers:

- memcache-0.memcache:11211:1

- memcache-1.memcache:11211:1

- memcache-2.memcache:11211:1

Из конфигурационного файла видно, что запросы к memcache обслуживаются по адресу localhost:6379 , так что контейнер при-ложения может получить доступ к контейнеру-послу. Теперь можно развернуть его в pod-группу к контейнеру-послу с по-мощью Kubernetes-объекта ConfigMap , который можно создать командой kubectl create configmap --from-file=nutcracker.yaml twem-config .

Подготовительные действия завершены, и теперь вы можете развернуть пример реализации паттерна Ambassador. Определите pod-группу контейнеров, которая выглядит следу-ющим образом:

apiVersion: v1

kind: Pod

metadata:

name: sharded-memcache-ambassador

Глава 6. Шардированные сервисы 111

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

Сохраните этот текст в файл с именем memcached-ambassador-pod.yaml , затем разверните его такой командой: kubectl create -f memcached-ambassador-pod.yaml Если не хотите использовать паттерн Ambassador, можно его не использовать. Вместо этого можно развернуть реплицированный сервис маршрутизации запросов шардам . У паттерна Ambassador, по сравнению с этим сервисом, есть свои достоинства и недостат-ки. Ценность сервиса маршрутизации состоит в снижении слож-ности. Вам не придется разворачивать контейнер-посол в каждой pod-группе, которой нужен доступ к шардированному сервису memcache. Доступ к нему может быть получен с помощью име-нованного сервиса с балансировкой нагрузки. У разделяемого сервиса есть и два недостатка. Во-первых, поскольку сервис используется совместно, его придется масштабировать по мере увеличения нагрузки. Во-вторых, разделяемый сервис — допол-нительный участок пути сетевого маршрута, вносящий лишнюю 112Часть II. Паттерны проектирования обслуживающих систем задержку в обработку запросов и занимающий часть пропускной способности распределенной системы.

Чтобы развернуть разделяемый сервис маршрутизации запросов, нужно немного изменить конфигурацию twemproxy, чтобы он принимал запросы во всех интерфейсах, а не только в петлевом: memcache:

listen: 0.0.0.0:11211

hash: fnv1a_64

distribution: ketama

auto_eject_hosts: true

timeout: 400

server_retry_timeout: 2000

server_failure_limit: 1

servers:

- memcache-0.memcache:11211:1

- memcache-1.memcache:11211:1

- memcache-2.memcache:11211:1

Сохраните этот код в файл с именем shared-nutcracker.yaml , затем создайте соответствующий объект ConfigMap с помощью команды kubectl :

kubectl create configmap --from-file=shared-nutcracker.yaml shared-twem-config

Разверните реплицированный сервис маршрутизации запросов шардам:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: shared-twemproxy

spec:

replicas: 3

template:

metadata:

labels:

app: shared-twemproxy

spec:

Глава 6. Шардированные сервисы 113

containers:

- name: twemproxy

image: ganomede/twemproxy

command:

- nutcracker

- -c

- /etc/config/shared-nutcracker.yaml

- -v

- 7

- -s

- 6222

volumeMounts:

- name: config-volume

mountPath: /etc/config

volumes:

- name: config-volume

configMap:

name: shared-twem-config

Сохраните код в файл с именем shared-twemproxy-deploy.yaml , затем разверните реплицированный маршрутизатор запросов шардам с помощью kubectl :

kubectl create -f shared-twemproxy-deploy.yaml Чтобы завершить развертывание маршрутизатора запросов шар-дам, необходимо создать балансировщик нагрузки, обрабатыва-ющий запросы:

kind: Service

apiVersion: v1

metadata:

name: shard-router-service

spec:

selector:

app: shared-twemproxy

ports:

- protocol: TCP

port: 11211

targetPort: 11211

114Часть II. Паттерны проектирования обслуживающих систем Балансировщик нагрузки разворачивается командой kubectl create -f shard-router-service.yaml .

Шардирующие функции

На данный момент мы обсудили процесс проектирования и развертывания просто шардированного и реплицированного шардированного кэша. Настало время уделить внимание тому, каким образом трафик переадресуется тому или иному шарду. Рассмотрим шардированный сервис с десятью независимыми шардами. Дан пользовательский запрос Req . Как выяснить, какой из шардов S с номерами от 0 до 9 должен обработать за-прос? Задача шардирующей функции — определить данное со-ответствие. Шардирующие функции похожи на хеш-функции, с которыми вы наверняка уже сталкивались, например, при из-учении ассоциативных массивов. Действительно, хеш-таблицу в виде массива цепочек можно считать примером шардирован-ного сервиса. Для заданных Req и Shard шардирующая функ-ция должна установить между ними соответствие вида: