2013 подписчиков
🦫Создание оркестратора для событийно-ориентированного приложения с Golang и RabbitMQ
Определение требований
Номера в гостинице бронируются по мере доступности.
• Создадим конвейер передачи запроса на бронирование номера по различным сервисам: резервирования, проверки, зачисления средств, бронирования.
Сервисам не нужно ждать ответа друг от друга — они даже не «знают», откуда запрос: у каждого сервиса только одна задача, и он хорошо с ней справляется. Это называется снижением связанности. Не нужно задумываться о причине запроса и ждать ответа других сервисов — используем все преимущества архитектуры микросервисов.
Сначала создадим блок-схему: показано в картинке.
Как видите, всего четыре этапа:
1. Проверка: в некоторых сценариях гостиницами обслуживаются не все желающие, например кому-то закрыт доступ или определенный номер резервируется только для конкретной группы. Это сложные правила, отделим их от веб-API.
2. Резервирование: одновременное бронирование номера несколькими людьми предотвращается глобальной блокировкой, подобной Redis.
3. Списание: зарезервировав номер, списываем средства.
4. Бронирование: завершив процесс списания, удаляем резервирование и бронируем номер.
Но в любом сервисе случаются ошибки.
Оркестрация — отличное подспорье для создания стабильного потока запросов, обработки ошибок и соответственных действий.
Действия требуются при очевидных ошибках:
• Недостаточно средств: удаляем резервирование.
• Ошибка при бронировании: возвращаем средства и удаляем резервирование.
Настройка RabbitMQ
Не знакомы с RabbitMQ? Посмотрите руководство для начинающих, хотя основы мы разберем.
RabbitMQ, как и Apache Kafka, — это приложение с отправителями и получателями сообщений. В приложении-чате отправителями сообщение отправляется, получателями — получается.
Как сообщению попасть к моему другу, а не случайному человеку в другой группе? Это сложная часть.
📌 Читать
1 минута
8 августа 2023