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

10 Системы на основе очередей задачПростейшая форма пакетной обработки — очередь задач . В си-стеме с очередью задач есть набор задач, которые должны быть выполнены. Каждая задача полностью независима от остальных и может быть обработана без всяких взаимодей-ствий с ними. В общем случае цель системы с очередью за-дач — обеспечить выполнение каждого этапа работы в течение заданного промежутка времени. Количество рабочих потоков увеличивается либо уменьшается сообразно изменению на-грузки. Схема обобщенной очереди задач представлена на рис. 10.1.

Система на основе обобщенной очереди задач

Очередь задач — идеальный пример, демонстрирующий всю мощь паттернов проектирования распределенных систем. Боль-шая часть логики работы очереди задач никак не зависит от 174Часть III. Паттерны проектирования систем пакетных вычислений

Рис. 10.1. Обобщенная очередь задач

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

Построение очереди задач на основе контейнеров требует со-гласования интерфейсов между библиотечными контейнерами и контейнерами с пользовательской логикой. В рамках контей-неризованной очереди задач выделяется два интерфейса: ин-терфейс контейнера-источника, предоставляющего поток задач, требующих обработки, и интерфейс контейнера-исполнителя, который знает, как их обрабатывать.

Интерфейс контейнера-источника Любая очередь задач функционирует на основе набора задач, требующих обработки. В зависимости от конкретного при-ложения, реализованного на базе очереди задач, существу-ет множество источников задач, в нее попадающих. Но после получения набора задач схема работы очереди оказывается Глава 10. Системы на основе очередей задач 175

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

глядеть реализацию паттерна Ambassador. Контейнер обобщен-ной очереди задач является главным контейнером приложения, а специфичный для приложения контейнер-источник является послом, транслирующим запросы контейнера-диспетчера оче-

реди конкретным исполнителям задач. Данная группа контей-неров изображена на рис. 10.2.

Рис. 10.2. Группа контейнеров, реализующая очередь задачК слову, хотя контейнер-посол специфичен для приложения (что очевидно), существует также ряд обобщенных реализа-ций API источника задач. Например, источником может слу-жить список фотографий, находящихся в некотором облачном хранилище, набор файлов на сетевом диске или даже очередь в системах, работающих по принципу «публикация/подпи-ска», таких как Kafka или Redis. Несмотря на то что пользо-ватели могут выбирать наиболее подходящие под свою задачу контейнеры-послы, им следует использовать обобщенную «библиотечную» реализацию самого контейнера. Так будет минимизирован объем работы и максимизировано повторное использование кода.

176Часть III. Паттерны проектирования систем пакетных вычислений API очереди задач. Учитывая механизм взаимодействия оче-реди задач и зависящего от приложения контейнера-посла, нам следует сформулировать формальное определение интерфейса между двумя контейнерами. Существует много разных прото-колов, но HTTP RESTful API просты в реализации и являются стандартом де-факто для подобных интерфейсов. Очередь задач ожидает, что в контейнере-после будут реализованы следующие URL:

‰ ‰ GET http://localhost/api/v1/items ;

‰ ‰ GET http://localhost/api/v1/items/ . же соответствующий рефакторинг позже станет крайне

дорого. Возьмите за правило добавлять версии ко всем API, даже если не уверены, что они когда-либо изменятся.

URL /items/ возвращает список всех задач: {

kind: ItemList,

apiVersion: v1,

items: [

"item-1",

"item-2",

….

]

}

URL /items/ предоставляет подробную информа-цию о конкретной задаче:

{

kind: Item,

Глава 10. Системы на основе очередей задач 177

apiVersion: v1,

data: {

"some": "json",

"object": "here",

}

}

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

зации внутри диспетчера очереди задач. В этой связи диспетчер очереди задач должен сам следить за тем, какие задачи уже об-работаны, а какие еще предстоит обработать. Из этого API мы получаем сведения о конкретной задаче, а за-тем передаем значение поля item.data интерфейса контейнера-исполнителя.

Интерфейс контейнера-исполнителя Как только диспетчер очереди получил очередную задачу, он должен поручить ее некоторому исполнителю. Это второй ин-терфейс в обобщенной очереди задач. Сам контейнер и его ин-терфейс немного отличаются от интерфейса контейнера-источ-ника по нескольким причинам. Во-первых, это «одноразовый» API. Работа исполнителя начинается с единственного вызова, и в течение жизненного цикла контейнера больше никаких вызовов не выполняется. Во-вторых, контейнер-исполнитель и диспетчер очереди задач находятся в разных группах контей-неров. Контейнер-исполнитель запускается посредством API оркестратора контейнеров в своей собственной группе. Это значит, что диспетчер очереди задач должен выполнить удален-ный вызов, чтобы инициировать работу контейнера-исполни-теля. Это также значит, что придется быть более осторожными 178Часть III. Паттерны проектирования систем пакетных вычислений в вопросах безопасности, так как злонамеренный пользователь кластера может загрузить его лишней работой. В контейнере-источнике для отправки списка задач диспетчеру задач мы использовали простой HTTP-вызов. Так было сделано исходя из того, что данный API-вызов нужно совершать не-сколько раз, а вопросы безопасности не учитывались, поскольку все работало в рамках localhost. API контейнера-исполнителя необходимо вызывать лишь однажды и важно убедиться, что другие пользователи системы не могут добавить работы испол-нителям хоть случайно, хоть по злому умыслу. Следовательно, для контейнера-исполнителя будем использовать файловый API. При создании мы передадим контейнеру переменную сре-ды под названием WORK_ITEM_FILE , значение которой ссылается на файл во внутренней файловой системе контейнера. Этот файл содержит данные о задаче, которую необходимо выпол-нить. Такого рода API, как показано ниже, может быть реали-зован Kubernetes-объектом ConfigMap . Его можно смонтировать в группу контейнеров как файл (рис. 10.3).