Распределённая база 1С на сотни магазинов без гигабайтных файлов: пообъектный обмен на HTTP-сервисах

Кто хоть раз поддерживал распределённую базу 1С на несколько десятков магазинов, тот, думаю, хорошо знает это ощущение: обмен вроде бы настроен, всё по методичке, но каждое утро начинается с выяснения, какие магазины опять не загрузились, почему файл не доехал и что делать с точкой, где обмен стоит уже третий день. А стоит чуть-чуть доработать конфигурацию — и начинается отдельная история с её доставкой по всем узлам.

Мы прошли через всё это на собственном опыте, когда сеть, с которой мы работали, выросла до нескольких сотен магазинов. В итоге обмен пришлось перестроить, и получилось решение, которое мы  называем «живым» обменом.

С чего всё началось?

Концепция родилась при работе с клиентом — крупной сетью алкогольно-продуктовых магазинов. Мы внедрили там 1С:Розницу, и при обмене данными на 200, а потом на 300 и 400 магазинов проблемы возникли практически сразу.

Типовой обмен 1С, как известно, формирует один файл выгрузки. Причём если хоть немного поменять конфигурацию, файл включает в себя и саму конфигурацию, то есть становится размером больше гигабайта. Передать такой файл в магазин по медленному каналу где-нибудь в глубинке становится предельно сложно, а при любом сбое он не загружается целиком — и это вполне может ограничивать работу магазина.

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

И отдельная боль — доработки. Пока новая конфигурация не установлена во все магазины, новые объекты, например номенклатура с новым реквизитом, не загружаются. А это значит, что торговля новыми товарами фактически встаёт. Установка же конфигурации во все магазины занимала у людей, которые обслуживают систему, крайне много времени.

А механизма расширений конфигурации тогда еще не было...

Идея: передавать не файл, а объекты

В какой-то момент возникла простая, в общем-то, мысль: а что если передавать изменения не одним большим файлом, а по объектам? Для этого мы сделали отдельный HTTP-сервис, который выдаёт перечень изменённых объектов в базе, и всё это работало как дополнение стандартного обмена Розницы в магазинах.

Ключевую роль при этом играет отдельная управляющая система: базы не обмениваются друг с другом напрямую, это она ходит в каждую из них. Цикл выглядит примерно так:

•     Управляющая система спрашивает у центральной базы, какие объекты должны уйти в конкретный магазин (или, наоборот, из магазина в центр).
•     Забирает сами объекты в несколько потоков, причём не обязательно по одному: пакетами по 5, 10 или 100 штук — в зависимости от их размера.
•     Передаёт пакет в базу-получатель, где объекты разбираются и загружаются.
•     Получатель формирует квитанцию, она идёт через управляющую систему обратно в базу-отправитель, и только тогда с объектов снимается регистрация.

Формат пакетов — JSON: конфигурации в узлах одинаковые, так что ничего сложнее не требуется. Загружаются объекты в режиме обмена данными, без допобработки и проведения, ведь это фактически тот же самый объект — в типовом обмене Розницы, напомню, передаются в том числе движения регистров и проведение.

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

Надстройка над РИБ, а не замена

Важный момент: мы не выбрасываем стандартную распределённую базу. Живой обмен — это надстройка, которую можно запустить в виде расширения над стандартным обменом РИБ. Штатный механизм при этом остаётся в базе, и при желании им можно воспользоваться, выгрузив изменения файлом по-старому. Просто данные уходят гораздо оперативнее, а конфигурация выгружается по-другому.

Сохраняется и всё остальное, ради чего вообще выбирают РИБ: фильтрация объектов и сама суть распределённой базы данных. Единственная разница в том, что у получателя можно снять признак РИБ, и всё будет работать, даже несколько проще, потому что при каждом обновлении конфигурации её не нужно снимать и убирать.

Почему не репликация средствами СУБД? Честно говоря, она предельно сложна для понимания, и устроить на ней фильтрацию тоже тяжело. С появлением Ai это, наверное, стало проще, но мне до сих пор сложно это представить. А РИБ — механизм понятный, и строить поверх него оказалось гораздо спокойнее.

Ещё несколько правил, которые сложились по ходу работы:

