Брокеры и ESB

Что это и зачем нужно

Простая аналогия: Telegram вместо телефонного звонка

Проблема прямого взаимодействия (как звонок):

• Сервис А должен ждать ответа от Сервиса Б
• Если Сервис Б "спит" (на обновлении) — ошибка или потеря данных
• Сервис Б перегружен? Сервис А будет долго ждать
• Много отправителей? Сервис Б не справится с нагрузкой

Решение — брокер (как мессенджер):

Сервис А → [Брокер] → Сервис Б

1. Сервис А быстро "сбрасывает" сообщение в брокер и идёт дальше
2. Брокер надёжно хранит сообщение
3. Сервис Б забирает сообщение, когда готов его обработать

Какие проблемы решает брокер?

Проблема без брокера	Решение с брокером
Блокировка — один сервис ждёт другого	Асинхронность — работа продолжается без ожидания
Потеря данных при сбое одного из сервисов	Надёжное хранение — сообщения не теряются
Перегрузка сервиса-получателя	Балансировка нагрузки — получатель работает в комфортном темпе
Сложная маршрутизация между многими сервисами	Централизованное управление потоками сообщений

Как работают брокеры "под капотом"

Где хранятся сообщения?

Ключевое понятие: персистентность (persistence)

Режим	Как работает	Когда использовать
В памяти	Быстро, но при перезагрузке брокера данные теряются	Не критичные данные, кэши, временные задачи
На диске	Медленнее, но данные сохраняются при сбоях	Финансовые операции, заказы, документы

Аналогия для понимания:

• Без персистентности = оставить записку на столе (может потеряться)
• С персистентностью = отправить заказное письмо с уведомлением (гарантия доставки)

Как обеспечивается гарантированная доставка?

Двухэтапная система подтверждений:

1. Этап 1: От отправителя к брокеру

   Отправитель → [Запись на диск] → ACK → Отправитель
   • Сообщение сначала записывается на диск
   • Только потом отправитель получает подтверждение
   • Если ACK не пришёл — отправитель отправляет повторно

2. Этап 2: От брокера к получателю

   Брокер → Получатель → [Обработка] → ACK → Брокер → Удаление
   • Получатель должен явно подтвердить обработку
   • Без подтверждения брокер отправляет сообщение другому получателю
   • Это гарантирует: сообщение обработано хотя бы один раз

Уровни гарантий доставки

Гарантия	Что означает	Пример для 1С
At-most-once (макс. один раз)	Может потеряться, но не дублироваться	Отправка уведомлений о новостях
At-least-once (мин. один раз)	Не потеряется, но могут быть дубли	Проводки, документы
Exactly-once (ровно один раз)	Сложная настройка, без дублей	Платёжные операции, кассовые чеки

Важно для 1С-разработчика: Реализуйте идемпотентность — при повторной обработке того же сообщения результат не должен меняться (проверка "такой документ уже есть").

RabbitMQ и Kafka

RabbitMQ — универсальный "почтальон"

Что это:

• Классический брокер сообщений
• Сообщение → Очередь → Получатель
• После обработки сообщение удаляется

Идеально для:

# Примеры сценариев для RabbitMQ:
1. Отправка email после оформления заказа
2. Генерация PDF-отчётов по расписанию  
3. Синхронизация данных между несколькими базами 1С
4. Обработка фоновых задач

Особенности RabbitMQ:

• ✅ Гибкая маршрутизация — можно направлять сообщения по сложным правилам
• ✅ Приоритеты сообщений — срочные задачи обрабатываются быстрее
• ✅ Простой старт — есть веб-интерфейс для мониторинга
• ✅ Push-модель — брокер сам отправляет сообщения получателям

Apache Kafka — "журнал событий"

Что это:

• Распределённый журнал всех событий системы
• Сообщения хранятся долго (дни, недели)
• Многие потребители могут читать одни и те же события

Идеально для:

# Примеры сценариев для Kafka:
1. Аналитика посещений сайта (каждый клик — событие)
2. Аудит всех действий пользователей в системе
3. Сбор логов со множества серверов
4. Системы реального времени (биржевые котировки)

Особенности Kafka:

• ✅ Хранение истории — можно перечитать события за прошлую неделю
• ✅ Масштабируемость — легко добавлять новые серверы
• ✅ Много потребителей — аналитика, мониторинг, уведомления читают одни данные
• ❌ Сложнее архитектура — нужно понимать топики, партиции, offset'ы

Сравнительная таблица: Что выбрать для проекта 1С?

