Архитектура приложений с общей шиной и очередью

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

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

Для организации реактивного поведения программного обеспечения используют в основном две архитектурные концепции:

• очередь сообщений
• шина сообщений

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

Об основных принципах построения, технических ограничениях, горизонтальном масштабировании поговорим в этом стриме.

Архитектурное заимствование

Duration: 10

Архитектурные идеи часто используются и переиспользуются в разных сферах АйТи. Впервые понятие шины появилось в вычислительной технике для организации взаимодействия различных компонент одного вычислительного устройства. Далее эта идея была заимствована и развита для синхронизации состояния реактивных приложений.

Интересно рассмотреть следующие особенности шины, используемой в вычислительно технике:

Шина это просто провод

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

Примечание: на практике есть окно в рамках которого шина сохраняет свое состояние - это либо окно синхронизации (время которое нужно чтобы сообщение распространено на все узлы системы), либо время необходимое для пассивного предоставления данных.

Шины бывают: - локальные - внешние

У шин есть два варианта реализации: - последовательная - параллельная

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

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

Под каждую задачу своя шина

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

Шина не определяет когда из нее должны быть считаны данные

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

Очередь как расширение ограничений шины

Так как шина не хранит данные, не оповещает о изменении данных, не гарантирует целостность данных, то для в программном обеспечении как правило используется комбинация "шина" + "очередь сообщений". Очередь - это реализации классической структуры данных, функционирующей по принципу FIFO. В задачи такого решения входит и накопление сообщений, и оповещение клиентов о получении новых сообщений, и гарантии доставки сообщений.

Таким образом очередь сообщений - это усовершенствованная идея "шины" из вычислительной техники. Однако на практике реализация простой шины в реактивных приложениях может оказать сильно проще и предпочтительнее использования "очереди сообщений"

Общая архитектура асинхронной шины

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

Так как шина не имеет истории сообщений, то в момент доставки сообщения существует два варианта поведения шины: - новые сообщения не принимаются в доставку; - доставка предыдущего сообщения прекращается и все клиенты начинают получать новое сообщение;

Общая архитектура очереди сообщенний

Duration: 8

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

Очередь - это усовершенствованная идея работы шины сообщений. Для реализации вносятся следующие изменения:

• сообщения сохраняются в очередь
• доступ к сообщениям по принципу очереди (сообщения извлекаются из очереди)
• информация о изменениях очереди направляется через события (опционально)

Стратегии доставки сообщений

Duration: 8

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

Прием сообщения осуществляется в несколько этапов: - сначала сообщение принимается в буфер обмена; - затем сообщение обрабатывается (приводится из текстового вида в структуры данных); - затем отправитель уведомляется об успешной приемке сообщения.

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

Для проектирования необходимо принять решение о стратегии доставки сообщений. Выделяют следующие стратегии доставки сообщений:

• Доставка без подтверждения (0, 1 или много);
• Доставка минимум одной копии сообщений (1 или много - at most once) ;
• Доставка максимум одной копии сообщения (0 или 1 - at least once);
• Доставка только одной копии сообщения (только 1 - exactly once).

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

Шина как основа реактивной архитектуры

Duration: 7

Шина сообщений организуется на базе двух вариантов доставки:

• широковещательная
• адресная

Широковещательная

в случае широковещательной доставки, всем клиентам подключенным к серверу предоставляется копия сообщения (режим "чата"). Клиенты сами решают нужно ли обрабатывать сообщений, или сообщение должно быть откинуто. Для того чтобы сообщения могли быть обработаны, в структуре сообщения должна быть служебная информация, необходимая для принятия решения.

Достоинства: - простая схема; - хорошо масштабируется (могут быть построены гетерогенные схемы где клиенты являются пользователями или серверами);

Недостатки: - Большой overhead - плохая безопасность (все получат сообщение, даже если оно им не предназначается)

Адресная

В случае адресной доставки сервер определяет и предоставляет копию сообщения только определенным клиентам (режим приватных сообщений), для масштабирования используются шлюзы сообщений или прямая доставка серверам входящих в систему.

Достоинства: - низкий overhead - возможность маршрутизации сообщений

Способы получения сообщений

Разделяют активный и пассивный способ получения данных или push/pull подходы

Push

Это активный способ, при котором сообщение не хранится на сервере (или хранится только в рамках окна синхронизации), а отправляется всем клиента, имеющим активное подключение (push).

Либо сообщение отправляется во все эндпоинты серверов, неподключенных к шине

Pull

В шине не реализуется

Сообщения

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

Очередь как основа реактивной архитектуры

Duration: 7

Очередь поддерживает так же pull и push режимы работы, но кроме этого дополнительно может оповещать клиентов о получении сообщений.

Очередь не поддерживает широковещательный способ доставки сообщений, но на практике такой способ доставки поддерживается и в таком случае очередь функционирует как обычная шина.

Режимы работы очереди следующие:

Общий режим

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

Приватный режим

В этом режиме для каждого клиента ведется своя очередь сообщений, при этом возможно копирование одного и того же сообщения нескольким приватным адресатам (широковещательная рассылка)

Способы получения сообщений

Push

Может быть реализована только в приватном режиме, в таком случае все клиенты получают свои сообщения сразу после получения на сервере

Pull

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

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

События

В случае pull режима очередь может оповещать клиентов о получении сообщений через рассылку событий.

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