Классическая картина: обмен с 1С ходит раз в пятнадцать минут, перекладывает весь массив остатков, и всё это время сайт живёт с устаревшими данными. Ходовой товар продали в опте, но на сайте он ещё «в наличии» — покупатель оформляет заказ, а его нечем отгружать. Плюс сам тяжёлый обмен раз в интервал даёт всплеск нагрузки, во время которого каталог подтормаживает. Пакетная синхронизация по расписанию — узкое место, которое одновременно и медленное, и тяжёлое.
Эта статья — о том, как перейти от пакетного обмена к событийной (event-driven) архитектуре синхронизации заказов и складов между сайтом на 1С-Битрикс и 1С: что такое события, зачем очереди и идемпотентность, как гарантировать доставку и как совместить это со штатным CommerceML. Такие интеграции мы проектируем и внедряем в рамках автоматизации продаж и склада на 1С.
Коротко
- Event-driven реагирует на конкретное изменение, а не перекладывает весь массив по расписанию — данные свежее, нагрузка ниже.
- Надёжность держится на очередях, подтверждениях доставки и повторах при сбоях.
- Идемпотентность обязательна: события дублируются, и обработчик не должен применять изменение дважды.
- Оптимален гибрид — событийная модель для оперативных данных поверх штатного обмена CommerceML как основы.
Боль пакетного обмена по расписанию
Пакетный обмен устроен просто: по таймеру запускается процедура, которая выгружает и загружает данные целиком или большими порциями. Пока каталог и заказы невелики, это работает. Но с ростом бизнеса проявляются два системных недостатка.
Первый — задержка. Остаток на сайте всегда отстаёт от учёта на интервал обмена. Для ходовых позиций это прямой источник оверселлинга: товар уже продан в другом канале, а сайт ещё принимает заказы. Второй — нагрузка. Тяжёлый обмен раз в интервал создаёт пиковую нагрузку, во время которой витрина проседает. Уменьшать интервал, чтобы данные были свежее, — значит чаще нагружать систему. Пакетная модель ставит скорость и стабильность в конфликт.
Что такое event-driven подход
Событийная архитектура меняет логику: вместо «периодически переложить всё» — «отреагировать на то, что изменилось». Каждое значимое изменение порождает событие — маленькое сообщение «что и как поменялось», которое надёжно доставляется заинтересованной системе.
| Критерий | Пакетный обмен | Event-driven |
|---|---|---|
| Триггер | Таймер | Изменение данных |
| Объём за раз | Весь массив | Одно изменение |
| Свежесть | Интервал обмена | Секунды–минуты |
| Нагрузка | Пики по расписанию | Равномерный поток |
| Масштабирование | Тяжелеет с ростом | Горизонтальное по воркерам |
Событийная модель убирает конфликт скорости и стабильности: данные свежее, потому что реакция мгновенная, и нагрузка ровнее, потому что вместо редких тяжёлых пакетов система обрабатывает поток мелких событий.
События заказов и остатков
Начать стоит с определения событий предметной области — что именно считается значимым изменением.
- Остаток изменился. Продажа, поступление, списание — событие с товаром, складом и новым значением.
- Цена изменилась. Пересмотр цены или типа цены для группы клиентов.
- Создан заказ. Оформление на сайте порождает событие для создания документа в 1С.
- Статус заказа изменился. Оплачен, собран, отгружён — двигает статус в обеих системах.
Каждое событие несёт минимально необходимые данные и стабильный идентификатор. Оно описывает факт («остаток стал равен N»), а не команду, — это делает обработку предсказуемой и упрощает идемпотентность. Аккуратная работа с сущностями заказов и остатков на уровне ORM здесь важна; подходы мы разбираем в статье про D7 ORM в Битрикс.
Очереди и надёжная доставка
Прямая синхронная отправка события «в лоб» хрупка: если приёмник недоступен, событие теряется или блокирует отправителя. Поэтому между отправителем и получателем ставят очередь.
Очередь развязывает системы во времени: событие складывается в неё и обрабатывается воркером тогда, когда получатель готов. Что это даёт:
- Устойчивость к недоступности. 1С временно не отвечает — события ждут в очереди, а не пропадают.
- Сглаживание пиков. Всплеск заказов не кладёт систему, воркеры разбирают очередь в своём темпе.
- Масштабирование. Больше нагрузки — больше воркеров на той же очереди.
- Развязку сайта и учёта. Оформление заказа не ждёт ответа 1С в реальном времени.
Идемпотентность обработчиков
Гарантия «хотя бы один раз» означает, что события неизбежно будут повторяться: сеть переотправит, воркер упадёт после применения, но до подтверждения. Если обработчик списывает остаток на каждое получение, дубликат испортит данные — товар «уйдёт» дважды.
Решение — идемпотентность: обработчик даёт один и тот же результат при повторной доставке одного события. Реализуют это так:
- Стабильный идентификатор события. Уникальный ключ, одинаковый при повторах.
- Журнал обработанных событий. Перед применением проверяется, не обработан ли этот идентификатор.
- Факты вместо дельт. «Остаток равен N» безопаснее «уменьши на 1»: повтор факта не ломает данные.
- Атомарность. Применение изменения и отметка об обработке — в одной транзакции.
Без идемпотентности событийная синхронизация опасна: любой сетевой повтор превращается в порчу остатков или задвоение заказа.
Двусторонний поток с 1С
Синхронизация заказов и складов двусторонняя, и события ходят в обе стороны. С сайта в 1С уходит поток о заказах и действиях клиента, из 1С на сайт — об остатках, ценах и статусах.
- Сайт → 1С. Оформлен заказ — событие создаёт документ в учёте; клиент оплатил — событие фиксирует оплату.
- 1С → сайт. Изменился остаток или статус заказа — событие обновляет витрину и личный кабинет.
Со стороны 1С-Битрикс входящие события удобно принимать через защищённые вебхуки, а исходящие — публиковать в очередь. Как безопасно строить такие точки приёма, мы разбираем в статье про REST, вебхуки и безопасность в Битрикс. Важно, чтобы обе стороны договорились о формате событий и идентификаторах, иначе рассинхрон неизбежен.
Гибрид с обменом CommerceML
Событийная модель не обязана заменять штатный обмен целиком — чаще выгоден гибрид. Тяжёлый обмен CommerceML остаётся для полной выгрузки каталога и первичной синхронизации, а события работают поверх для оперативных данных.
Разделение ответственности выглядит так:
- CommerceML. Полный каталог, справочники, первичная загрузка, периодическая сверка.
- События. Остатки ходовых позиций, цены, статусы заказов — всё, где важна свежесть.
- Сверка по расписанию. Редкая полная выгрузка как страховка, выравнивающая накопленные расхождения.
Такой гибрид сочетает согласованность пакетного обмена с актуальностью событий и снижает риск перехода: базовая интеграция остаётся, а событийный слой добавляется поверх поэтапно.
Обработка ошибок и повторы
В распределённой системе ошибки — норма, а не исключение. Архитектура должна их переживать, а не падать.
- Экспоненциальные повторы. При временной ошибке событие переобрабатывается с нарастающей паузой.
- Очередь недоставленных (dead letter). События, что не обработались после N попыток, уходят в отдельную очередь на разбор, а не теряются.
- Журнал событий. Лог позволяет восстановить состояние воспроизведением при серьёзном сбое.
- Ограничение отравляющих сообщений. Одно битое событие не должно блокировать всю очередь.
Комбинация очереди, подтверждений, повторов и dead letter даёт практическую гарантию: изменение либо применится, либо попадёт в видимую очередь ошибок, но не пропадёт молча.
Мониторинг и наблюдаемость
Событийную систему нельзя эксплуатировать вслепую. Без наблюдаемости накопившийся затор в очереди или растущий dead letter заметят только по жалобам клиентов.
- Глубина очередей. Растущая очередь — сигнал, что воркеры не справляются или получатель недоступен.
- Задержка обработки. Время от возникновения события до применения.
- Ошибки и dead letter. Всплеск недоставленных событий требует немедленной реакции.
- Расхождения при сверке. Метрика того, насколько события и пакетный обмен согласованы.
Наблюдаемость превращает событийную интеграцию из «чёрного ящика» в управляемую систему, где проблему видно до того, как её увидит клиент.
Реализация в 1С-Битрикс
Технически событийный слой в 1С-Битрикс собирается из штатных механизмов плюс аккуратной инженерии.
- Определите события. Опишите факты предметной области, их данные и идентификаторы.
- Ловите изменения. Обработчики событий Битрикс на заказах и остатках публикуют события в очередь.
- Заведите очередь и воркеры. Агенты, cron-воркеры или внешний брокер разбирают очередь.
- Сделайте обработчики идемпотентными. Журнал обработанных событий и атомарное применение.
- Настройте приём от 1С. Защищённые вебхуки для входящих событий об остатках и статусах.
- Добавьте повторы и мониторинг. Dead letter, экспоненциальные повторы, метрики очередей.
- Внедряйте поэтапно. Начните с одного потока — остатков ходовых позиций — поверх существующего обмена.
Такой слой обычно оформляют как отдельный модуль с чистой архитектурой — это надёжнее правок в шаблонах; см. статью про разработку модуля под Битрикс. А безопасную и предсказуемую выкатку изменений интеграции обеспечивает CI/CD и деплой в Битрикс.
Частые ошибки
- Синхронная отправка без очереди. Недоступность 1С блокирует оформление заказа или теряет событие.
- Неидемпотентные обработчики. Повтор события задваивает списание остатка или заказ.
- Дельты вместо фактов. «Уменьши на 1» ломается при повторе; «остаток равен N» — нет.
- Нет dead letter. Битое событие теряется молча или блокирует очередь.
- Отсутствие мониторинга. Затор в очереди замечают только по жалобам клиентов.
- Резкий переход целиком. Попытка заменить весь обмен разом вместо поэтапного внедрения.
- Нет сверки. Без периодической полной сверки расхождения накапливаются незаметно.
Чек-лист внедрения
- События описаны. Факты предметной области с данными и стабильными идентификаторами.
- Очередь работает. События публикуются в очередь и разбираются воркерами.
- Обработчики идемпотентны. Журнал обработанных событий, атомарное применение, факты вместо дельт.
- Двусторонний поток. Сайт → 1С и 1С → сайт согласованы по формату и идентификаторам.
- Ошибки обрабатываются. Экспоненциальные повторы и очередь dead letter настроены.
- Мониторинг включён. Глубина очередей, задержка, ошибки и расхождения под наблюдением.
- Гибрид с обменом. Событийный слой работает поверх CommerceML, есть периодическая сверка.
Вывод
Event-driven архитектура снимает главный конфликт пакетного обмена — между свежестью данных и нагрузкой. Реагируя на конкретные изменения, а не перекладывая весь массив по таймеру, событийная синхронизация держит остатки и статусы заказов актуальными и распределяет нагрузку ровно. Цена этого — инженерная дисциплина: очереди, идемпотентность, надёжная доставка и мониторинг.
Не переписывайте интеграцию разом. Начните с одного болезненного потока поверх существующего обмена CommerceML, отладьте на нём очередь и идемпотентность, измерьте эффект — и расширяйте модель на цены и статусы. Гибрид пакетного обмена и событий даёт и согласованность, и актуальность, а поэтапный переход снижает риск до приемлемого.
