Задумывались ли вы, почему мы используем отдельную базу данных для каждого сервиса, но при этом один общий брокер для нескольких сервисов? Ведь вполне возможно использовать базу данных в роли брокера сообщений. Однако если мы попробуем заменить RabbitMQ на Redis, то натолкнемся на проблему общего использования базы данных. Это станет проблемой, потому что общее использование базы данных является антипаттерном.
?️ Database
В микросервисной архитектуре существуют два основных подхода к организации баз данных:
Отдельная база данных для каждого сервиса
Общая база данных для всех сервисов
Общая база данных - это хорошее решение для небольших проектов без амбициозных планов на рост. Однако в контексте микросервисной архитектуры, это считается антипаттерном, поскольку невозможно независимо тестировать и масштабировать два сервиса, использующие одну базу данных. В итоге, эти сервисы больше похожи на один сервис, который может превратиться в монолит.
Подход с отдельной базой данных для каждого сервиса подразумевает, что каждый сервис использует свою собственную базу. Сервис может получать данные другого сервиса только через API, без прямого подключения к его базе данных. Это позволяет командам выбирать базы данных, которые им больше подходят. Например, кто-то может предпочесть MongoDB, другие могут предпочесть PostgreSQL, а для кого-то будет достаточно Redis.
? Database per service - подход, где каждый сервис имеет свою базу данных, обеспечивая изоляцию и независимость.
✉️Shared message broker
Брокер сообщений - это архитектурный паттерн в распределённых системах, где элементы системы общаются через посредника. Брокер упрощает работу веб-сервисов, отвечая за пересылку сообщений и все связанные задачи.
В работе брокера сообщений участвуют два ключевых элемента: producer (создатель сообщений) и consumer (получатель/подписчик). Один элемент создает сообщения и отправляет их другому элементу-получателю. В процессе отправки брокер обеспечивает промежуточный этап, сохраняя сообщения от продюсера в определенной папке файловой системы.
Для чего нужны брокеры сообщений?
Гарантии доставки сообщений. Если получатель не готов обработать полученную информацию в данный момент, она будет сохранена в очереди, и получатель сможет обработать ее позже.
Повышение производительности. Использование брокеров может повысить производительность благодаря асинхронной обработке сообщений.
Отказоустойчивость и масштабируемость. Способствует созданию отказоустойчивых и масштабируемых систем благодаря асинхронной обработке данных и возможности использовать кластеры брокеров.
Разделение слоев. Допускает разделение слоев приложения, уменьшая связность между ними, что предоставляет возможность сделать приложение более модульным, гибким и удобным в разработке. Также будет полезен при организации микросервисной системы.
Посмотрим на рекомендуемую схему с брокером между сервисами. Здесь мы увидим что брокер сообщений общий для всех сервисов:
Минусы
Усложнение системы. Использование брокеров повлечет за собой увеличение сложности системы за счет добавления нового элемента в нее. Усложняется отладка, обслуживание и администрирование.
Сложность в освоении. Изучение данного ПО может занять длительный период времени из-за сложности архитектуры.
Дополнительная точка отказа. Это место возможного критического отказа, при котором большинство систем не смогут функционировать. Однако, многие брокеры обеспечивают высокую доступность и надежность функционирования. Это потенциальное узкое «горлышко» в производительности.
Мертвые сообщения. В наших старых и забытых очередях существуют мертвые сообщения, которые, казалось бы, потеряли свою актуальность и важность, но они все равно остаются на своих местах.
Дополнительная нагрузка на сеть. Использование брокеров может повлечь за собой дополнительную нагрузку на сеть из-за передачи данных.
?Message broker per service
Используя аналогию с базой данных, мы можем рассмотреть концепцию "брокер сообщений на сервис". В этом случае каждый сервис будет иметь свой собственный брокер сообщений, что позволит каждому сервису независимо управлять своими сообщениями и обеспечивать уровень изоляции, аналогичный тому, который предоставляет паттерн "база данных на сервис". Это может привести к более гибкой и надежной системе. Рассмотрим некоторые проблемы, которые можно эффективно решить с использованием данной архитектуры.
Не явная связанность
Давайте рассмотрим пример, как брокер может быть использован для асинхронного обмена данными между двумя сервисами.
Можем ли мы определить, какой из сервисов работает в асинхронном режиме? Нет, они тесно связаны, как в монолитной структуре, и оба могут быть классифицированы как асинхронные.
? Использование общего брокера повышает взаимосвязанность между сервисами, делая ее более тесной, но менее очевидной, что может усложнить процесс работы.
Теперь давайте приступим к разработке новой схемы.
Как мы видим, у двух сервисов есть свои брокеры и они работают асинхронно. Мы имеем возможность исключить первый брокер, что обеспечит независимость сервиса от брокера, но при этом мы сможем обеспечить асинхронную работу второго сервиса.
Модель, где каждый сервис использует свой собственный брокер сообщений, предполагает обмен данными сервисов исключительно через API, без прямого доступа к очередям друг друга. Это дает возможность иметь единый контракт для асинхронного и синхронного взаимодействия.
Что бы, когда нам потребуется от сервиса синхронный и асинхронный метод, не получить такую схему:
Это также позволит нам проверить модель сразу при входе, что бы не потерять запрос.
Брокер не заменит HTTP
Рассмотрим возможность использования брокера вместо HTTP-канала для решения проблем с сетью и обеспечения надежной доставки сообщений. Брокер функционирует на основе легковесного протокола AMQP, который может работать лучше, чем HTTP. Ниже представлена схема с общим брокером для сервисов. В случае возникновения сетевых проблем при попытке отправить сообщение, существует риск его потери, поскольку у нас может не получиться подключиться к очереди. Только после того, как сообщение попадает в очередь, мы можем гарантировать его доставку в сервис B, если он сразу не сможет подключиться к очереди.
Если рассмотреть ситуацию с отдельным брокером для каждого сервиса, гарантия доставки остается именно на сервисе. В этом случае брокер просто становится инструментом для обеспечения этой гарантии. Даже в случаи обрыве сети, у нас сервис A должен обеспечить повторную отправку сообщения в сервис B.
Таким образом, мы стремимся не накладывать избыточную ответственность на брокера. Вместо этого, мы полагаемся на стратегию повторной доставки, обеспечиваемую нашими политиками.
? Вам не требуется хранить сообщения в брокере длительный период. Достаточно повторить его всего через несколько секунд
Шина сообщений
Когда нам нужно отправлять однотипные сообщения разным подписчикам, мы можем использовать функционал брокера. В контексте общего брокера сообщений, именно брокер выполняет функции оркестратора. Однако в схеме, где каждому сервису присваивается свой брокер, роль оркестратора может выполнять сам сервис.
В этой модели, все сервисы сосредоточены вокруг брокера. При добавлении или удалении подписчика, необходимо будет настройка брокера. Возможно, потребуется отдельный специалист для обслуживания и поддержки этого брокера. Вся система будет ориентирована на этот брокер и нуждается в соединении с ним. Заменить его на другой брокер сообщений будет довольно сложной задачей.
? Брокер сообщений становится центром проекта, от которого зависит вся система.
Назначим определенный сервис в качестве оркестратора, который будет распределять сообщения среди конечных пользователей.
Таким образом, вы получаете аналогичные возможности, но брокер уже не является центром вашей системы. Ответственность за работу прозрачно определяется командой, которая отвечает за данный сервис. Кроме того, между сервисами устанавливается явная связь через REST-интерфейс.
Также стоит отметить, что использование REST-интерфейса для обмена сообщениями между сервисами может существенно упростить процесс разработки и отладки, так как REST является широко применяемым и хорошо документированным подходом к организации взаимодействия между компонентами системы.
Разница:
Отметим разницу между этими подходами
Shared message broker | Message broker per service |
|---|---|
Гарантии доставки сообщений обеспечивает сам брокер | Гарантии доставки сообщений обеспечивает сервис, брокер сообщений используется как инструмент |
Зависимость от одного брокера, каждый новый сервис становится частью существующей системы | Гибкость: каждый сервис может выбирать брокер сообщений, который наилучшим образом соответствует его требованиям |
Размытые границы доменной области, одна бизнес-модель используется в двух и более сервисах | Четкие границы доменной области, сервисы общаются с помощью DTO |
Необходимо дублировать модели между сервисами или публиковать через библиотеки или другие инструменты, задумываясь о версионировании | Контракты распространяются между сервисами через OpenApi, Proto файлы или другие популярные инструменты |
Мертвые сообщения присутствуют в наших старых и забытых очередях, которые относятся либо к продюсеру, либо к подписчику. | Мертвые сообщения также могут находиться в очередях, но ответственность за них можно точно определить к сервису и его команде |
Ошибочные сообщения будут взяты в работу когда поднимется подписчик. | Не доставленные сообщения сразу берутся в повторную обработку |
Сложность из-за неявной связи через объекты, сложно тестировать и вести отладку | Простота: связь между сервисами основана на endpoints, IDE подсвечивает событие в подписчике и продюсере |
Уменьшение связности между сервисами, все взаимодействие происходит через брокер | У сервиса есть связь и со своим брокером сообщений, и с конкретным следующим сервисом, или даже несколькими |
?Подведем итоги
Отказавшись от одного плюса- "Разделение слоев", который предоставлял нам гибкость взаимодействия между сервисами, мы уверенно получаем следующие преимущества:
Изоляция: Подобно паттерну "база данных на сервис", использование отдельного брокера сообщений для каждого сервиса обеспечивает уровень изоляции, позволяющий каждому сервису независимо управлять своими сообщениями.
Гибкость: Каждый сервис может выбрать брокера сообщений, который лучше всего соответствует его требованиям. Это может включать различные аспекты, такие как производительность, надежность, сложность и стоимость.
Очевидные связи: Изучение данного ПО может занять меньше времени, благодаря более очевидной связи между сервисами.
Статья предлагает альтернативный подход к использованию брокера сообщений - предоставление отдельного брокера для каждого сервиса. Этот подход может быть более простым и надежным, но не является единственно верным. Как и в случае с выбором между отдельной базой данных для каждого сервиса и общей базой данных, каждый подход имеет свои преимущества и недостатки
В зависимости от контекста вашего проекта, вы можете выбрать подход, который наиболее соответствует вашим требованиям. Основной ключ к успеху - это хорошо продуманная архитектура и четкое понимание ваших потребностей и ограничений.
