1С:Шина – успешный опыт эксплуатации

Доклад называется «1С:Шина – успешный опыт эксплуатации». Это спойлер. Опыт действительно есть, он действительно успешный, мы действительно внедрили 1С:Шина в промышленную эксплуатацию.

Но почему мы решили внедрить именно 1С:Шина? Как мы решили, что этот продукт нам подходит? И какие задачи хотели с ее помощью решить? Чтобы ответить на эти вопросы, расскажу обо всем по порядку.

Изначально у нас в компании было:

• Много сервисов, написанных на разных языках: PHP, Python, .NET

• Эти сервисы общались между собой в основном через брокер очередей RabbitMQ.

• Процесс интеграции контролировался через единую систему мониторинга, которую наши прекрасные DevOps-инженеры реализовали на Prometheus плюс визуализация на Grafana.

• А логи этой интеграции хранились в единой системе хранения логов на базе ClickHouse – СУБД от Яндекс.

За последний год в нашей компании появилось много новых сервисов, основанных на 1С – как на типовых конфигурациях, так и на полностью самописных. Причем эти сервисы стали применяться в операционном контуре, и в случае их недоступности или деградации по производительности бизнесу приходилось страдать. Нам необходимо было найти решение для более глобальной интеграции продуктов 1С в весь IT-контур. А именно:

• Обеспечить гарантированную доставку сообщений – чтобы сообщения, отправленные сервису 1С, всегда доходили до него, а ответы от сервиса 1С всегда достигали получателя.

• Реализовать возможность асинхронного обмена сообщений – 1С без Шины не умеет асинхронно взаимодействовать.

• Встроить 1С в единую систему мониторинга.

• И интегрировать логи 1С в единую систему логирования.

Мы рассматривали множество различных вариантов решения, вплоть до «а давайте напишем свою шину». Но в начале 2021 года увидели новый продукт – 1С:Шина. Изучили документацию и заинтересовались – судя по описанию, 1С:Шина должна была решить все поставленные перед нами задачи.

Мы приобрели этот продукт, получили дистрибутив и развернули его в нашей инфраструктуре. Поскольку 1С:Шину можно установить как на операционной системе Windows, так и на Linux:

• Dev-контур мы реализовали на операционной системе Windows Server 2019 – поставили туда 1С:Шину со средой разработки, а в качестве СУБД использовали файловую базу 1С.

• А Prod развернули на виртуальной машинке Ubuntu – поставили 1С:Шину без среды разработки, а в качестве СУБД использовали PostgreSQL 13.6.

Схема гарантированной доставки 1С:Шина

Расскажу о возможности гарантированной доставки с помощью 1С:Шина немного подробнее – каким образом это решение гарантирует доставку.

На слайде – картинка из официальной документации 1С:Шины:

• здесь отправитель и получатель – это конфигурации 1С;

• интеграционная шина – это отдельное решение 1С:Шина, которое мы установили на Windows, в проде на Linux;

• у отправителя есть свое хранилище – это СУБД;

• у интеграционной шины есть свое хранилище – тоже СУБД, есть различные варианты – может быть PostgreSQL, MS SQL, файловая;

• у получателя есть свое хранилище;

• и между ними есть каналы интеграции.

Теперь давайте более детально посмотрим, что скрывается за этой картинкой под капотом.

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

• У нас в конфигурации-отправителе настроен исходящий канал «JournalLogs_ИзКонфигурацииВШину».

• При создании такого канала в СУБД создается табличка _integchanneloutqueue52, где будут храниться сами сообщения и информация об этих сообщениях: ID-шники, тело, заголовки. Когда разработчик пишет на языке 1С:
  СервисыИнтеграции[Сервис][Канал].ОтправитьСообщение(СообщениеСервиса);
  сообщение в первую очередь попадает в эту таблицу, а далее по каналу передается в интеграционную шину.

• Шина фиксирует это сообщение у себя в хранилище, производит с ним какой-либо процессинг, если нужно, определяет, кто будет получать это сообщение, и передает его в канал получателя.

