2020 подписчиков

🦫Создание оркестратора для событийно-ориентированного приложения с Golang и RabbitMQ

Определение требований

Номера в гостинице бронируются по мере доступности.

• Создадим конвейер передачи запроса на бронирование номера по различным сервисам: резервирования, проверки, зачисления средств, бронирования.

Сервисам не нужно ждать ответа друг от друга — они даже не «знают», откуда запрос: у каждого сервиса только одна задача, и он хорошо с ней справляется. Это называется снижением связанности. Не нужно задумываться о причине запроса и ждать ответа других сервисов — используем все преимущества архитектуры микросервисов.

Сначала создадим блок-схему: показано в картинке.

Как видите, всего четыре этапа:

1. Проверка: в некоторых сценариях гостиницами обслуживаются не все желающие, например кому-то закрыт доступ или определенный номер резервируется только для конкретной группы. Это сложные правила, отделим их от веб-API.

2. Резервирование: одновременное бронирование номера несколькими людьми предотвращается глобальной блокировкой, подобной Redis.

3. Списание: зарезервировав номер, списываем средства.

4. Бронирование: завершив процесс списания, удаляем резервирование и бронируем номер.

Но в любом сервисе случаются ошибки.

Оркестрация — отличное подспорье для создания стабильного потока запросов, обработки ошибок и соответственных действий.

Действия требуются при очевидных ошибках:

• Недостаточно средств: удаляем резервирование.

• Ошибка при бронировании: возвращаем средства и удаляем резервирование.

Настройка RabbitMQ

Не знакомы с RabbitMQ? Посмотрите руководство для начинающих, хотя основы мы разберем.

RabbitMQ, как и Apache Kafka, — это приложение с отправителями и получателями сообщений. В приложении-чате отправителями сообщение отправляется, получателями — получается.

Как сообщению попасть к моему другу, а не случайному человеку в другой группе? Это сложная часть.

📌 Читать

@golang

1 минута

8 августа 2023