Критерий	RabbitMQ	Apache Kafka
Модель данных	Очередь сообщений	Журнал событий
После чтения	Удаляется	Остаётся в истории
Масштабирование	Вертикальное (мощнее сервер)	Горизонтальное (+ серверы)
Скорость старта	Быстро, понятно	Требует изучения
Для 1С-систем	Чаще используется! Интеграции, фоновые задачи	Аналитика, аудит, Big Data

Простое правило выбора:

• RabbitMQ — если нужно "доставить задание" (обработать документ, отправить письмо)
• Kafka — если нужно "сохранить историю событий" для анализа

С версии 3.9 RabbitMQ поддерживает Stream Queues, которые работают по принципу Kafka:

• ✅ Сообщения хранятся (не удаляются сразу после чтения)
• ✅ Недеструктивное потребление — несколько потребителей могут читать одни данные
• ✅ Возможность replay — можно вернуться и перечитать историю сообщений

Теперь RabbitMQ может использоваться и как классическая очередь, и как потоковый брокер (аналог Kafka).

1С:Шина

Что такое 1С:Шина?

Представьте: У вас есть 3 базы 1С, сайт, мобильное приложение и CRM. Все они должны обмениваться данными. Без 1С:Шины получается "паутина" связей:

1С УТ → 1С БП → 1С ЗУП
  ↓       ↓       ↓
Сайт → CRM ← Мобильное приложение

С 1С:Шиной: все общаются через единый центр:

       [ 1С:Шина ]
       ↗ ↑  ↑ ↖ ↖
Все системы общаются только с Шиной

Преимущества 1С:Шины для разработчика 1С

1. "Из коробки" работает с 1С

   • Встроенный механизм сервисов интеграции
   • Не нужно писать сложные обмены вручную
   • Обновления конфигураций не ломают интеграции

2. Все протоколы в одном месте

   // 1С:Шина поддерживает:
   - Веб-сервисы (SOAP)
   - REST API (HTTP)
   - Файловый обмен (FTP, сетевые папки)
   - Брокеры сообщений: RabbitMQ, Kafka, ActiveMQ
   - Прямой доступ к БД (JDBC для MS SQL, PostgreSQL)

3. Гарантии как у брокеров

   • Сообщения хранятся на диске до подтверждения доставки
   • Автоматические повторы при сбоях
   • Мониторинг всех обменов в одном интерфейсе

4. Не снимает с поддержки

   • Доработки через расширения
   • Официальная поддержка от 1С
   • Входит в реестр российского ПО

Пример из жизни: Интернет-магазин на 1С

Без 1С:Шины:

Проблемы:
1. Сайт падает, если 1С на обновлении
2. Заказы теряются при сетевых сбоях
3. Непонятно, где "застрял" конкретный заказ
4. Добавили CRM — переписываем все интеграции

С 1С:Шиной:

Решение:
1. Сайт → [1С:Шина] → Заказ сохранён, сайт продолжает работу
2. 1С прочитает заказ, когда вернётся с обновления
3. Добавили CRM → просто подключаем к Шине

Что использовать и когда

Быстрый чек-лист для выбора

Выбирайте RabbitMQ, если:

• Нужна простая очередь задач
• Сообщение нужно обработать один раз и забыть
• Важна гибкая маршрутизация (разным получателям — разные сообщения)
• Есть срочные и несрочные задачи (приоритеты)
• Хотите быстро запустить и чтобы "просто работало"

Выбирайте Kafka, если:

• Нужно хранить историю событий
• Одни данные читают много систем (аналитика + уведомления + логгирование)
• Обрабатываете потоки данных в реальном времени
• Ожидаете огромные нагрузки (тысячи сообщений в секунду)
• Готовы разбираться с топиками, партициями, consumer groups

Выбирайте 1С:Шину, если:

• Основная экосистема — продукты 1С
• Хотите единую точку управления всеми интеграциями
• Важна официальная поддержка и обновления
• Нужны гарантии доставки "из коробки"
• Команда знает 1С, но не хочет глубоко изучать RabbitMQ/Kafka

Выводы

Три ключевых вывода:

1. Брокеры решают проблему "звонка" — сервисы не блокируют друг друга
2. Гарантии доставки — это запись на диск + подтверждения — без этого теряются данные
3. Выбор инструмента зависит от задачи — нет "лучшего", есть "подходящий"

Что запомнить про каждый инструмент:

Инструмент	Аналогия	Главное преимущество для 1С
RabbitMQ	Почтальон с квитанцией	Простота + гибкая маршрутизация
Kafka	Журнал регистрации событий	История + масштабируемость
1С:Шина	Центральный коммутатор в офисе	"Родная" интеграция + единое управление

Материалы

• Выбор между RabbitMQ и Apache Kafka

• Kafka для начинающих: откуда такой спрос и зачем нужна эта технология

• 1С:Шина