•     Только через центр, как и в стандартном обмене. Обмен напрямую между магазинами невозможен, но через центральную базу данные летают очень быстро.
•     Коллизии. Если объект изменили одновременно в центре и в магазине, приоритет у версии центральной базы.
•     Обмен по части типов односторонний. Это наработано опытом, после нескольких остановок всей сети из-за ошибок действий пользователя или программиста в одном магазине.
•     Ошибки. Не пришла квитанция — объект в следующий раз выгрузится снова, а в управляющей системе в логах видно, что именно пошло не так. Если в пакете десять объектов и один не загрузился - остальные 9 загрузятся и это будет отражено в квитанции, повторно они не будут выгружаться
•     Битые ссылки. Документ может прийти раньше справочника, и тогда ссылка загрузится как битая. Я, признаться, ожидал, что это станет огромной проблемой, но практика показала, что нет, на реальную работу это влияет крайне редко. А если пользователи в магазине всё-таки видят такое, это сигнал для IT-отдела: значит, не дописали правила или что-то сломалось.

Когда в узлах разные версии конфигурации

Пообъектная передача решила проблему с оперативными данными, но доставка изменений конфигурации по-прежнему шла долго. А Розница у нас активно дорабатывалась, и нужно было как-то передавать объекты в магазины, где новой конфигурации ещё нет, — пусть даже не в полном виде.

Так у узлов появились версии конфигурации: центральная база, допустим, имеет версию 150, а магазин — 149. Объект JSON по дороге может дорабатываться скриптами в управляющей системе, которые мы называем правилами конвертации. Скажем, в центральной базе в номенклатуру добавили реквизит. Тогда для перехода из 150 в 149 применяется правило, которое просто удаляет из JSON строчку с этим реквизитом, а для магазина, застрявшего на версии 148, может применяться правило, удаляющее уже два реквизита.

Проблему того, что в части магазинов реквизит оказывается незаполнен, мы решаем позже: когда конфигурация установлена во все магазины, объекты, у которых этот реквизит заполнен, вручную регистрируются к выгрузке и разлетаются по магазинам уже в полном виде. А при установке конфигурации версия узла обновляется автоматически, и правило конвертации для него больше не применяется.

Сами правила — это не язык программирования, а четыре-пять функций: удалить реквизит, добавить реквизит, переименовать, поменять тип, подставить значение по умолчанию, обработать новую табличную часть. Пишет их тот, кто дорабатывает конфигурацию, — он и так знает, какой реквизит добавил, — и одно правило занимает, условно, секунд двадцать. На каждое направление правило своё: «150 → 148» и «148 → 150» — разные правила. Когда узлы со старыми версиями заканчиваются, правила чистят, чтобы их не накопилось слишком много.

На практике одновременно существовало до пяти версий, и это могло длиться неделями, если канал такой, что конфигурация никак не докачивается. Оперативные данные при этом идут как обычно. Версию узла управляющая система узнаёт постоянно, функцией ping: она опрашивает удалённый узел, а версия хранится в наименовании расширения.

Конфигурация — отдельно и ночью

Магазины теперь могли работать, но сама установка конфигурации по-прежнему отнимала уйму времени. И тут мы поняли, что у управляющей системы уже есть всё необходимое: список магазинов и их адреса во внутренней сети (VPN-сеть, естественно, была уже на всех магазинах). А значит, она может с помощью скриптов подключаться и к базам 1С магазинов, и к самим компьютерам.

Одним из первых появился скрипт копирования конфигурации: он по медленным каналам, с докачкой, закачивает конфигурацию в магазин и помечает, что у узла есть её копия. Закачивали мы полный CF, а не файл обновления CFU, потому что подготовить CFU сложновато. Самый медленный канал, по которому работала докачка, был 64 кбит/с по ADSL, и вот с такими каналами проблемы, конечно, были.

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

Инструмент для системных администраторов

Дальше скриптов становилось всё больше, и они решали уже самые разные задачи: обслуживание баз данных, проблемы, которые возникают в файловых базах, обслуживание самих компьютеров, сбор версий ПО. Из того, что есть точно: сбор конфигурации оборудования вместе с проверкой места на диске, тест жёсткого диска, обновление платформы 1С, которое само скачивает и ставит новую версию.

Пишут скрипты системные администраторы, и список открыт — можно добавлять свои. Где выполняется скрипт, выбирают тоже они: в 1С на стороне управляющей системы, в 1С на стороне магазина или на стороне управляющей системы с удалённым подключением к компьютеру. Изначально, насколько я помню, для подключения к компьютерам использовался PowerShell, но вариант может быть любой. Журнал выполнения скриптов мы специально не делали, результат пока виден только косвенно; сделать его недолго, просто до этого не дошли руки.

