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

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

трудняет проведение экспериментов и внесение изменений в процесс взаимодействия пользователя с приложением. Рассмотрим реализацию входа пользователя в систему как со-бытийный конвейер из нескольких 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. На схеме показаны три экземпляра, каждый из которых может быть владельцем, или хозяином. Сначала владельцем будет пер-вый экземпляр. Если в нем случится ошибка, владельцем станет третий экземпляр.

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

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

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