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

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).

Рис. 10.3. API контейнера-исполнителя

Такой механизм файлового API проще реализовать с помо-щью контейнера. Исполнитель в рамках очереди задач часто Глава 10. Системы на основе очередей задач 179

представляет собой простой сценарий командной оболочки, обращающийся к нескольким инструментам. Нецелесообразно поднимать для управления задачами целый веб-сервер — это приводит к усложнению архитектуры. Как и в случае с ис-точниками задач, большая часть контейнеров-исполнителей будет представлять собой специализированные контейнеры для определенных задач, но есть и обобщенные исполнители, применимые для решения нескольких разных задач. Рассмотрим пример контейнера-исполнителя, который скачивает файл из облачного хранилища, выполняет над ним сценарий ко-мандной оболочки, а затем копирует результат обратно в облачное хранилище. Такой контейнер может быть по большей части об-щим, но в качестве параметра ему может передаваться конкретный сценарий. Таким образом, большая часть кода работы с файлом может быть повторно использована многими пользователями/ очередями задач. Конечному пользователю необходимо лишь предоставить сценарий, содержащий специфику обработки файла. Общая инфраструктура очередей задач Что остается внедрить в повторно используемой реализации очереди, если реализации двух ранее описанных интерфейсов контейнеров у вас уже есть? Базовый алгоритм работы очереди задач довольно прост.