Асинхронный обмен между базами 1С

Асинхронный обмен между базами 1С

Введение

Обмен между базами 1С, как правило, строится по одному из классических сценариев - РИБ или с помощью правил конвертации данных. Эти подходы хорошо известны и в большинстве проектов работают удовлетворительно и полнстью покрывают потребности в обмене. Проблемы начинаются не на старте, а при росте системы:

* увеличивается количество узлов
* растёт объём передаваемых данных
* появляются внешние интеграции
* нагрузка становится неравномерной
* каналы связи перестают быть идеально стабильными

И в этот момент выясняется, что основная сложность не в правилах обмена и не в конкретной реализации, а в самой архитектуре — большинство обменов построены по синхронной модели «точка-точка»:

* одна база отправляет данные другой и ждёт результата
* если принимающая сторона недоступна — обмен останавливается
* если сеть нестабильна — возникают повторы
* если поток большой — могут начать проблемы на уровне железа

Это естественное ограничение синхронной архитектуры. В этой статье я хочу разобрать альтернативный подход — асинхронный обмен через брокер сообщений — и показать, в каких случаях он действительно оправдан.

Проблемы классического обмена

На практике чаще всего встречаются следующие узкие места:

1. Жадная выгрузка

В файл или пакет попадают все связанные данные, даже если они уже были переданы ранее. Это увеличивает:

* объём трафика
* нагрузку на процессор
* время выгрузки
* время загрузки

2. Синхронность

В случае если данные передаются через COM-соединение отправитель фактически зависит от состояния получателя. Если принимающая база занята или недоступна — процесс блокируется. С ростом числа узлов количество связей между ними растёт экспоненциально.

3. Скорость обмена

Эта проблема является следствием архитектуры жадной выгрузки и усугубляется при обмене через выгрузку в файл.

Архитектурная идея: асинхронный обмен

Альтернатива синхронной модели — разделить участников обмена через посредника (брокера сообщений).

Архитектура становится следующей:

1. Отправитель передаёт сообщение Брокеру и не ждёт обработки получателем
2. Брокер сохраняет сообщение
3. Получатель самостоятельно запрашивает данные у Брокера
4. Обработка происходит независимо от отправителя

Таким образом устраняется жёсткая зависимость между узлами. Базы перестают «ждать друг друга».

Роль WebSocket и сервера брокера

Начиная с версии 8.3.27 в платформе 1С появился WebSocketКлиент. Это позволяет базе выступать клиентом при постоянном соединении. Однако WebSocket-сервером 1С быть не может, поэтому требуется отдельный сервис. В моём случае брокер реализован на Go — из-за высокой производительности и удобной параллельной обработки. Важно подчеркнуть: выбор языка не принципиален. Принципиальна сама модель — асинхронный обмен через персистентный посредник.

Как работает отправитель

Перед отправкой объект регистрируется к обмену. Для каждого объекта формируется уникальный идентификатор обмена (exchange_id) в следующем формате:

```
guid#version#type
```

Пример:

```
ad178c88-1b07-4234-11f1-063fc697887f#AAAA-BFAA#Документ.ПриходнаяНакладная
```

В сообщении передаются:

* exchange_id
* JSON с данными

Это принципиальный момент: обмен строится не вокруг ссылок 1С, а вокруг независимых идентификаторов.

Как работает Брокер

Брокер:

* принимает сообщения
* сохраняет их персистентно
* выдаёт по запросу получателям
* фиксирует факт передачи

Он не интерпретирует данные и не знает ничего о бизнес-логике.

Модель доставки — **at least once**. Это означает, что сообщение гарантированно будет доставлено, но возможно повторно. Повторная обработка должна быть безопасной — это обеспечивается идемпотентностью на стороне получателя.

Как работает получатель

Получатель не обрабатывает сообщения «на лету». Алгоритм следующий:

1. Получение пакета сообщений
2. Сохранение в регистр предзагрузки
3. Проверка зависимостей
4. Если все зависимости получены — загрузка объекта
5. Если нет — ожидание следующего цикла загрузки

Таким образом решается проблема порядка поступления данных. Получатель может безопасно получать объекты в любом порядке, а воспроизводить их только при наличии всех ссылок. В целях оптимизации в отправителе можно (но не обязательно) установить приоритет выгрузки для разных объектов, Получателя тогда тоже имеет смысл настроить на загрузку по приоритету.

Гарантии и устойчивость

При такой архитектуре:

* падение получателя не влияет на отправителя
* падение отправителя не блокирует других участников
* сообщения не теряются при кратковременных сбоях
* возможна горизонтальная масштабируемость брокера

Ответственность за полноту данных лежит на отправителе. Брокер отвечает только за доставку.

Когда такой подход оправдан

Асинхронный обмен через брокер имеет смысл, если выполняется хотя бы одно из условий:

* 3 и более узлов
* большой поток сообщений
* нестабильные каналы связи
* требования к отказоустойчивости
* необходимость масштабирования

Если же обмен происходит между двумя базами в локальной сети с небольшим объёмом данных — классические механизмы могут быть проще и достаточны.

Итог

Асинхронная архитектура не заменяет привычные механизмы обмена. Она решает конкретную задачу — устойчивый обмен в распределённой системе с ростом нагрузки. Когда система выходит за пределы «файлов раз в ночь», появляется необходимость:

* убрать синхронные блокировки
* минимизировать объём передаваемых данных
* обеспечить гарантированную доставку
* разделить ответственность между узлами

Брокер сообщений — один из способов этого добиться.