• А далее это сообщение принимает уже конфигурация-получатель, у которой есть входящий канал. При создании этого входящего канала в СУБД базы-получателя создается табличка _integchannelinqueue56 – входящая очередь. Она имеет точно такую же структуру, только добавляется новое бинарное поле _processed, которое отвечает за то, обработано сообщение или нет.

А теперь давайте посмотрим, что будет, если вдруг что-то где-то поломается.

Например, мы потушили Шину, выключили ее. При отправке на стороне отправителя никаких ошибок не будет – будет говориться о том, что сообщение отправлено, но все сообщения будут копиться в табличке _integchanneloutqueue52.

Как только мы включаем Шину, она начинает слушать канал, и все сообщения переедут в хранилище интеграционной шины.

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

Как только база получателя будет доступна, все сообщения переедут уже в табличку _integchannelinqueue56.

Сигнатура процедуры для обработки входящего сообщения на стороне 1С содержит два параметра – это сообщение и классическая служебная переменная «Отказ».

• Если никаких исключений при обработке сообщения не возникло – мы доехали до конца процедуры и «Отказ» не стал Истина, сообщение пометится в колонке _processed как Истина, и будет считаться доставленным.

• Если же произошла какая-то исключительная ситуация, _processed будет «Ложь», и через некоторое время произойдет повторная попытка доставки сообщения – это время настраивается уже в конфигурационном файле 1С:Шины.

Практика использования. Сбор метрик

Расскажу о кейсах, которые мы реализовали с помощью 1С:Шины.

У нас порядка 17 различных конфигураций – на слайде они условно называются база №1, база №2, база №3. Из всех этих баз нам нужно собирать метрики в единую систему мониторинга на базе Prometheus.

Для каждой базы наши разработчики и Product Owner-ы определили, какие метрики и health check’и должны быть получены, и регламентным заданием через Шину эти данные отправляются в отдельную базу «Агрегатор метрик».

Сам «Агрегатор метрик» опубликован на веб-сервере Apache, и туда настроен экспортер Prometheus – он забирает эти метрики себе, а Grafana все это визуализирует.

На слайде показаны графики с метриками для специальной конфигурации 1С, которая у нас слушает вебхуки Jira и производит процессинг по задачам. На графике выводится количество сообщений в планах обмена – можно увидеть, сколько за последнее время было событий и что вообще происходит. Получилось очень полезно. Кейс успешный.

Контроль доступности баз 1С

После этого мы пошли дальше и стали с помощью 1С:Шины измерять доступность баз.

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

Поэтому мы воспользовались возможностью веерной отправки с помощью 1С:Шина. Дело в том, что при отправке мы можем указать код получателя, и тогда сообщение поедет конкретному получателю. А можно не указывать в свойстве «КодПолучателя» ничего, и тогда сообщение размножится для всех слушателей этого канала.

Мы в базу «Агрегатор метрик» добавили регламентное задание, которое периодически отправляет пинг в соответствующий канал 1С:Шины без указания получателя. На этот канал подписаны все наши решения. Они получают наш пинг, и отвечают, что все хорошо. Prometheus это видит, и эту метрику фиксирует.

На слайде я специально потушил сервис B3 – он вывел ALARM, и в Telegram пришло сообщение о том, что сервис недоступен.

Все получилось – мы убедились, что веерная отправка работает шикарно.

Выгрузка журнала регистрации

Дальше мы решили нагрузить 1С:Шину и реализовали через нее выгрузку журнала регистрации в единую систему хранения логов ClickHouse.

Для выгрузки журнала регистрации мы написали свою небольшую подсистему а-ля БСП – назвали ее «Оснастка» и установили на всех конфигурациях.

Эта подсистема читает инкременты журнала регистрации, парсит его в JSON и отправляет это сообщение в Шину. Отправили и после отправки очищаем – тем самым у нас журнал регистрации не пухнет.

