Меня зовут Денис Бельмач. В этой статье я расскажу о том, как в компании АО «Гринатом» мы разработали единое информационное пространство для множества бэкендов 1С и не только. Я являюсь главным архитектором по закупочным системам ЦК 1С. Мой опыт в IT составляет более 12 лет, а в компании АО «Гринатом» я работаю с 2021 года.
Задачи проекта
Начнем с задач, которые перед нами поставила отрасль в рамках проекта по замене закупочных систем. Основная цель заключалась в том, чтобы заменить систему SAP, используемую для проведения закупок, на отечественное решение. Заказчик выдвинул несколько ключевых требований:
-
Вся бизнес-логика должна быть сосредоточена на бэкенде, а фронтенд – только отображать пользовательский интерфейс.
-
Система должна обеспечивать поддержку до 5000 одновременно работающих активных пользователей.
-
Гарантированная доставка сообщений: каждое сообщение, поступившее с фронтенда, должно быть обработано и возвращено клиенту.
-
Время отклика системы не должно превышать 3 секунд.
Выбор архитектурного подхода
Первым шагом стал выбор архитектурного подхода. Мы рассматривали три варианта (монолитная, микросервисная, композитная) и в итоге остановились на композитной архитектуре, которая объединяет преимущества как монолитной, так и микросервисной архитектуры.
Выбор платформы и СУБД
Следующая задача заключалась в выборе бэкенда. Мы остановились на платформе 1С, но важно уточнить, что речь идет именно о Z-платформе. В качестве СУБД была выбрана Postgres Pro, что также соответствовало требованиям по импортозамещению.
После того, как мы определились с бэкендом, перед нами встала задача выбора конфигурации. Мы рассматривали различные варианты: использование тяжелой конфигурации на базе ERP УХ, ERP-консолидацию или более типовые конфигурации. В итоге мы пришли к решению разрабатывать конфигурацию на основе библиотеки стандартных подсистем и создать полноценное самописное решение.
Выбор технологии фронтэнда и транспорта
В качестве фронтенда мы выбрали Vue 3, так как у команды был опыт работы именно с этим фреймворком.
С транспортом возникло больше сложностей, потому что протокол HTTP не гарантировал доставку сообщений. 1С:Шина на тот момент находилась в стадии тестирования, и мы не могли ее использовать. Поэтому мы остановились на RabbitMQ и прокси на Rust, что также является самописным решением.
Почему RabbitMQ? Во-первых, он хорошо документирован. Во-вторых, он давно развивается и зарекомендовал себя на рынке. Мы могли использовать его и в дальнейшем.
Финальная архитектура системы
У нас есть набор подсистем – «Бриф», «Закупки», «Договор». Это функциональные подсистемы, которые представляют собой конфигурации на базе 1С.
«Атом.Форма» – это фронтенд, который мы разработали. Между фронтендом и подсистемами находится «Атом.Гейт» – тот самый прокси, о котором я упоминал. Помимо этого, функциональные подсистемы взаимодействуют между собой через брокер сообщений RabbitMQ. Кроме конфигураций 1С, у нас также есть сервисы роботов и сервисы поиска.
Обмен frontend-backend
Когда мы разобрались с архитектурой, начали продумывать, как будет происходить взаимодействие между фронтендом и бэкендом. Общая схема выглядит следующим образом: пользователь нажимает кнопку на веб-странице, запрос уходит в функциональную подсистему. Она формирует ответ в формате JSON, а «Атом.Форма» преобразует этот ответ в конечную страницу для пользователя.
Взаимодействие с RabbitMQ
Было принято решение, что для каждой функциональной подсистемы создаются две очереди – входящая и исходящая. Фронтенд помещает запрос во входящую очередь, бэкенд считывает сообщение, обрабатывает его, формирует ответ и кладет в исходящую очередь. «Атом.Гейт» – наш прокси – считывает сообщение и передает его «Атом.Форме».
На начальном этапе этот подход себя зарекомендовал: система функционировала, тесты проходили успешно. Однако при нагрузочном тестировании мы поняли, что работа с одной очередью – это узкое место, и сообщения не успевали обрабатываться.
Тогда мы начали искать решение и нашли его в RabbitMQ: там существует тип точек обмена под названием consistent hashing exchange, который позволяет равномерно распределять сообщения от клиентов по большому количеству очередей.
Мы использовали это решение: добавили точку обмена для каждой функциональной подсистемы и, в зависимости от нагрузки, создавали необходимое количество очередей. Сервер считывал сообщения, обрабатывал их и отправлял обратно в исходящую очередь.
RabbitMQ для обмена между системами
RabbitMQ используется не только для обмена между фронтендом и бэкендами, но и для взаимодействия между функциональными подсистемами. Далее представлен вариант обмена одного потока данных.
Например, если одной функциональной подсистеме нужно передать данные другой, первая создает точку обмена. Потребители подключаются к ней, создавая очередь и настраивая маршрутизацию, чтобы получать необходимые сообщения и данные.
Синхронный формат обмена
Изначально мы разработали синхронный формат обмена между фронтендом и бэкендом: запрос отправляется в функциональную подсистему, и на стороне «Атом.Гейт» включается обработчик ожидания ответа. Тайм-аут был установлен на 50 секунд – если за это время ответ не поступал, все последующие сообщения игнорировались. В целом решение работало, но со временем функциональные подсистемы развивались, объем данных увеличивался, формы становились сложнее, и даже 50 секунд перестали быть достаточным временем для полной загрузки.
Тогда мы начали искать альтернативные решения и реализовали формат обмена SSE – Server-Sent Events. Эта технология позволяет серверу отправлять клиенту дополнительную информацию и загружать данные по мере необходимости.
Преимущество SSE в том, что каждый запрос можно фрагментировать: на один запрос сервер может отправлять несколько ответов, загружая информацию постепенно. Кроме того, мы реализовали онлайн-обмен между клиентами: когда один пользователь выполняет действие (например, редукционы), информация о совершенном действии сразу становится видна всем участникам процесса.
Структура запросов от фронтенда к бэкенду
Структура запросов от фронтенда к бэкенду достаточно проста: запрос состоит из двух частей – заголовка (header) и тела сообщения (body). В заголовках хранится служебная информация, необходимая серверу для принятия решений. В теле сообщения передаются параметры, на которые реагирует бэкенд.
Один из ключевых параметров – свойство command. В нем перечисляются действия, которые должен выполнить бэкенд, и для каждого действия предусмотрена своя обработка данных. От этого параметра зависят передаваемые параметры, контекст и другие детали.
Например, в запросе клиент может указать, какую информацию о пользователях нужно вывести, с какими фильтрами отобрать данные и вернуть их пользователю.
Структура ответа бэкенда
Структура ответа более сложная, так как вся бизнес-логика, включая работу с формами, выполняется на стороне бэкенда. Ответ состоит из заголовка и тела сообщения. В теле сообщения содержатся параметры, такие как «ЭлементыФормы», связанные со свойствами данных, и заголовок этой формы.
Далее представлен пример данных. «ЭлементыФормы» представляют собой массив, где каждый элемент обладает своими свойствами. Они тесно связаны и во многом напоминают свойства, которые есть в самой платформе 1С.
Разработка форм
Разработка формы изначально осуществлялась на стороне сервера. Самым быстрым решением было формирование этих форм вручную: создавался JSON-файл, который помещался в макет, а данные из него записывались в регистр. При обращении к форме мы просто забирали ее и дополняли актуальными данными.
На первоначальном этапе этот подход удовлетворял нашим потребностям, но со временем формы становились все больше, а JSON-файлы разрастались до нескольких тысяч строк. Редактировать их и отслеживать изменения – например, проводить ревью – стало крайне сложно.
Поэтому мы решили создать конструктор форм. Это обработка, которая позволяет работать с объектами формы средствами кода 1С. В результате ее работы формируется JSON, который затем заполняется данными и передается клиенту.
Среди плюсов такого подхода:
-
встроенная документация: среда разработки начала подсказывать, какие свойства и параметры можно использовать,
-
упростилось ревью форм: изменения стало удобнее отслеживать.
Однако есть и минус: если на стороне фронтенда меняется API, приходится дорабатывать или изменять обработку.
Реализация отчетности в системе
Одно из требований заказчика заключалось в отчетности. Мы разработали компоненту для фронтенда, которая визуально полностью напоминает систему компоновки данных (СКД) и вдохновлена тем, как работают отчеты внутри 1С.
Общая логика работы такова: разработчик создает отчет в СКД, вносит его в систему. У клиента появляется меню, где он может выбрать этот отчет. После того как пользователь нажимает кнопку «Сформировать», формируется запрос с настройками отчета. На стороне бэкенда этот запрос десериализуется, заполняются настройки схемы компоновки данных, выполняется отчет, и полученный табличный документ сериализуется в JSON-формат, после чего отправляется обратно клиенту.
Единое информационное пространство
Вот как выглядит наше единое информационное пространство: пользователь видит перед собой единую систему, не подозревая, с какими именно подсистемами он работает в данный момент. Мы реализовали механизмы кросс-ссылок, которые позволяют переходить из одной подсистемы в другую – например, из системы закупок можно открыть карточку клиента из подсистемы «Бриф». Для пользователя этот переход прозрачен, как будто он просто открыл карточку внутри одной системы. Главное условие – наличие соответствующих прав доступа.
Нам не хватило готовых решений для работы с динамическими списками. В 1С этот механизм реализован отлично, но внешнего API для интеграции с внешними фронтендами нет. Пришлось разрабатывать все самостоятельно, что заняло немало времени. Также не удалось в полной мере использовать подсистему взаимодействия для интеграции с внешними фронтендами, например, для подключения чатов.
Проблемы. Оптимизация. Инструменты
Одна из самых сложных задач на начальном этапе – авторизация пользователей. Данные считываются из очередей, но все действия должны выполняться от имени конкретного пользователя. Пользователь авторизуется по JWT-токену, и нам нужно было понять, как реализовать эту логику.
В заголовке сообщения передается JWT-токен. На стороне бэкенда мы разбираем этот токен, извлекаем ключевые свойства, чтобы определить пользователя. Если пользователь не найден, для него создается отдельное регламентное задание, срок выполнения которого устанавливается на время жизни токена. Это задание запускается от имени пользователя, просматривается справочник входящих сообщений – тех, что приходят с фронтенда – и выполняются действия согласно запросу. Таким образом проблема авторизации была решена.
Мы проводили нагрузочное тестирование. Подробно останавливаться на проблемах и инструментах, которые помогли выявить узкие места, не буду – это тема отдельной статьи. Но для себя мы сделали несколько важных выводов: необходимо внимательно читать документацию, написанную на ИТС, и следовать рекомендуемым настройкам. Также важно придерживаться стандартов фирмы 1С при оптимизации кода.
Далее представлены результаты первого нагрузочного тестирования и итоги после оптимизации. Между этими этапами прошло около полутора месяцев, и по некоторым операциям производительность выросла в десятки раз.
Что касается инструментов разработки: мы используем связку EDT и Git, хотя изначально не могли применять ее из-за ограничений поддержки платформы 8.3.14 в EDT.
Мы пробовали несколько инструментов для юнит-тестов, в том числе Vanessa ADD, но в итоге остановились на YaxUnit – рекомендую его тем, кто планирует заниматься написанием юнит-тестов для своих систем.
Для автоматизации сборки и обновления баз используем GitLab CI.
Для статического анализа кода используем SonarQube.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
