Очереди и темы

Представьте, что у нас есть архитектура, основанная на сервисах, в которой ряд служб (A и B) генерируют сообщения, а ряд других служб (C и D) потребляют сообщения. Наиболее распространенный способ представить такую архитектуру следующим образом:

С некоторых точек зрения, эта диаграмма является точным представлением архитектуры. Службы A и B отправляют сообщения посреднику, который перенаправляет эти сообщения в службы C и D. Проблема в том, что характер этой диаграммы “hub and spoke”, как правило, скрывает реальную историю, в которой между производителями и потребителями сообщений может существовать определенная взаимосвязь.

Точка к точке

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

В этом примере мы можем ясно видеть, что существует связь между службами A и C через очередь с именем X, и аналогичная двухточечная связь между службами B и D через очередь с именем Y.

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

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

В результате получается визуально более простая и менее загроможденная диаграмма, но очереди на диаграмме уже не так отчетливо видны. Поскольку модель C4 не зависит от обозначений, вы можете дополнительно использовать другой стиль линий (сплошные или пунктирные) или цвет, чтобы выделить взаимосвязи, основанные на сообщениях. Ни одна из версий диаграмм не “лучше” другой, они просто рассказывают одну и ту же историю по-разному. Это все компромиссы.

Издатель/Подписчик (Pub/Sub)

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

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

Резюме

Существует несколько способов построения диаграмм архитектур, основанных на сообщениях, причем последние два из приведенных ниже являются “правильными”:

• Неверно: Смоделируйте шину сообщений как контейнер C4.
• Правильно: явно моделируйте очереди и темы как контейнеры C4.
• Правильно: неявно моделируйте взаимодействия на основе сообщений, используя обозначение отношений “через”.

Дальнейшие соображения

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

Если вы ознакомились с рекомендациями по микросервисам и моделируете каждый сервис как отдельную программную систему, вам также необходимо учитывать, кто “владеет” очередями и темами. Если служба A (программная система) имеет двухточечную связь со службой B (также программной системой) через очередь с именем X (контейнер)… кому принадлежит контейнер? Принадлежит ли службе A определение формата сообщений и управление очередью, или это служба B? Или, возможно, она находится в совместном владении или полностью принадлежит кому-то другому. Право собственности повлияет на диаграммы.