Топ-5 шаблонов проектирования распределенных систем

Топ-5 шаблонов проектирования распределенных систем Изучение

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

Здесь неоценимыми становятся шаблоны проектирования распределенных систем. Шаблоны проектирования, которые иногда используются чрезмерно, являются ключевым навыком, который ищут рекрутеры, и они необходимы, чтобы выделиться на собеседованиях по продвинутому дизайну систем.

Сегодня мы рассмотрим 5 самых популярных шаблонов проектирования распределенных систем, чтобы помочь вам узнать об их преимуществах и недостатках, а также о том, когда их использовать.

Что такое шаблон проектирования распределенной системы?

Шаблоны проектирования — это испытанные и проверенные способы построения систем, каждая из которых соответствует конкретному варианту использования. Это не реализации, а, скорее, абстрактные способы структурирования системы. Большинство шаблонов проектирования разрабатывались и обновлялись годами разными разработчиками, что означает, что они часто являются очень эффективной отправной точкой.

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

Шаблоны проектирования создают основу при создании новых объектов. Структурные шаблоны определяют общую структуру решения. Паттерны поведения описывают объекты и то, как они общаются друг с другом.

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

Читайте также:  Команда sort в Linux с примерами

Эти шаблоны широко используются при проектировании распределенной системной архитектуры крупномасштабных облачных вычислений и масштабируемых программных систем микросервисов.

Типы распределенных шаблонов проектирования

Большинство распределенных шаблонов проектирования попадают в одну из трех категорий в зависимости от функциональности, с которой они работают.

  • Связь с объектами: описывает протоколы обмена сообщениями и разрешения для взаимодействия различных компонентов системы.
  • Безопасность: решает вопросы конфиденциальности, целостности и доступности, чтобы гарантировать защиту системы от несанкционированного доступа.
  • Управляемый событиями: шаблоны, описывающие производство, обнаружение, потребление и реакцию на системные события.

1. Разделение ответственности за команды и запросы (CQRS)

Шаблон CQRS фокусируется на разделении операций чтения и записи в распределенной системе для повышения масштабируемости и безопасности. В этой модели используются команды для записи данных в постоянное хранилище и запросы для поиска и извлечения данных.

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

Преимущества:

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

Недостатки:

  • Требуется постоянная двусторонняя связь между командами и моделями чтения.
  • Может вызвать повышенную задержку при отправке запросов с высокой пропускной способностью
  • Нет средств для связи между сервисными процессами

Вариант использования

CQRS лучше всего подходит для приложений с интенсивным использованием данных, таких как системы управления базами данных SQL или noSQL. Это также полезно для микросервисных архитектур с большим объемом данных. Это отлично подходит для работы с приложениями с отслеживанием состояния, потому что различие писатель / читатель помогает с неизменяемыми состояниями.

2. Двухфазная фиксация (2PC)

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

Все службы в системе 2PC заблокированы по умолчанию, то есть они не могут отправлять данные. Пока службы заблокированы, они завершают этап подготовки, поэтому после разблокировки они готовы к отправке. Координатор разблокирует сервисы одну за другой и запрашивает их данные. Если сервис не готов предоставить свои данные, координатор переходит на другой сервис. Как только все подготовленные данные будут отправлены, все сервисы разблокируются, чтобы дождаться новых задач от координатора.

По сути, 2PC гарантирует, что одновременно может работать только одна служба, что делает процесс более устойчивым и последовательным, чем CQRS.

Преимущества:

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

Недостатки:

  • Не отказоустойчивый, склонный к возникновению узких мест и блокировок из-за своей синхронной природы
  • Требует больше ресурсов, чем другие шаблоны проектирования

Вариант использования

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

3. Сага

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

Saga использует шину событий, чтобы позволить сервисам взаимодействовать друг с другом в микросервисной системе. Шина отправляет и принимает запросы между службами, и каждая участвующая служба создает локальную транзакцию. Затем каждая участвующая служба генерирует событие для получения другими службами. Все остальные службы прослушивают события. Первая служба, получившая событие, выполнит требуемое действие. Если этой службе не удается завершить действие, она отправляется другим службам.

