кластер, то приступайте к установке Kubeless, который можно загрузить с соответствующего сайта (https:// git hub.com/kubeless/kubeless/releases). Как только у вас появился исполняемый файл kubeless, установить его в кластер можно командой kubeless install.
Kubeless устанавливается как сторонняя API-надстройка Kubernetes. А это значит, что после установки его можно будет использовать в рамках инструмента командной строки kubectl. К примеру, развернутые в кластере функ-ции можно будет увидеть, выполнив команду kubectl get functions. На данный момент в вашем кластере не развер-нуто ни одной функции.
Практикум. Подстановка значений по умолчанию до обработки запроса Продемонстрировать полезность паттерна Decorator в FaaS мож-но на примере подстановки значений по умолчанию в RESTful-Глава 8. Функции и событийно-ориентированная обработка 143вызов для параметров, значения которых не были заданы пользо-вателем. С помощью FaaS это делается довольно просто. Функция подстановки значений по умолчанию написана на языке Python: # Простая функция-обработчик, подставляющая значения # по умолчанию
def handler(context):
# Получаем входное значение
obj = context.json
# Если поле "name" отсутствует, инициализировать его # случайной строкой
if obj.get("name", None) is None:
obj["name"] = random_name()
# Если отсутствует поле 'color', установить его # значение в 'blue'
if obj.get("color", None) is None:
obj["color"] = "blue"
# Выполнить API-вызов с учетом значений параметров # по умолчанию
# и вернуть результат
return call_my_api(obj)
Сохраните эту функцию в файл под названием defaults.py . Не за-будьте заменить вызов call_my_api вызовом нужного вам API. Эту функцию подстановки значений по умолчанию можно заре-гистрировать в качестве kubeless-функции следующей командой: kubeless function deploy add-defaults \
--runtime python27 \
--handler defaults.handler \
--from-file defaults.py \
--trigger-http
Чтобы ее протестировать, можно использовать инструмент kubeless :
kubeless function call add-defaults --data '{"name": "foo"}' Паттерн Decorator показывает, насколько просто адаптировать и расширять существующие API дополнительными возможно-стями вроде валидации или подстановки значений по умолчанию.
144Часть II. Паттерны проектирования обслуживающих систем Обработка событий
Большинство систем являются запросно-ориентированны-ми — они обрабатывают непрерывные потоки пользовательских и API-запросов. Несмотря на это, существует довольно много событийно-ориентированных систем. Различие между запро-
сом и событием, как мне кажется, кроется в понятии сессии . За-просы представляют собой части более крупного процесса взаи-модействия (сессии). В общем случае каждый пользовательский запрос есть часть процесса взаимодействия с веб-приложением либо API в целом. События видятся мне более «одноразовыми», асинхронными по своей природе. События важны и должны со-ответствующим образом обрабатываться, но они оказываются вырваны из основного контекста взаимодействия и ответ на них приходит лишь спустя некоторое время. Примером события может служить подписка пользователя на некоторый сервис, что вызовет отправку приветственного письма; загрузка файла в общую папку, что приведет к отправке уведомлений всем пользователям данной папки; или даже подготовка компьютера к перезагрузке, что приведет к уведомлению оператора или ав-томатизированной системы о том, что необходимо предпринять соответствующие действия.
Поскольку эти события в значительной степени независимы и не имеют внутреннего состояния, а частота их весьма измен-чива, они идеально подходят для работы в событийно-ориенти-рованных FaaS-архитектурах. Их часто разворачивают рядом
с «боевым» сервером приложений для обеспечения дополни-тельных возможностей или для фоновой обработки данных в от-вет на возникающие события. Кроме того, поскольку к сервису постоянно добавляются новые типы обрабатываемых событий, простота развертывания функций делает их подходящими для реализации обработчиков событий. А так как каждое собы-тие концептуально независимо от остальных, вынужденное Глава 8. Функции и событийно-ориентированная обработка 145ослабление связей внутри системы, построенной на основе функций, позволяет снизить ее концептуальную сложность, позволяя разработчику сосредоточиться на шагах, необходимых для обработки только одного конкретного типа событий. Конкретный пример интеграции событийно-ориентированного компонента к существующему сервису — реализация двух-факторной аутентификации. В данном случае событием будет вход пользователя в систему. Сервис может генерировать для этого действия событие и передавать его функции-обработчику. Обработчик на основе переданного кода и контактных данных пользователя отправит ему аутентификационный код в виде текстового сообщения.
Читать дальше