Космическая Одиссея 2020 года

Меня зовут Григорий Шатров, я из компании «ИнфоСофт», город Новосибирск.

Хочу рассказать вам интересную историю, вдохновением и САСПЕНСом для которой послужило великое произведение режиссера Стенли Кубрика – фильм «Космическая Одиссея 2001 года».

Как вы помните, классическая история «Одиссеи» началась с того, что на нашу Землю приземлился большой черный монолит, который содержал в себе что-то неизведанное, но при этом – самое главное для наших землян.

В нашей истории этим «монолитом» стали тысячи внешних устройств с разнородными показателями, которые нужно было считывать и загружать в нашу систему. Для этого нужно было настроить потоковый обмен данными через доступные у этих устройств интерфейсы – с помощью CSD-модемов/опросников, а в некоторых случаях через TCP-соединения.

После нескольких мозговых штурмов было выработано достаточно интересное классическое решение с некоторыми особенностями.

• Бэкендом у нас являлась учетная система 1С, которая была написана с нуля на основе БСП и БИП (библиотеки интернет-поддержки). Она у нас крутилась в облаке – внутри нее формировались все нужные данные, которые показывались пользователям.

• Правой рукой, артерией служил веб-сервер Apache и самописные PHP-запросы – они помогали нашей системе 1С взаимодействовать с «Системой опросов устройств».

• И на острие атаки у нас использовалась самописная программа на C# «Система опросов устройств» (MIS) – она опрашивала все эти устройства, получала от них нужные данные и записывала их в 1С. Для разработки этой программы мы специально использовали C#. Несмотря на то, что большинство разработок с нуля у нас в компании ведется на платформе 1С, наши внутренние хакатоны позволили нам расширить вектор во все стороны, и для данного проекта мы выбрали наиболее эффективные инструменты из имеющихся.

Используем гравитацию: строим экосистему с 1С-ным ядром

Давайте заглянем внутрь нашего «космического корабля». Процессы взаимодействия 1С и «Системы опросов» были разделены по принципу микросервисов, реализованных в виде регламентных заданий.

• Первый микросервис запускал процесс «Формирование и отправка заданий для устройств». В данном процессе 1С дает устройству задание проинициализировать какое-то действие и отправляет это задание в «Систему опросов».

• Когда задание попадает в наш космический корабль «Система опросов», оно может долететь до любой звезды и привести оттуда нужную нам информацию с данными устройств.

• Эта информация фиксируется в нашей системе – как положительные, так и отрицательные результаты. Отрицательный результат по опросу – это тоже результат. Процесс получения данных JSON из этих устройств и разбор этих JSON по нужным аналитикам внутри системы 1С у нас также разделен по отдельным микросервисам – «Получение» и «Разбор».

Давайте рассмотрим все эти процессы по отдельности.

За первый процесс отвечает микросервис «Формирование и отправка». Ему нужно уделить отдельное внимание, так как в этом микросервисе для обмена с нашей «Системой опросов» все данные уже должны быть подготовлены в нужном формате.

При разработке данного процесса мы прошли несколько итераций, как можно было формировать данные задания.

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

• Поэтому мы пришли к следующей логике по формированию данных заданий – это ежедневное формирование запросов, но уже периодичностью менее чем «День», с последней успешно загруженной информацией по данному устройству. При этом в системе копятся все последние опросы на текущую дату, и не возникает технологических «дыр» в полноте данных по всем устройствам.

Балансируем в невесомости: разрабатываем центр управления тысячами внешних устройств

Следующей составляющей системы стала «Система опросов» – наше C#-ное детище, которое и опрашивает разнородные устройства.

«Система опросов» состоит из нескольких компонент.

• Первый компонент – это MQB, сам балансировщик заданий, тикетов и т.д. Балансировщик работает с каждым заданием, ни одно из них не будет им пропущено – при этом будут получены все нужные данные.

• Второй компонент – MI. Но это не Xiaomi-телефон, а компонента MI MTI, которая по разным протоколам опрашивает каждое из устройств и получает данные. Т.е. это – рабочая лошадка, ядро самой системы опросов, которое непосредственно уже отправляет конкретные задания, опрашивая конкретные устройства.

