🔥 3 реальных задачи, которые решают брокеры 🔥
Брокеры сообщений — это не просто очереди для передачи данных. Это ТОП-инструмент для построения асинхронных, отказоустойчивых и масштабируемых систем.
Они позволяют сервисам взаимодействовать без жесткой связанности, гарантируют доставку сообщений и помогают балансировать нагрузку.
Разберем три основных кейса, когда без брокеров не обойтись:
📌 1. Централизованная отправка уведомлений
Без брокера каждый сервис должен напрямую взаимодействовать с системой уведомлений, что создает жесткую зависимость.
Вместо этого сервисы просто отправляют события в брокер, а сервис уведомлений обрабатывает их, когда будет готов.
👍 Почему так лучше?
+ Уменьшается связанность между сервисами
Если сервис уведомлений перегружен и не может принять сообщение сразу, оно сохранится в брокере.
Отправивший задачу на уведомление сервис не зависает в ожидании ответа, а продолжает работу.
+ Гибкое масштабирование
Когда 15 сервисов генерируют уведомления, для их обработки может понадобиться от 5 до 15 экземпляров сервиса уведомлений.
Без брокера система должна мгновенно реагировать на всплески нагрузки и увеличивать количество работающих копий сервиса уведомлений.
С брокером это не критично — сообщения просто ставятся в очередь и обрабатываются позже.
+ Можно легко добавлять новые каналы уведомлений (почта, пуши, SMS)
Например, в сервисе заказов сменился статус товара на "Доставлен".
Пользователь подписан на push, SMS и email-уведомления
Вместо того, чтобы сервису заказов делать три запроса или один долгий и ждать, пока каждое уведомление отправится, мы положим событие о смене статуса в брокер с пометкой о каналах доставки. А сервис уведомлений позже его обработает.
Таким образом, сервису заказов не придётся длительно ожидать ответ о доставке всех уведомлений.
📌 2. Централизованный сбор событий для мониторинга
Все сервисы отправляют в брокер данные о своих состояниях, ошибках, метриках. Из брокера эти события забирает система мониторинга, анализирует их и отправляет алерты DevOps-инженерам.
👍 Почему так лучше?
+ Все данные собираются в одном месте
Логи, ошибки, метрики и другие события поступают в брокер от всех сервисов, упрощая их обработку и анализ.
+ Гибкость и независимость от конкретной системы мониторинга
Можно легко подключать новые инструменты анализа и визуализации (Prometheus, ELK, Grafana и др.), не внося изменения в код сервисов, которые генерируют события.
Без брокера пришлось бы перенастраивать все сервисы на доставку в новый сервис мониторинга.
+ Гибкое масштабирование
📌 3. Реакция нескольких сервисов на одно событие
Один сервис отправляет событие в брокер, а сразу несколько других сервисов на него реагируют.
Пример:
При успешной оплате заказа в Интернет-Магазине сервис платежей отправляет событие "Оплата успешна" в брокер.
На это событие реагируют три сервиса:
▫️ Сервис заказов переводит статус заказа в "Оплачен"
▫️ Сервис склада списывает товары и создает задачу на сборку
▫️ Сервис уведомлений отправляет клиенту подтверждение об оплате
Если бы сервис платежей напрямую дергал API каждого сервиса, это привело бы к сильной связанности и проблемам при сбоях.
Сервис склада упал?
➖ Прервали процесс обработки события оплаты, потому что не получилось достучаться до склада
➖ Или потеряли уведомление о платеже и оно не дошло на склад
Брокер позволяет сделать процесс асинхронным и надежным.
👍 Почему так лучше?
+ Уменьшается связанность между сервисами
За счет асинхронного обмена и отвязки от режима реального времени, когда все должны работать и быть доступны.
+ Можно легко добавлять новые подписчики без изменений в коде исходного сервиса
Например, когда после успешной оплаты надо еще начислить бонусные баллы в сервисе лояльности, то мы добавим новый обработчик события из брокера, но не будем трогать код сервиса платежей.
+ Лучше отказоустойчивость
Нет риска, что событие не обработается в каком-либо сервисе - брокер даёт гарантию доставки.
+ Гибкое масштабирование
Итого:
Брокеры — залог гибкой, масштабируемой и отказоустойчивой архитектуры 👍
#АрхитектураGA
Брокеры сообщений — это не просто очереди для передачи данных. Это ТОП-инструмент для построения асинхронных, отказоустойчивых и масштабируемых систем.
Они позволяют сервисам взаимодействовать без жесткой связанности, гарантируют доставку сообщений и помогают балансировать нагрузку.
Разберем три основных кейса, когда без брокеров не обойтись:
📌 1. Централизованная отправка уведомлений
Без брокера каждый сервис должен напрямую взаимодействовать с системой уведомлений, что создает жесткую зависимость.
Вместо этого сервисы просто отправляют события в брокер, а сервис уведомлений обрабатывает их, когда будет готов.
👍 Почему так лучше?
+ Уменьшается связанность между сервисами
Если сервис уведомлений перегружен и не может принять сообщение сразу, оно сохранится в брокере.
Отправивший задачу на уведомление сервис не зависает в ожидании ответа, а продолжает работу.
+ Гибкое масштабирование
Когда 15 сервисов генерируют уведомления, для их обработки может понадобиться от 5 до 15 экземпляров сервиса уведомлений.
Без брокера система должна мгновенно реагировать на всплески нагрузки и увеличивать количество работающих копий сервиса уведомлений.
С брокером это не критично — сообщения просто ставятся в очередь и обрабатываются позже.
+ Можно легко добавлять новые каналы уведомлений (почта, пуши, SMS)
Например, в сервисе заказов сменился статус товара на "Доставлен".
Пользователь подписан на push, SMS и email-уведомления
Вместо того, чтобы сервису заказов делать три запроса или один долгий и ждать, пока каждое уведомление отправится, мы положим событие о смене статуса в брокер с пометкой о каналах доставки. А сервис уведомлений позже его обработает.
Таким образом, сервису заказов не придётся длительно ожидать ответ о доставке всех уведомлений.
📌 2. Централизованный сбор событий для мониторинга
Все сервисы отправляют в брокер данные о своих состояниях, ошибках, метриках. Из брокера эти события забирает система мониторинга, анализирует их и отправляет алерты DevOps-инженерам.
👍 Почему так лучше?
+ Все данные собираются в одном месте
Логи, ошибки, метрики и другие события поступают в брокер от всех сервисов, упрощая их обработку и анализ.
+ Гибкость и независимость от конкретной системы мониторинга
Можно легко подключать новые инструменты анализа и визуализации (Prometheus, ELK, Grafana и др.), не внося изменения в код сервисов, которые генерируют события.
Без брокера пришлось бы перенастраивать все сервисы на доставку в новый сервис мониторинга.
+ Гибкое масштабирование
📌 3. Реакция нескольких сервисов на одно событие
Один сервис отправляет событие в брокер, а сразу несколько других сервисов на него реагируют.
Пример:
При успешной оплате заказа в Интернет-Магазине сервис платежей отправляет событие "Оплата успешна" в брокер.
На это событие реагируют три сервиса:
▫️ Сервис заказов переводит статус заказа в "Оплачен"
▫️ Сервис склада списывает товары и создает задачу на сборку
▫️ Сервис уведомлений отправляет клиенту подтверждение об оплате
Если бы сервис платежей напрямую дергал API каждого сервиса, это привело бы к сильной связанности и проблемам при сбоях.
Сервис склада упал?
➖ Прервали процесс обработки события оплаты, потому что не получилось достучаться до склада
➖ Или потеряли уведомление о платеже и оно не дошло на склад
Брокер позволяет сделать процесс асинхронным и надежным.
👍 Почему так лучше?
+ Уменьшается связанность между сервисами
За счет асинхронного обмена и отвязки от режима реального времени, когда все должны работать и быть доступны.
+ Можно легко добавлять новые подписчики без изменений в коде исходного сервиса
Например, когда после успешной оплаты надо еще начислить бонусные баллы в сервисе лояльности, то мы добавим новый обработчик события из брокера, но не будем трогать код сервиса платежей.
+ Лучше отказоустойчивость
Нет риска, что событие не обработается в каком-либо сервисе - брокер даёт гарантию доставки.
+ Гибкое масштабирование
Итого:
Брокеры — залог гибкой, масштабируемой и отказоустойчивой архитектуры 👍
#АрхитектураGA