В начале был РИБ, и РИБ был медленный...
Как и большинство феодальных дистрибьюторских бизнесов, все начиналось с одной-единственной базы УТ.
Далее, как говорится, шли годы, компания росла, добавлялись новые филиалы - количество которых приблизилось к 30-ти, а потом и превысило это количество, к тому же разрастались процессы и запросы к актуальности данных. Продолжительность полного цикла обмена между 30 базами РИБ с большим количеством документов не отвечала требованиям бизнеса и многие данные должны были появляться «здесь и сейчас».
Центральная база не успевала отработать весь объем, блокировала работу и, как следствие, была выделена только для обмена, т.к работа в ней пользователей была невозможна. Сделали так, что центральная база (ЦБ) превратилась в периферийную, а обменная база (ОБ) стала главным узлом. Так как в качестве транспорта данных использовался FTP и в схему передачи данных добавилось ещё одно звено ОБ, то при этом значительно увеличилось время для передачи данных от ЦБ до филиала: до 6 часов. А такие вещи как скидки, например, или установку цен номенклатуры, очень хотелось, да собственно прямо скажем - требовалось - передавать побыстрее. Приоритезация решалась последовательностью обмена с ОБ (сначала ЦБ, потом остальные).
Любые срочные динамические изменения приводили к полному циклу обмена. Без фундаментальных изменений логики информационных потоков возможность получить актуальную информацию или впоследствии сопоставить дубли не представлялось возможным.
В качестве экспериментов были испробованы различные методы оптимизации скорости обмена. Были включены урезанные планы обмена для миграции выборочных типов объектов, однако этот подход не оправдал себя из-за низкой пропускной способности центральной базы. Регламенты не всегда можно было выстроить последовательно и без накладок. Низкая масштабируемость решения (каждый раз создавать отдельный план) наводила на мысли о неверном пути.
Дополнительно были изучены возможности работы по правилам обмена, но поддержка правил тоже требовала ресурсов, причем полученная производительность не превышала скорости типового обмена. Работа с правилами порождала значительное число новых вопросов, и которые в итоге не позволили выбрать данное решение.
Эпоха веб сервисов
Однажды было принято решение создать единую базу с хранением нужной НСИ, которая раздавала бы данные по мере необходимости, не дожидаясь полного цикла обмена. Более подробно о проблеме и решении описано тут (//infostart.ru/public/944961/).
Думаем... думаем... и придумываем
Технология веб-сервисов зарекомендовала себя с хорошей стороны и возникла шальная мысль:
«А не перевести ли весь обмен на веб-сервисы? Базы все однотипные (модное слово “не гетерогенные”), будет работать сериализация, напилим базу-диспетчер обмена и будет нам счастье».
Что получаем в итоге: обмен будет пообъектный, регистрация хранится в плане обмена, при выгрузке объект переносим в буфер до подтверждения получения данных в приемнике.
На первый взгляд звучит заманчиво, но надо решить некоторые вопросы, а именно:
1. Изменения конфигурации
Как их будем передавать? Не очень хочется городить пакетные обновления со своим управлением. Ну ок, отдадим эту задачу на типовой РИБ, пусть меняет штатными средствами по расписанию.
Передавать конфигурацию через веб-сервис это грех, тут вопросов нет, но как отправить данные, которые хранят в себе модифицированные реквизиты, не измененные в приёмнике? Придется пакет объекта ставить в очередь, пока приемник не получит изменения, данные загрузить не получится, сериализация будет невозможна. Однако, те объекты, которых не затронуло изменение могут беспрепятственно обмениваться.
2. Приоритезация изменений
В базе-диспетчере (БДО) есть приоритет (число) для каждого филиала. Если пришел объект в БДО с более высоким приоритетом, то он перезаписывается в раздаче для получателей. Перед загрузкой в более приоритетную базу проверяем наличие изменений в плане объекта и принимаем решение по приоритету.
3. Маршрутизация
Маршрутизация в РИБ остается такой же, при регистрации изменений определяется список получателей. В дальнейшем можно сделать маршрутизацию в БДО, но для текущих нужд все устраивает.
4. Отказоустойчивость
Важно добиться аналогичного уровня надежности доставки объектов, как у РИБ. Все объекты пишем в транзакции, при неудаче откатываемся и считаем количество попыток.
Сеем
Инициатором всех процессов является БДО. В ней для каждой ПБ есть регламентное задание для обмена, выполняющее 2 процедуры: ПрочитатьИзменения(..) и ЗаписатьИзменения(..).
Чтение данных (концептуальный вариант)
- Из плана обмена “ВебОбмен” выполняется считывание 1 зарегистрированного там объекта и его сериализация в XML-текст.
- После того, как объект считан и XML-текст помещён в массив - объект снимается с регистрации в плане обмена “ВебОбмен” и записывается в регистр сведений “Прочитанные объекты”.
- Чтение происходит до тех пор, пока размер формируемого пакета, не превышает установленного значения (в нашем случае 1,5 мб), либо пока не кончатся элементы в регистре.
- Сформированный массив XML-текстов в сжимаемом типе данных “ХранилищеЗначения” передается в обменную базу.
- Каждый полученный XML-текст записывается в регистр сведений “ОчередьПакетов” в обменной базе при условии, что уже имеющаяся запись с таким же объектом не от базы с повышенным приоритетом. После записи каждого XML-текста в базу-отправитель по web-сервису отправляется команда на удаление записи в регистре сведений «Прочитанные объекты». Если по какой-либо причине не удаётся выполнить запись XML-текста в регистр сведений “ОчередьПакетов”, то удаления объекта из регистра не происходит. В следующий раз объект будет повторно выгружен в п.5. (перед обменом данные регистра загружаем в план обмена).
- Операции 1-5 выполняются до тех пор, пока не закончатся объекты в плане обмена.
Запись изменений в базу-получатель
- В обменной базе сразу после получения данных формируется выборка XML-текстов, которые нужно передать в базу-получатель (эта же база только что была базой-отправителем).
- Запись одного XML-текста регистра сведений “ОчередьПакетов” блокируется в обменной базе.
- XML-текст передаётся по web-сервису в базу-получатель, десериализуется в объект 1С.
- Объект 1С записывается в базе-получателе в транзакции. В случае документа, также происходит запись проводок.
- Запись из регистра сведений “ОчередьПакетов” удаляется.
- Снимается блокировка с записи XML-текста регистра сведений “ОчередьПакетов” в обменной базе.
- Операции 2-8 выполняются по циклу до тех пор, пока не закончится выборка.
Концептуальная схема обмена
Приведенная ниже схема не содержит в себе процессов по контролю транзакционной целостности, механизмов возобновления работы после сбоя и смены подразделений у документов. Целью схемы является демонстрация концепта потоков данных. Полный контур процессов выглядит достаточно громоздко, поэтому здесь не приведен. На схеме продемонстрирован процесс относительно обмена с одной базой, из которой сначала читаем данные, а потом отправляем.
Пожинаем
- Ускорение обменов
- Обменная база значительно повышает скорость передачи данных между ЦБ и подчиненными базами.
- Разгружает центральную базу. Обменной базе достаточно обменяться с обменной базой только один раз, которая далее обменивается с периферийными базами.
- Значительно реже случаются конфликты блокировок. Сервер обмена не блокирует центральную базу целиком при выполнении обмена. Блокировка данных (начало транзакции - конец транзакции) включается только на момент передачи одного экземпляра объекта. Это существенно разгружает базу данных, если управляемые блокировки таблиц в конфигурации ещё не включены.
- Отказоустойчивость
- Восстановление передачи данных с точки прерывания. При повторном запуске передача продолжится с того же места. Можно самостоятельно остановить выполнение передачи данных.
- Мониторинг и статистика обменов
- Видим очередь объектов в режиме он-лайн, можем анализировать и конфигурировать объемы данных и расписание.
- Сбор статистики: понимаем, что “ходит” в обмене, делаем выводы для оптимизации.
- Информирование пользователя о статусе обмена объекта.
- Обменная база в инфраструктуре позволяет использовать полезные сервисные функции:
- Исполнение произвольного кода на периферии.
- Хранение тяжелых регистров сведений (нетиповое версионирование, например).
- Централизованное выполнение регламентов (последовательности и т.д).
Не баги, а фичи….
В подходе, при котором обмен идет без загрузки изменений, есть возможность нарваться на логическую проблему. В случае, если ожидаемое поведение модифицированной конфигурации зависит от данных, и на эти данные в не модифицированной конфигурации настроена иная логика, то изменение данных без изменения конфигурации приведет к логической ошибке. Однако, при соблюдении некоторых техник в разработке (использование версий, например) данный тип проблем можно избежать. Эта категория вопросов будет всегда при разделяемом обмене (отдельно данные, отдельно конфигурации).
Время собирать камни помидоры обратную связь
К тому моменту, когда система стала работать слаженно и бесперебойно, мы прошли через огромное количество споров по поводу технологии обмена. На Инфостарте есть куча отличных примеров от вдохновляющих нас ребят по работе с RabbitMQ и прочих интеграционных шин. На выбор технологии на платформе 1С повлияли экзистенциально-языческие сомнения в стабильность связки 1С и решений из “внешнего мира”. Хотелось обойтись без привлечения сторонних средств с целью избежания bus-фактора в команде. Обращения в техподдержку после ввода системы снизились в разы. Поддержка решения не требует специфических знаний сторонних технологий.
В итоге мы получили достаточно стабильное решение вопросов обмена при наличии устойчивой связи. Наличие установленного на филиалах apache-сервера не являлось для нас проблемой, т.к они уже были подняты для других задач. Мы надеемся, что данный подход возможно поможет оптимизировать обмена на других предприятиях. В любом случае любая обратная связь по вышеописанной концепции будет нам ценна и полезна.