Все сообщения 1С:Шина отправляет в специальную базу «Сбор логов», которая записывает их себе в регистр сведений, преобразует в формат для загрузки в ClickHouse, укладывает в ClickHouse и очищает кэш (удаляет записи из регистра сведений).

По данным ClickHouse мы в Grafana имеем красивый дашборд, который показывает абсолютно всю агрегационную информацию по журналу регистрации:

• сколько у нас было соединений и фоновых заданий;

• сколько у нас было транзакций – какие из них были зафиксированы, а какие откатились;

• сколько раз поменялся тот или иной объект метаданных – документ, регистр сведений и прочее;

• сколько у нас было авторизаций успешных, а сколько – неуспешных и т.д.

Через две минуты после того как событие произошло, оно попадает в ClickHouse, и мы его уже видим в Grafana. Очень удобно.

Например, мы выпустили новый релиз, столкнулись с деградацией производительности, смотрим на график и видим, что количество перезаписей регистра сведений выросло в 10 раз. Сразу нашли, что запись происходила в цикле. Очень визуально.

Производительность 1С:Шина

Хотя обычно журнал регистрации – это неподъемная штука, мы убедились, что через 1С:Шину можно прокачать значительный объем данных:

• У нас одновременно собираются данные журнала регистрации от 17 достаточно нагруженных баз.

• Все эти 17 баз генерируют порядка 10,5 миллиардов записей в месяц, что соответствует чуть более 4000 событий в секунду в среднем.

• На уровне базы 1С «Сбор логов» у нас в пике заходит больше 200 пакетов в секунду, в среднем где-то 150.

• В этих 150 пакетах – 30 тысяч событий журнала регистрации в секунду.

• Если говорить об объемах данных, то это порядка 16 мегабайт в секунду.

И это все в один поток. А в 1С:Шине можно реализовать несколько потоков загрузки – в документации это описано. Мы не стали делать многопоточность, потому что у нас и так шестикратный запас по прочности. В принципе, производительность 1С:Шины меня приятно удивила. Я действительно считаю, что этот опыт успешный.

Преимущества при внедрении 1С:Шина

Давайте поговорим, какие экономические преимущества дает внедрение 1С:Шина.

• Во-первых, нам не пришлось разрабатывать что-то свое или искать какие-то внешние инструменты.

• По 1С:Шине мы можем получить поддержку у вендора, и мы ее получали достаточно оперативно. У нас было несколько вопросов, представители фирмы «1С» оперативно проконсультировали нас по продукту.

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

• Время доступности сервисов тоже увеличилось за счет асинхронной реализации. Мы можем спокойно обновлять одну базу, при этом на стороне тех, кто запрашивает данные, ошибок не возникает – как только база обновится и станет доступна, все ответы придут.

Преимущества по инфраструктуре:

• Для обмена данными между базами 1С через 1С:Шина нет необходимости публиковать базы 1С на веб-сервере или реализовывать HTTP/веб-сервисы, которые будут взаимодействовать с внешними приложениями.

• Это позволяет нам переносить базу на другой сервер, не задумываясь о перепрописывании путей.

• При обновлении платформы нет зависимости от минорных версий – нет необходимости ставить на веб-сервере dll той же версии, что требует платформа 1С.

• Сервисы интеграции на конкретной базе можно легко включить-выключить. Это делается в режиме 1С:Предприятия через встроенную обработку «Управление сервисами интеграции» – там можно включить или выключить активность того или иного канала.

Преимущества при разработке решений:

• Больше нет риска «потерять» сообщение, это дает нам возможность не придумывать на каждое решение какие-то внутренние очереди. Не нужно сохранять сообщения куда-нибудь в кэш, в другую базу, сообщать об этом пользователю». Такой задачи нет. Мы все спокойно отправили, а 1С:Шина уже разрулит.

• Возможность верной отправки сразу нескольким получателям – о ней рассказал ранее.