Почему мы называем его «живым»

Думаю, теперь понятно, почему я называю этот обмен живым — в отличие от стандартного обмена через файлы, которые содержат в себе все изменения и саму конфигурацию.

Во-первых, мы всегда видим состояние обменов по каждому магазину. Из управляющей системы можно формировать любые отчёты, а щёлкнув на магазин, увидеть очередь объектов, которые в него улетают. Ping при этом собирает доступность узла, время последнего обмена, версию конфигурации и версию расширения.

Во-вторых, обмен идёт в онлайне: изменения доходят до узлов за минуты. В той самой сети с медленными каналами вместо ожидания минимум в сутки, а максимум в неделю-две мы получили передачу объектов в течение максимум часа, и упирается эта скорость, по большому счёту, только в мощность сервера, на котором стоит управляющая система.

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

Что нужно для работы?

•     VPN-сеть между узлами крайне желательна, в любом виде. Без неё, даже на белых IP-адресах, всё становится гораздо менее безопасным.
•     Бесплатный веб-сервер Apache в каждом магазине. Обычно их два: один для обмена, второй для работы тонких клиентов в магазине.
•     Сервер 1С с серверной лицензией под управляющую систему. На файловой базе она не заработает, но нагрузка на неё минимальна, всё хорошо распараллелено, так что её вполне можно поставить на один из уже работающих серверов 1С. Отдельный сервер имеет смысл, только если серверов десятки. Стоит она обычно недалеко от центральной базы.
•     Дополнительные лицензии в магазины не нужны: обмен идёт через веб-сервисы.
•     Расширение обмена в базах. Для старых конфигураций, где расширений нет, обновляется платформа и ставится расширение.
•     Базы в магазинах — любые. У первого клиента на самых больших магазинах, их около пятнадцати, клиент-серверные базы, на остальных — файловые.

Конфигурация при этом может быть любой, от самых старых до самых новых; главное, чтобы все базы были одного типа и в целом представляли собой одну распределённую базу. Авторизация у первого клиента сделана по пользователю 1С, но её можно сделать и по токену, и как угодно ещё.

Где это работает сейчас?

На этом обмене сейчас работают та самая крупная сеть алкогольно-продуктовых магазинов — около 400 магазинов, сеть оптовика с шестью филиалами и небольшая сеть из десяти магазинов, тоже на Рознице. Первое внедрение, честно говоря, не столько внедрялось, сколько рождалось, и заняло больше года. Развернуть уже готовое решение для десяти магазинов — это, условно, неделя-две, для сотни — около месяца.

Из этого же обмена, кстати, потом вырос и наш архив баз 1С, о котором я рассказывал в отдельной статье: архив, по сути, оказался частным случаем того же самого обмена.

Честно о слабых местах

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

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

Ну и главное: Живой обмен нужен не всем. Если между филиалами есть постоянная связь хотя бы 10–20 Мбит/с, строить обмен уже теряет смысл, и лучше работать в одной базе 1С. А вот если такой связи нет, он актуален с любого размера — даже для пяти баз в распределённой базе. Думаю, по мере того как сети становятся быстрее и надёжнее, такой обмен будет постепенно отмирать, но останутся сценарии, где он будет нужен всегда.

Один из таких сценариев — репликация, а вернее живая пообъектная копия с двухсторонним обменом. С помощью того же обмена можно держать на соседнем сервере копию большой базы со всеми данными и выполнять в ней сложные и объёмные операции: тяжёлые отчёты или, например, пересчёт последовательности документов. Нагрузка при этом снимается с основной базы, что для больших баз бывает очень кстати.

Вместо заключения

Если коротко, главное, что нам дал пообъектный обмен, — это ощущение контроля. Файл выгрузки был чёрным ящиком: он то доезжал, то нет, и узнать, что происходит, можно было только постфактум. Теперь мы видим очередь по каждому магазину, знаем, какая версия где стоит, и можем дорабатывать конфигурацию, не останавливая торговлю.

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

Буду рад вопросам и критике в комментариях. Особенно интересно, как вы живёте с РИБ на десятках узлов и как доставляете в них доработки конфигурации.