Привет, Хабр! Меня зовут Максим Вишняков, я ведущий разработчик в Axenix. За время работы я накопил обширные знания в части оптимизации, развития и поддержки различных решений на платформе 1С:Предприятие. В этой статье хотел бы рассказать об опыте оптимизации работы ERP-системы для лидера алкогольного рынка, который отгружает продукцию в режиме 24/7 и осуществляет огромный объем операций.
Суть проекта
Наша команда работает с одним из крупнейших производителей алкогольных напитков в России. Приемка сырья и отгрузка готовой продукции на предприятии не останавливаются ни на минуту, ведется постоянный обмен данными с внешними информационными системами.
Ранее компания использовала зарубежную ERP-систему, но некоторое время назад перешла на связку «1С:ERP.УХ + Производство алкогольной продукции (ПАП)». Система отвечает за критически важные процессы — закупки, складскую логистику и управление отгрузками. Новый контур получил высокую степень автоматизации: активно использовались цепочки взаимосвязанных документов, автоматически создавались сопутствующие сущности и выполнялись многочисленные операции обмена с внешними системами, включая ЕГАИС и «Честный знак».
Масштабы операций, в особенности большой объём круглосуточных отгрузок и приёмок продукции, определяли высокие требования к производительности системы. Поэтому решения по оптимизации закладывались и реализовывались непосредственно в ходе миграции, а затем уточнялись и развивались по мере эксплуатации системы.
Оптимизация: очереди заданий и особенности их применения
Один из ключевых показателей производительности, требующий особенного внимания — время выполнения транзакций. Его увеличение сказывается на всей системе: замедляются ключевые бизнес-процессы, возрастает нагрузка на инфраструктуру, увеличивается время отклика.
Для оптимизации этого показателя было принято решение активно использовать очереди заданий, которые представляют собой относительно простой и эффективный механизм оптимизации работы ERP. Очереди позволяют разгружать основные процессы и распределять выполнение ресурсоемких задач во времени, снижая нагрузку на систему в пиковые моменты и сокращая время выполнения пользовательских транзакций. Таким образом, очереди заданий выступают не просто техническим механизмом, а архитектурным способом управления нагрузкой в системе.
Вместо того чтобы обрабатывать все действия пользователя непосредственно в момент выполнения операции — например, при проведении документов закупки или отгрузки — часть бизнес-логики помещается в очередь фоновых заданий. В результате пользовательская транзакция фиксирует только ключевые данные и завершает работу значительно быстрее, а последующая обработка, включающая расчеты, обмены и обновление связанных регистров, выполняется системой асинхронно в фоновом режиме.
Особенно заметный эффект это дает в сценариях массовых операций. Например, при пакетном проведении документов, обработке складских операций или формировании данных для передачи регулятору, поскольку позволяет избежать накопления длительных транзакций и связанных с ними задержек для пользователей.
При этом мы понимали, что использование очередей заданий может создать и определенные сложности: увеличить время разработки бизнес-логики и снизить прозрачность процессов как для пользователей, так и для разработчиков.
Дополнительную сложность создает то, что механизм очередей может быть реализован множеством способов. При отсутствии единых правил и архитектурных ограничений это приводит к неоднородности решений внутри системы.
Поэтому в рамках проекта мы сразу же создавали единый, универсальный механизм, который позволяет обойти указанные сложности и который можно использовать повторно в различных сценариях. Схематичное представление архитектурного решения приведено на схеме ниже.
Как именно это работает?
Для каждой отдельной бизнес-задачи (или типа обработки / бизнес-сценария) реализуется свой собственный регистр очереди и свое регламентное задание. Оно в свою очередь запускает универсальный обработчик очередей, передавая в качестве параметров имя очереди и настройки обработки: количество потоков, размер пакета обработки и задержку обработки каждой записи при возникновении ошибки.
Универсальный метод обработки позволяет осуществлять выборки из очереди и разделения потоков, сама же бизнес-логика располагается в модуле менеджера соответствующего бизнес-объекта (документа / справочника).
Первое, что обеспечивает такой подход – универсальную структуру регистров очередей. Как следствие, отсутствуют трудозатраты на, по сути, одно и то же проектирование. Также появляется возможность массовой обработки всех очередей проекта.
Общий механизм обработки очередей накладывает ограничения на размещение бизнес-логики, что упрощает дальнейшее сопровождение. Становится ясна точка входа, а размещение обработчика очереди в модуле менеджера позволяет изменять бизнес-правила для каждого типа объекта обработки отдельно в рамках одной очереди.
Оптимизация в инфраструктурном контексте
Оптимизация программного решения – не всегда про быстродействие. Иногда на нее важно посмотреть, как на процесс адаптации программного решения к инфраструктурным реалиям.
В процессе эксплуатации внедренной системы были выявлены частые аварийные завершения фоновых заданий, вызванные падениями процессов rphost’ов (рабочих процессов сервера «1С:Предприятие»).
В рамках внедрения в системе был реализован собственный обмен с WMS. Для выполнения высоких требований к скорости обмена и повышения его стабильности, он выполнялся несколькими экземплярами регламентных заданий. При этом каждый из экземпляров работал в многопоточном режиме – иначе говоря, в обработке у нас могло быть до 12 входящих сообщений одновременно.
Чтобы гарантировать, что два разных потока не будут обрабатывать одно и то же сообщение одновременно, входящие сообщения получили соответствующую статусную модель. Принципиальная схема обработки сообщений вместе со статусной моделью представлена ниже.
Эта реализация обмена в течение длительного времени демонстрировала устойчивость, но оказалась абсолютно не готова к реальности, в которой фоновое задание может аварийно завершиться, в результате чего сообщение зависало в обработке уже несуществующего сеанса. Как итог – не только избыточная обработка из-за падения rphost’ов, но и зависшие сообщения.
С программной точки зрения эта проблема решается через реализацию дополнительного регламентного задания, которое обнаруживало эти «зависшие» сообщения и возвращало их в статус «Не обработан», что позволяло заново взять их в обработку.
Таким образом, в условиях высоконагруженной системы ключевым фактором устойчивой работы становится не столько наращивание ресурсов, сколько грамотное управление временем выполнения транзакций. В рассматриваемом проекте именно этот показатель стал отправной точкой для принятия архитектурных решений.
Использование очередей заданий позволило вынести ресурсоемкую бизнес-логику за пределы пользовательских операций и тем самым сократить время отклика системы в критических сценариях. При этом важным оказалось не только само применение механизма, но и его унификация. Единый подход к реализации очередей позволил избежать избыточной сложности и упростить дальнейшее сопровождение решения.
Однако даже корректно выстроенная архитектура не дает полной картины без понимания того, как система ведет себя в эксплуатации. Для этого необходим следующий слой, а именно — мониторинг, который позволяет не только фиксировать возникающие проблемы, но и развивать решение на основе реальных данных о его работе.