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

Первый шаг в событийно-ориентированном потоке задач — от-правка проверочного письма. Чтобы обеспечить его надежную реализацию, нужно сопоставить потенциальных пользователей одной из географических зон. Это позволит продолжать прини-

мать новых пользователей даже в условиях частичного отказа подсистемы регистрации. Каждый шард отправляет конечным пользователям проверочные письма. Первый этап потока за-вершен. Схема первого этапа приводится на рис. 11.8.

Рис. 11.8. Первый этап потока задач по регистрации нового пользователяПоток возобновляется при получении подтверждения от поль-зователя. Оно становится событием в отдельном (но связанном) потоке задач, который отправляет подтверждения и настраивает уведомления. Первый его этап служит примером реализации 200Часть III. Паттерны проектирования систем пакетных вычислений паттерна Copier, распределяющего пользователей в две очере-ди. Первая очередь задач отвечает за отправку приветственных электронных писем, а вторая — за настройку уведомлений. Как только задачи были распределены в две очереди, очередь на от-правку письма отправляет сообщение, и на этом данная ветвь пото-ка завершается. Но за счет использования паттерна Copier активна еще одна ветвь потока задач. Она связана с обработкой настроек уведомлений. Данная очередь задач относится к контейнеру-филь-тру, который делит ее на очереди подписки на почтовые и СМС-уведомления. Соответствующие очереди задач подписывают поль-зователей на уведомления по электронной почте и/или СМС. Оставшаяся часть потока задач приводится на рис. 11.9.

Рис. 11.9. Очередь задач по уведомлению пользователей и рассылкеприветственных электронных писем

Глава 11. Событийно-ориентированная пакетная обработка 201Инфраструктура publish/subscribe Мы рассмотрели много разных паттернов, связывающих реа-лизации паттернов событийно-ориентированной пакетной обработки. При фактической реализации подобной системы приходится решать, каким образом управлять потоком данных, идущим параллельно потоку задач. Проще всего будет записы-вать каждый элемент очереди задач в определенном каталоге локальной файловой системы, за появлением новых задач в ко-тором выполняется наблюдение на конкретном этапе обработки. Использование локальной файловой системы ограничивает рабочую область одним узлом. Можно воспользоваться сетевой файловой системой, распределяющей файлы между множе-ством узлов, но это усложняет и код приложения, и процесс его развертывания.

При реализации подобных потоков задач принято использовать API или сервис типа pub/sub (publish/subscribe, публикация/ подписка). API pub/sub позволяет определить набор очередей, иногда называемых темами . Один издатель или более публи-куют в этих очередях сообщения. По аналогии один подписчик или более «прослушивают» их в ожидании новых сообщений. После опубликования сообщение надежно хранится в очереди и таким же надежным образом доставляется подписчикам. На сегодняшний день большинство публичных облачных провайдеров предоставляют pub/sub-API, к примеру Azure EventGrid или Amazon Simple Queue. Кроме того, на собствен-ном оборудовании или в облачных виртуальных машинах можно использовать довольно популярную реализацию pub/ sub-API под названием Apache Kafka ( https://kafka.apa che.org/ ). В оставшейся части обзора pub/sub-API в примерах мы будем использовать Kafka, но их будет несложно перенести на дру-гие реализации pub/sub.

202Часть III. Паттерны проектирования систем пакетных вычислений Практикум. Развертывание Kafka Очевидно, существует множество способов развертывания Kafka. Один из простейших подходов — использование кон-тейнера под управлением оркестратора Kubernetes и мене-джера пакетов helm.

Helm — менеджер пакетов для Kubernetes, упрощающий развер-тывание и управление готовыми приложениями наподобие Kafka. Если у вас еще не установлен инструмент командной строки helm, загрузить его можно с сайта http://helm.sh .

Инструмент helm после установки необходимо инициализиро-вать. В процессе инициализации helm разворачивает в вашем кластере компонент под названием tiller и устанавливает ряд паттернов на локальной системе.

helm init

После инициализации helm установите Kafka, выполнив сле-дующие команды:

helm repo add incubator

http://storage.googleapis.com/kubernetes-charts-incubator helm install --name kafka-service incubator/kafka

поддержки

Инкубаторные (incubator) паттерны носят более экс-периментальный характер и в меньшей степени опро-бованы в «боевых» условиях. Инкубаторные паттерны полезны для быстрой PoC-реализации (proof-of-concept) сервисов, а также в качестве начальной точки для развертывания рабочей среды сервисов, работающих

Глава 11. Событийно-ориентированная пакетная обработка 203После установки и запуска Kafka можно создавать темы, а в них — делать публикации. В рамках пакетной обработки тема соответствует выходным данным одного из модулей пото-

ка задач. Они, скорее всего, станут входными данными другого модуля в потоке задач.

К примеру, в рамках ранее рассмотренного паттерна Sharder каждому из выходных шардов будет соответствовать своя тема. Если выходной шард называется Photos и всего у вас их три, то и темы также будет три — Photos-1, Photos-2 и Photos-3. После вычисления значения шардирующей функции модуль шардирования публикует сообщение в соответствующей теме. Рассмотрим, как создать тему. Чтобы получить доступ к Kafka, сначала создадим контейнер в кластере:

for x in 0 1 2; do

kubectl run kafka --image=solsson/kafka:0.11.0.0 --rm --attach --command -- \

./bin/kafka-topics.sh --create --zookeeper kafka-service-zookeeper:2181 \