• 1С:Шина – это не просто брокер очередей, не аналог RabbitMQ. Это действительно ESB-решение, на котором можно процессить – видоизменять сообщения и получателей. Если сообщение было адресовано одному получателю, но мы по телу поняли, что эта информация необходима и другим получателям – можно это все сделать на уровне Шины, а не на уровне отправителя.

На этом наш успешный опыт эксплуатации 1С:Шины на текущий момент закончился, но не закончились задачи для Шины – хочу поделиться нашими идеями о том, что еще можно сделать с помощью 1С:Шина.

Новые задачи для 1С:Шина

1С:Шину можно использовать как своеобразный уловитель Web-Hook и CallBack.

В нашем интеграционном контуре есть много разных систем, которые умеют отправлять сообщения через REST-интерфейс по любому адресу – куда вы им скажете. Сложность в том, что, как правило, отправителю неважно, получили вы сообщение или нет. Та же Jira вебхучит куда угодно, но если вдруг тот сервис недоступен, повторного вебхука не будет. А база 1С, как мы знаем, периодически обновляется и не всегда доступна.

На 1С:Шине можно реализовать HTTP-сервис, который будет слушать и обрабатывать любой GET-запрос. На уровне внешнего приложения мы настраиваем, чтобы оно отправляло свои вебхуки по REST-интерфейсу в 1С:Шину. Оно отправляет данные в 1С:Шину, а она уже в зависимости от того, кто является отправителем, определяет, какая из баз будет получателем.

Второй вариант использования 1С:Шины – это процессинг.

Например, у нас есть 1С:Документооборот, в котором появляется карточка нового контрагента, и связанные с ним файлы – сканы договора, сертификатов и прочее. Все это можно объединить в один объект и отправить в Шину, а уже на уровне Шины разложить, что:

• карточка с установленными лимитами должна попасть в 1С:Управление Холдингом;

• карточка с реквизитами контрагента – в 1С:Бухгалтерию предприятия;

• а все файлы должны отправиться в хранилище S3.

Думаю, у многих возник вопрос: зачем нам эти промежуточные базы 1С – «Агрегатор метрик», «Сборщик логов»? Мы их сделали, потому что так было быстрее и удобнее. Но по большому счету 1С:Шину можно настроить так, что она сама будет укладывать данные в ClickHouse, и сама будет сообщать экспортеру Prometheus о тех или иных метриках.

В планах у нас отказаться от этих прослоек – баз 1С «Агрегатор метрик» и «Сборщик логов» – и реализовать это все на уровне Шины, тем самым еще больше упростить процесс.

Заключение

Я рассказал, какие плюсы от внедрения 1С:Шина получила компания. А какие плюсы получил я сам?

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

Вопросы и ответы

Задача мониторинга сервисов 1С и агрегации свода данных в базах 1С прекрасно решается и без использования 1С:Шины. И сервисы 1С можно интегрировать с Prometheus и Grafana напрямую. Но вы зачем-то используете 1С:Шину. Объясните подробнее, почему?

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

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

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

За год ее работы она ни разу не упала. Было такое, что канал переставал слушать, но это решалось просто перезапуском активности конкретного слушателя на конкретной базе.

И сейчас мы уже настраиваем, чтобы через 1С:Шину передавались бизнесовые данные. Пока это будет обмен между базами 1С. Но дальше мы планируем выводить это за инфраструктуру 1С на весь IT-ландшафт.

1С:Шина увязана с другими технологиями 1С. В каком формате вы передаете данные? Вы сами создаете структуру пакетов, которые у вас летят в 1С:Шину, или используете формат Enterprise Data?

По Шине передаются в основном либо пакеты двоичных данных, либо текст. Что вы в текст положите – JSON или XML – это уже не важно.

Вопрос в том, как вы эти пакеты делаете? Сами?

Сами. Можно сериализовать любой объект в xml-строку и отправить по Шине.

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

Если вы указали конкретного получателя, сообщение попадает одно в канал и выслушивается конкретным получателем. Пока этот получатель не подключится к Шине и не начнет слушать по этому каналу, никто другой это сообщение не получит.

