Задумывались ли вы, почему мы используем отдельную базу данных для каждого сервиса, но при этом один общий брокер для нескольких сервисов? Ведь вполне возможно использовать базу данных в роли брокера сообщений. Однако, если мы попробуем заменить RabbitMQ на Redis, то натолкнемся на проблему общего использования базы данных. Это станет проблемой, потому что общее использование базы данных является антипаттерном.
В микросервисной архитектуре существуют два основных подхода к организации баз данных:
Общая база данных - это хорошее решение для небольших проектов без амбициозных планов на рост. Однако, в контексте микросервисной архитектуры, это считается антипаттерном, поскольку невозможно независимо тестировать и масштабировать два сервиса, использующие одну базу данных. В итоге, эти сервисы больше похожи на один сервис, который может превратиться в монолит.
Подход с отдельной базой данных для каждого сервиса подразумевает, что каждый сервис использует свою собственную базу. Сервис может получать данные другого сервиса только через API, без прямого подключения к его базе данных. Это позволяет командам выбирать базы данных, которые им больше подходят. Например, кто-то может предпочесть MongoDB, другие могут предпочесть PostgreSQL, а для кого-то будет достаточно Redis.
<aside> 💡 Database per service - подход, где каждый сервис имеет свою базу данных, обеспечивая изоляцию и независимость.
</aside>
Брокер сообщений - это архитектурный паттерн в распределённых системах, где элементы системы общаются через посредника. Брокер упрощает работу веб-сервисов, отвечая за пересылку сообщений и все связанные задачи.
В работе брокера сообщений участвуют два ключевых элемента: producer (создатель сообщений) и consumer (получатель/подписчик). Один элемент создает сообщения и отправляет их другому элементу-получателю. В процессе отправки брокер обеспечивает промежуточный этап, сохраняя сообщения от продюсера в определенной папке файловой системы.