Распределенные приложения — неотъемлемая часть современной индустрии разработки ПО. Они играют важную роль в сфере облачных услуг и обеспечивают реактивность крупномасштабных веб-приложений. При создании таких систем хорошим подспорьем для программистов становится наличие базовых строительных блоков и единой терминологии для эффективного общения друг с другом.
В связи с этим возрастает значимость шаблонов проектирования распределенных систем. Несмотря на случаи злоупотребления ими, понимание принципов их работы является ключевым навыком, востребованном на рынке труда, и весомым подтверждением профессиональной компетентности на собеседованиях.
В статье мы познакомимся с 5 главными шаблонами проектирования распределенных систем, изучив их преимущества, недостатки и случаи применения.
На повестке дня:
- Понятие шаблона проектирования распределенных систем
- 1. Разделение назначения запросов и команд на обработку данных (CQRS)
- 2. Двухфазный коммит (2PC)
- 3. Сага
- 4. Реплицированные сервисы с балансировкой нагрузки
- 5. Шардированные сервисы
- Материалы для дальнейшего изучения
Понятие шаблона проектирования распределенных систем
Шаблоны проектирования — проверенные и опробованные на практике способы конструирования, предназначенные для конкретных сценариев использования. Это не реализации, а абстрактные подходы к структурированию системы. Для создания и обновления большинства шаблонов потребовались годы и усилия самых разных разработчиков, вследствие чего теперь они служат весьма эффективным инструментом для начала процесса разработки.
Благодаря таким строительным блокам программисты не начинают работу над каждой системой с нуля, а опираются на уже имеющиеся знания. Кроме того, они создают набор стандартных моделей для проектирования, позволяющих другим разработчикам понять, как их собственные проекты могут взаимодействовать с данной системой.
- Порождающие шаблоны проектирования служат основой для создания новых объектов.
- Структурные определяют общую структуру решения.
- Поведенческие описывают объекты и их взаимодействие друг с другом.
Рассматриваемые в статье шаблоны проектирования предназначены для разработки распределенных систем, которые представляют собой группы вычислительных машин и центров обработки данных, работающих для конечного пользователя как один компьютер. Они определяют архитектуру ПО, согласно которой осуществляется взаимодействие разных узлов, распределение между ними нагрузки и выполнение разного рода рабочих задач.
Данные шаблоны широко применяются при проектировании архитектуры распределенных систем крупномасштабных облачных вычислений и масштабируемых микросервисных программных систем.
Типы шаблонов распределенного проектирования
Большинство шаблонов распределенного проектирования делятся на 3 категории в зависимости от функциональностей, с которыми они работают.
- Взаимодействие объектов: описывает протоколы обмена сообщениями и разрешения для различных компонентов системы с целью обеспечения коммуникации.
- Безопасность: решает вопросы конфиденциальности, надежности и соответствия требованиям, защищая систему от несанкционированного доступа.
- Ориентация на события: описывает создание, обнаружение, потребление и реакцию на события системы.
1. Разделение назначения запросов и команд на обработку данных (CQRS)
Шаблон проектирования CQRS нацелен на разделение операций чтения и записи распределенной системы для повышения масштабируемости и безопасности. Эта модель применяет команды для записи данных в постоянное хранилище и запросы для обнаружения и извлечения данных.
Их обработкой занимается центр управления, получающий запросы от пользователей. После этого он извлекает данные, вносит необходимые изменения, сохраняет их и уведомляет службу чтения, которая затем обновляет модель чтения для демонстрации изменения пользователю.
Преимущества
- Уменьшает сложность системы посредством делегирования задач.
- Обеспечивает четкое разделение между бизнес-логикой и валидацией.
- Помогает классифицировать процессы по выполняемой работе.
- Уменьшает число непредвиденных изменений общих данных.
- Уменьшает число сущностей, имеющих доступ к данным с правом изменения.
Недостатки
- Требует поддержания постоянного двустороннего взаимодействия между моделями команд и чтения.
- Может привести к увеличению времени ожидания при отправке запросов с высокой пропускной способностью.
- Отсутствуют средства для взаимодействия между сервисными процессами.
Использование
CQRS лучше всего подходит для информационно емких приложений, таких как системы управления БД SQL или NoSQL, а также для микросервисных архитектур с большими объемами данных. CQRS оптимален для приложений, сохраняющих состояния, поскольку разделение записывающих и считывающих компонентов помогает в работе с неизменяемыми состояниями.
2. Двухфазный коммит (2PC)
По своему транзакционному подходу и акценту на центральное управление 2PC похож на CQRS, но при этом разделы обрабатываются в зависимости от их типа и стадии выполнения. Во время предварительной фазы сервисы получают от центрального контроллера команду подготовить данные, а на этапе фиксации им дается указание эти данные отправить.
В системе 2PC все сервисы заблокированы по умолчанию, поэтому не могут получать данные. Находясь в этом состоянии, они выполняют задание подготовительной фазы, чтобы приготовиться к отправке данных в момент разблокировки. Координатор открывает сервисы по очереди и запрашивает данные. Если какой-либо из них не готов их отправить, он переходит к другому. Как только состоялась отправка всех подготовленных данных, сервисы открываются и ожидают новые задачи от координатора.
2PC гарантирует, что одновременно может работать только один сервис, благодаря чему процесс становится более устойчивым и последовательным, чем в случае с CQRS.
Преимущества
- Последовательный и устойчивый к ошибкам вследствие отсутствия одновременно выполняющихся запросов.
- Масштабируемый — способен также легко обрабатывать пулы больших данных, как и данные с одного компьютера.
- Предоставляет возможности как для изолирования, так и совместного использования данных.
Недостатки
- Не отличается отказоустойчивостью, допускает сбои и блокировку из-за своей синхронной природы.
- Требует больше ресурсов, чем другие шаблоны проектирования.
Использование
2PC лучше всего подходит для распределенных систем с ответственными транзакциями, для которых точность важнее ресурсоэффективности. Он устойчив к ошибкам и позволяет легко отслеживать возникающие неисправности по мере их появления, даже при масштабировании.
3. Сага
Сага — асинхронный шаблон, который не задействует центральный контроллер, а обеспечивает непосредственное взаимодействие между сервисами. Он позволяет избежать недостатков ранее рассмотренных синхронных паттернов.
Сага опирается на механизм обработки событий Event Bus, позволяющий компонентам взаимодействовать друг с другом в микросервисной системе. Этот механизм регулирует отправку и получение запросов между занятыми в процессе сервисами, каждый из которых создает локальную транзакцию. Затем каждый задействованный сервис порождает событие для других участников, которые пребывают в состоянии ожидания. Первый сервис, получивший событие, выполняет требуемое действие. Если ему не удается его осуществить, он перепоручает задачу другому.
Как и в шаблоне 2PC, в данной структуре задание передается по кругу от одного сервиса к другому при условии, что один из них с ним не справляется. Однако Сага отказывается от централизованного контролирующего элемента ради более эффективного управления рабочим процессом и сокращения числа необходимых двухсторонних взаимодействий.
Преимущества
- Отдельные сервисы могут обрабатывать более длительные транзакции.
- Оптимальный вариант для распределенной системы благодаря децентрализации.
- Уменьшает число сбоев в связи с равноправным взаимодействием между сервисами.
Недостатки
- Вследствие асинхронной автономии становится сложнее следить за тем, какие из сервисов выполняют отдельные задачи.
- Сложная оркестровка затрудняет процесс отладки.
- Меньшая изоляция сервиса, чем в предыдущих шаблонах.
Использование
Децентрализованный подход Сага оптимален для масштабируемых бессерверных функций, одновременно обрабатывающих множество параллельных запросов. AWS задействует принципы проектирования на его основе во многих функциях, например ступенчатых и лямбда.
4. Реплицированные сервисы с балансировкой нагрузки (RLBS)
RLBS, простейший и наиболее распространенный шаблон, состоит из нескольких идентичных сервисов, все из которых отчитываются перед центральным балансировщиком нагрузки. Каждый сервис способен обрабатывать задачи и дублироваться в случае сбоя. Балансировщик нагрузки получает запросы от конечного пользователя и распределяет их по сервисами согласно циклическому принципу или усложненному алгоритму маршрутизации.
Благодаря репликации сервисов приложение сохраняет высокую доступность для принятия пользовательских запросов и способно перераспределять работу в случае сбоя одного из компонентов.
RLBS часто используется с Azure Kubernetes. Эта разработанная Microsoft технология оркестровки контейнеров с открытым исходным кодом предоставляет автоматическое масштабирование сервисов на основе рабочего процесса.
Преимущества
- Стабильная производительность с точки зрения конечного пользователя.
- Способность к быстрому восстановлению после сбоев в работе сервисов.
- Высокая масштабируемость при добавлении сервисов.
- Оптимально подходит для параллельной обработки данных.
Недостатки
- Несогласованная производительность из-за алгоритма балансировки нагрузки.
- Требует чрезмерных ресурсов для управления сервисами.
Использование
RLBS отлично подходит для фронтальных систем, которые демонстрируют нестабильную рабочую нагрузку в течение дня, но должны поддерживать низкое значение задержки. К ним относятся такие развлекательные веб-приложения, как Netflix или Amazon Prime.
5. Шардированные сервисы
Альтернативой шаблонам на основе реплик является создание набора сервисов, каждый из которых выполняет только определенный вид запроса. Этот процесс называется шардирование (разделение на шарды или сегменты), поскольку поток запроса разбивается на несколько неравных частей. Например, один шард принимает все кэшируемые запросы, а другой занимается обработкой только запросов высокого приоритета. Балансировщик нагрузки изучает каждый входящий запрос и направляет его соответствующему шарду на выполнение.
Как правило, данный шаблон подходит для создания сервисов с сохранением состояния, поскольку его размер слишком большой для одного контейнера без запоминания состояния. Шардирование позволяет масштабировать конкретный шард под размер состояния.
Шардированные сервисы также способствуют более быстрой обработке запросов высокого приоритета, поскольку ответственные за них шарды не помещают их в очередь, а обрабатывают сразу по мере их поступления.
Преимущества
- Позволяет масштабировать шарды для обычных запросов.
- Легко распределяет запросы в соответствии с приоритетом.
- Прост в отладке благодаря естественной сортировке.
Недостатки
- Может потребовать чрезмерных ресурсов для обслуживания многочисленных шардов.
- При непропорциональном применении шардов приводит к снижению производительности.
Использование
Шардированные сервисы предназначены для тех случаев, когда система получает ожидаемый дисбаланс в типах запросов, некоторые из которых обладают высоким приоритетом.
Материалы для дальнейшего изучения
Шаблоны проектирования распределенных систем — важная часть любой эффективной бэкенд-системы. Здесь мы рассмотрели лишь некоторые из числа тех, что применяются профессиональными инженерами ПО.
Перечислим шаблоны для дальнейшего изучения:
- Sidecar;
- Write-Ahead Log;
- Split-Brain Pattern;
- Hinted Handoff;
- Read Repair.
Читайте также:
- Пять шаблонов проектирования, которые необходимо знать каждому разработчику
- Современные шаблоны проектирования архитектуры
- Изучаем шаблоны проектирования в JavaScript
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи The Educative Team: Top 5 Distributed System Design Patterns
