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

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

трудняет проведение экспериментов и внесение изменений в процесс взаимодействия пользователя с приложением. Рассмотрим реализацию входа пользователя в систему как со-бытийный конвейер из нескольких FaaS-сервисов. При таком разделении функция создания пользователя понятия не имеет, Глава 8. Функции и событийно-ориентированная обработка 149что происходит во время входа пользователя в систему. У нее есть два списка:

‰ ‰ список необходимых действий (например, отправка привет-ственного электронного письма);

‰ ‰ список необязательных действий (например, подписка на рассылку).

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

def create_user(context):

# Безусловный вызов всех необходимых обработчиков for key, value in required.items():

call_function(value.webhook, context.json) # Необязательные обработчики выполняются

# при соблюдении определенных условий

for key, value in optional.items():

if context.json.get(key, None) is not None: call_function(value.webhook, context.json) Каждый из обработчиков теперь также можно реализовать по принципу FaaS:

def email_user(context):

# Получить имя пользователя

user = context.json['username']

msg = 'Здравствуйте, {}, спасибо, что воспользовались нашим замечательным сервисом!".format(user)

send_email(msg, contex.json['email])

def subscribe_user(context):

# Получить имя пользователя

email = context.json['email']

subscribe_user(email)

150Часть II. Паттерны проектирования обслуживающих систем Декомпозированный таким образом FaaS-сервис становится значительно проще, содержит меньше строк кода и сосредо-точен на реализации одной конкретной функции. Микросер-висный подход упрощает написание кода, но может привести к сложностям при развертывании и управлении тремя разными микросервисами. Здесь подход FaaS проявляет себя во всей красе, поскольку в результате его использования становится очень просто управлять небольшими фрагментами кода. Визуа-лизация процесса создания пользователя в виде событийного конвейера позволяет также в общих чертах понять, что именно происходит во время входа пользователя в систему, просто про-следив изменение контекста от функции к функции в рамках конвейера.

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

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

Общая схема распределенного владения приводится на рис. 9.1. На схеме показаны три экземпляра, каждый из которых может быть владельцем, или хозяином. Сначала владельцем будет пер-вый экземпляр. Если в нем случится ошибка, владельцем станет третий экземпляр.

Наконец, первый экземпляр восстанавливает работу и снова входит в группу, но при этом третий экземпляр все так же оста-ется владельцем.

Распределенное владение — одновременно самая сложная и са-мая важная часть проектирования надежной распределенной системы.

Как определить, нужен ли выбор владельца

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

Глава 9. Выбор владельца 153

Рис. 9.1. Протокол выбора владельца в действии: сначала владельцемявляется первый экземпляр сервиса, а в случае его отказа полномочия берет на себя третий экземпляр

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

‰ ‰ Если контейнер откажет, он будет перезапущен.‰ ‰ Если контейнер зависнет, а у вас реализована проверка ра-

ботоспособности, он также будет перезапущен. ‰ ‰ Если произойдет аппаратный сбой, контейнер будет пере-

мещен на другую машину.

Благодаря наличию этих гарантий сервис-одиночка, работа-ющий под управлением оркестратора контейнеров, как правило, имеет достаточно высокий процент времени безотказной рабо-ты. Чтобы уточнить, насколько высок «достаточно высокий» процент, рассмотрим, что происходит в случае каждого из пере-численных отказов. Если запущенный в контейнере процесс от-кажет, приложение будет перезапущено через несколько секунд. Предположим, контейнер сбоит раз в день. Это примерно соот-ветствует доступности на уровне 3–4 девяток (99,9–99,99 %) — 2 секунды недоступности в день примерно равны 99,99 % до-ступности. Если контейнер отказывает реже, то доступность будет еще лучше. При отказе оборудования Kubernetes потре-буется некоторое время, чтобы понять, что машина вышла из строя, после чего он переместит контейнер на другую машину. Допустим, это зай мет 5 минут. Если каждая машина в кластере отказывает раз в день, то доступность сервиса составляет две девятки, или 99 %. Честно сказать, если у вас в кластере каждая машина отказывает раз в день, то низкая доступность сервиса — наименьшая из ваших проблем.