• И третий компонент – это MCT, такая метровая палка, с помощью которой можно «потыкать» устройство из системы 1С, если оно не работоспособное, вышло из строя или не отвечает некоторое время. Через эту компоненту данные от устройств можно получать практически в онлайне, даже несмотря на то, что система 1С и «Система опросов» работают асинхронно.

А как управлять большим количеством тикетов, и при этом не построить какой-то сложный пульт управления?

Как сделать управление максимально простым?

Тут нам на помощь приходит система Канбан-доски. В этом случае мы определяем каждое из заданий по аналитике или статусам данных заданий. И формируем нашу систему.

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

• В папку IN у нас попадают все задания, нужные для опроса.

• После этого, если балансировщик подхватил данное задание, он определяет его в папку IN PROGRESS.

• После этого, если это устройство успешно опрошено, задание попадает в папку OUT.

• И когда 1С успешно забирает данные через PHP-запрос, как лог перемещается в COMPLETE.

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

• И после прохода N итераций, если устройство все-таки не выходит на связь, задание попадает в FAILED. Если выходит, в OUT.

• И также у нас есть папка UNKNOW, куда попадают совсем неизведанные задания. За счет того, что наши устройства реально масштабируются и могут попасться абсолютно уникальные случаи.

Наблюдаем в иллюминатор из 1С: разбираем вопросы взаимодействия инфосистем

Для формирования панели мониторинга с данными заданиями была написана панель на основе графического движка chart.js с применением технологии AJAX. Она позволяет получать все нужные данные без обновления самой странички.

Так как наши пользователи работают в 1С, с помощью реквизита строкового типа и поля HTML-документа можно максимально просто поместить данную панель мониторинга в 1С.

Также можно скомпилировать ее в Android-приложение – это тоже прекрасно работает.

Подчиняем космические скорости: создаем балансировщик системы опросов

Но как сделать данные очереди максимально эффективными для самой «Системы опросов»?

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

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

• Содержания, где содержится сам JSON запроса, с помощью чего уже опрашиватель собирает данный JSON и опрашивает соответствующее устройство.

После опроса нашей MIS все JSON-запросы попадают в 1С и разбираются по нужным аналитикам.

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

• Плюсом, конечно же, является бесконечная масштабируемость данного подхода, несвязанность параметров.

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

Отображаем динамические показатели

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

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

Для этого взят динамический список. В обработчике «ПриСозданииНаСервере» формы, внутри которой нужно было показывать данные показатели, просто создавался динамический список с колонками всех показателей, которые есть вообще в системе.

Т.е. фиксировалась колонка под каждый показатель, типизировалась.

И после этого в обработчике «ПриПолученииДанныхНаСервере» для определенных строк просто определялось, какие колонки нужно показывать. Эти колонки заполнялись нужными данными, а для остальных убиралась видимость.

Кажется, что это будет работать медленно, но нет – это работает очень быстро. При этом работу с динамическим списком можно круто настраивать для пользователя.

Тестируем связь с устройствами

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

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

После этого инженеры, которые могут проверить устройство и ответить, действительно ли оно неработоспособно, формируют команду «Тест связи». Эта команда имеет высокий приоритет, моментально обрабатывается устройством и позволяет понять – живое оно или нет. Если устройство реально работает, они включают обратно в стек всех очередей по данному заданию, и после этого оно заново начинает опрашиваться, не образуя дырок в полноте всех данных.

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

Реализуем многопоточность

В HighLoad мы все встречаемся и все когда-то натыкаются на то, что нужно использовать многопоточность. В нашем случае использование нескольких потоков нужно было в процессе разбора самих JSON-запросов, так как их было очень много.

Кейс обработки нескольких потоков я разделяю на два типа:

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

• И второй кейс – это пополняемый стек каких-то данных. В нашем случае, JSON-запросов. Т.е. в момент, когда вы запустили много потоков, может прилететь еще столько же, либо большее количество JSON-запросов. Это непрогнозируемый объем данных. В этом же случае к нам приходит на помощь метод «ОжидатьЗавершения(<Таймаут>)» управляющего фонового задания. Этот метод образует паузу, которая нужна всем 1С-никам, чтобы не грузить ЦП на 100% в бесконечном цикле. И после этого мы проверяем – есть ли сейчас вообще, чему опрашиваться. Есть ли неопрошенный JSON. Если он есть, мы формируем фоновое задание – если оно не превышает количество необходимых нам потоков. Если оно превышает, то мы ждем дальше через «ОжидатьЗавершения(<Таймаут>)». И точкой выхода из этого бесконечного цикла с паузами, конечно, является то, что уже нет JSON-запросов для разбора. Мы выходим их этого управляющего фонового задания и после этого по регламенту заново пробуждаем это управляющее задание.