Но если вы не указали получателя, это сообщение полностью задублируется для каждого, кто этот канал слушает. Пока каждый получатель не вычитает, это сообщение будет ждать его в очереди.

А кто вообще может слушать канал, какая информационная система – это указывается в панели администрирования Шины.

Канал входящий в Шину или исходящий?

Как входящий, так и исходящий. Кто может пушить в канал, и кто может слушать канал.

Один канал для получателя может быть забит сообщениями для других получателей?

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

Какой максимальный размер пакета данных можно передавать через канал?

Я думаю, что это можно посмотреть в конфигурационном файле. 30-40 мегабайт мы спокойно передавали. Передавать 1,5 Тб или 1,5 Гб еще не пробовали. Эмпирически не могу сказать, насколько большим может быть пакет. Если учесть, что у 1С:Шины своя СУБД и там сообщения хранятся в бинарном виде, наверное, максимальный размер зависит от настроек СУБД.

Какие типы источников могут использоваться в 1С:Шина? FTP, HTTP и так далее.

Протокол AMQP можно нативно использовать как с 1С-интеграциями через сервисы интеграции, так и для RabbitMQ. Также можно использовать файловые, GMC, FTP и HTTP каналы – исходящие так и входящие.

Подразумевает ли 1С:Шина кастомизацию? Можно ли создавать свои коннекторы – к примеру, для S3, Redis или для чего-нибудь еще?

Если напишете. 1С:Шина написана на 1С:Элементе, там есть свой язык разработки. Вы можете ее кастомизировать, писать свои препроцессоры – хоть бизнес-логику там реализовать.

По вашему мнению, фирма «1С» даст добро на тиражное использование этих коннекторов? Я сравниваю с Mule ESB – это тоже аналог Шины на Java, на Eclipse. Там в комплект стандартной поставки входят коннекторы, которые изначально были разработаны сообществом.

Я думаю, что вопрос больше к фирме «1С». Не вижу никакой причины, почему бы они не пошли на это.

Создание коннектора подразумевает снятие 1С:Шины с поддержки?

В 1С:Элементе нет такого понятия.

На слайде была фраза «невозможно потерять сообщение». А вы каким-то образом проверяли или пробовали специально потерять сообщение?

Да. Я показывал на слайде – мы гасили Шину, а потом гасили получателя и смотрели, как ведут себя сервисы интеграции.

А как гасили Шину?

Через ребут.

Я пробовал передавать большой файл и в процессе делал hard reset Шины – в итоге получал потерю данных сообщения: часть данных ушла из отправителя, часть попала в Шину, часть потерялась безвозвратно, и исходящая очередь стала колом, пока ручками не стерли в табличке очереди эту сбойную запись.

Вы отправляли файл единым пакетом, не чанками?

Я просто отправлял сообщение, там был бинарь 4 гига. Специально взял такой объем.

А само сообщение в табличке out появилось?

Да, и там эта строчка осталась, потому что сообщение не ушло до конца. Чанки уходили, но в процессе я ее потушил.

Т.е. Шина разбила ваше сообщение на несколько?

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

А какая версия?

Примерно последняя, где-то несколько месяцев назад на тот момент (прим. ред. доклад от 7 октября 2022 года).

Мы ловили подобную ошибку на тестовой версии, 1.1. Но там это была не проблема битого сообщения, а проблема задвоенных идентификаторов.

Как лечилось?

Через TRUNCATE.

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

Вопрос в том, как те же журналы сообщений собирать и укладывать в код 1С. Если мы будем каждую запись пытаться записать как одно сообщение, база действительно не вывезет. Но мы получаем сразу массив данных через BULK и его записываем. Поэтому здесь уже вопрос производительности больше к дисковой подсистеме, а не к 1С.

Все, что мы реализовали, это исключительно нативно – никаких внешних компонент, никаких сторонних решений. Журнал регистрации парсится, разбирается, собирается JSON для ClickHouse и так далее, исключительно средствами 1С.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.