Эта структура аналогична дизайну 2PC в том, что службы циклически меняются, если невозможно выполнить задачу. Однако Saga удаляет центральный элемент управления, чтобы лучше управлять потоком и уменьшить количество требуемых обменов данными.

Преимущества:

  • Отдельные сервисы могут обрабатывать гораздо более длительные транзакции
  • Отлично подходит для распределенной системы благодаря децентрализации
  • Уменьшает количество узких мест благодаря одноранговой связи между сервисами

Недостатки:

  • Асинхронная автономия затрудняет отслеживание того, какие службы выполняют отдельные задачи.
  • Сложно отлаживать из-за сложной оркестровки
  • Меньшая изоляция сервисов, чем предыдущие шаблоны

Вариант использования

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

4. Реплицируемые сервисы с балансировкой нагрузки (RLBS)

Шаблон RLBS — самый простой и наиболее часто используемый шаблон проектирования. На самом базовом уровне он состоит из нескольких идентичных сервисов, которые все отчитываются перед центральным балансировщиком нагрузки. Каждая служба способна обрабатывать задачи и может реплицироваться в случае сбоя. Балансировщик нагрузки получает запросы от конечного пользователя и распределяет их по службам либо с использованием циклического перебора, либо иногда с помощью более сложного алгоритма маршрутизации.

Дублирующие службы гарантируют, что приложение поддерживает высокую доступность для запросов пользователей и может перераспределять работу, если один из экземпляров службы выйдет из строя.

RLBS часто используется с Azure Kubernetes, которая представляет собой технологию оркестрации контейнеров с открытым исходным кодом, разработанную Microsoft, которая предлагает автоматическое масштабирование служб на основе рабочего процесса.

Преимущества:

  • Постоянная производительность с точки зрения конечного пользователя
  • Может быстро восстановиться после сбоев в работе
  • Высокая масштабируемость с большим количеством услуг
  • Отлично подходит для параллелизма

Недостатки:

  • Несогласованная производительность на основе алгоритма балансировщика нагрузки
  • Ресурсоемкое управление услугами

Вариант использования

RLBS отлично подходит для фронтальных систем, которые имеют непостоянные рабочие нагрузки в течение дня, но должны поддерживать низкую задержку, например, развлекательные веб-приложения, такие как Netflix или Amazon Prime.

5. Раздельные сервисы

Альтернативой дизайну на основе реплик является создание набора служб, каждая из которых выполняет только определенный тип запроса. Это называется «сегментированием», потому что вы разделяете поток запросов на несколько неравных частей. Например, у вас может быть одна служба сегментов, которая принимает все запросы кеширования, а другая обрабатывает только запросы с высоким приоритетом. Балансировщик нагрузки оценивает каждый входящий запрос и распределяет его по соответствующему сегменту для выполнения.

Разделенные службы обычно используются для создания служб с отслеживанием состояния, поскольку размер состояния часто слишком велик для одного контейнера без состояния. Шардинг позволяет масштабировать отдельный сегмент в соответствии с размером состояния.

Разделенные службы также позволяют быстрее обрабатывать высокоприоритетные запросы. Осколки, выделенные для высокоприоритетных запросов, всегда доступны для обработки таких запросов в момент их поступления, а не помещаются в очередь.

Преимущества:

  • Позволяет масштабировать шарды для общих запросов
  • Легко расставить приоритеты запросов
  • Простая отладка благодаря естественной сортировке

Недостатки:

  • Может потребовать значительных ресурсов для обслуживания большого количества шардов.
  • При непропорциональном использовании осколков приводит к снижению производительности.

Вариант использования

Разделенные службы лучше всего подходят, когда ваша система получает предсказуемый дисбаланс в типах запросов, но некоторые запросы имеют приоритет.

Что учить дальше

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

Вот несколько шаблонов, которые вам следует изучить дальше:

  • Sidecar Pattern.
  • Write-ahead Log.
  • Split-Brain Pattern.
  • Hinted Handoff.
  • Read Repair.
Оцените статью
bestprogrammer.ru
Добавить комментарий