Обманываем оптимизатор запросов СКД

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

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

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

При этом конструктор запросов внутри СКД максимально правильно это обработает, ничего не допишет, не уберет из группировок – таким образом мы оптимизатор «обманываем».

Время историй

Расскажу об особенностях, с которыми мы столкнулись в нашей истории.

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

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

• Следующее, с чем мы столкнулись – это то, что при группировке реквизитов строкового типа внутри объекта «Запрос» сама 1С не смотрит на регистр данных строк. Допустим, «а» и «А» будут сгруппированы в одну строку. То же самое – «Иванов» и «иванов». Возможно, это известный факт, но я выделил его здесь для тех, кто с этим не сталкивался, чтобы в дальнейшем вы у себя в системе это учитывали.

• У нас в системе для каждого из устройств хранился уникальный номер – в реквизите строкового типа справочника по этим устройствам. При этом заранее не было известно, что должно было быть внутри этих номеров. Сейчас мы определились, что туда попадают только числа – заложили это в алгоритмы по опросу данных устройств. Потому что в какой-то момент одно из устройств реально украли с адреса, где оно находилось. И мы в качестве значения реквизита этого устройства мы записали «123_Украден», чтобы исключить его из общего пула всех заданий.

• Также мы столкнулись с особенностями работы присоединенных файлов в режиме мобильного клиента. Как я говорил ранее, мы использовали крутую возможность мобильного клиента фотографировать устройство через камеру телефона. При этом БСП очень классно обрабатывает – файл сразу же прикрепляется к нужному объекту из системы. Но в БСП 3.0.3 мы столкнулись с проблемой, что при переключении с мобильного клиента на десктопную версию рабочий каталог, куда сохранялись временные файлы по этим присоединенным файлам, не переключался обратно. Тем самым, при работе на компьютере просто не было возможности вообще работать с присоединенными файлами – он пытался обратиться в нужную ему папку на Android. В этом случае помогала очистка рабочего каталога.

Полезные инструменты не-1С-ника

При работе с не-1С-ными системами мы наткнулись на интересные моменты:

• Например, оказалось, что разработчики устройств придумали максимально новую для меня систему счисления (не десятичную и не шестнадцатеричную). Дело в том, что показатели данных устройств всегда получаются с учетом дробной части – какое-то целое число и какая-то часть дробная. Но для конкретных типов устройств нужно было заранее определить, сколько в принципе у нас длина дробной части, исходя из ширины значимых цифр внутри экранчика данного устройства. Допустим, у них есть 7 значимых цифр внутри этого экранчика, если туда попадает целое число, которое занимает 7 символов, оно 7 символов туда переводит без дробной части. Если в целой части 6 символов, тогда показывается 6 символов целых и один символ – в дробной части. Получается, что при работе с двоичными или шестнадцатеричными данными нужно было заранее знать, сколько символов есть – эта неизведанная для нас система счисления тоже была для нас интересным моментом. Инструменты, приведенные по ссылкам https://crccalc.com/ и https://www.h-schmidt.net/FloatConverter/IEEE754.html помогают рассчитывать все эти моменты.

• Также нам пригодились слушатели всех COM-портов и всех TCP-соединений, чтобы правильно получать от всех этих устройств двоичные, десятеричные и шестнадцатеричные данные.

• И мы постоянно использовали всеми любимый GIT. В мире 1С его люди тоже все чаще и чаще начинают использовать. Но внутри мира C# GIT дает возможность попробовать подтвердить либо не подтвердить гипотезы, а также может быть крутым источником для бэкапирования.

Заключение

Все наши собранные знания по архитектуре, по инструментам, подходам дают возможность без проблем серфить по космическому океану навстречу нашему новому «монолиту». Айда вместе с нами!

На этом история нашей космической одиссеи заканчивается. Да прибудут всем интересные и новые прогрессивные идеи!

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.