О компании и единой ИТ-инфраструктуре
СДЭК – это крупнейшая логистическая компания России. Думаю, все так или иначе пользовались услугами СДЭК. Кто-то напрямую, придя в ПВЗ, но большинство стали клиентами СДЭК, пользуясь услугами известных интернет-магазинов и маркетплейсов. Под капотом там очень часто именно СДЭК.
СДЭК – это группа компаний. В состав группы входит несколько сервисных компаний и сеть из более чем четырех тысяч партнеров. Партнеры – это юридические лица, работающие более чем в сорока странах мира.
Сервисная компания задает и контролирует стандарты работы сети, обеспечивает магистральную логистику, выполняет оркестрацию работы сети и много чего еще. В том числе обеспечивает единую ИТ-инфраструктуру для всех компаний группы.
Все сотрудники компании и группы работают в единой ERP-системе под названием ЭК5. Это система класса ERP, построенная по микромодульной архитектуре. Каждый модуль обеспечивает свою функцию и является условно независимым.
У ЭК5 есть несколько фронтов. В том числе для клиентов СДЭК, для нас с вами, – это сайт sdek.ru и мобильное приложение СДЭК. Для бизнес-пользователей – сайт ЭК5 и мобильное приложение ЭК5.
Взаимодействие модулей построено по классической для подобного рода систем схеме. Это преимущественно асинхронные взаимодействия по протоколу AMQP. В качестве брокера выступает RabbitMQ. Синхронные взаимодействия – REST API, все классически.
В структуру единой ERP-системы ЭК5 входит порядка двадцати баз 1С. Они также выполняют свои функции, при этом некоторые выведены на веб-фронт ЭК5 во фрейме.
Проблемы старого модуля клиентских документов
Среди более чем двухсот модулей ЭК5 есть модуль по формированию документов для клиентов СДЭК – для корпоративных клиентов СДЭК. Его цель – сформировать различные акты, детализации к актам, взаимозачеты, отразить всевозможные начисления.
Документы модулем формируются автоматически. У модуля есть фронт. Пользователи на этом фронте могут отредактировать автоматически сформированные документы, отправить их на почту, на ЭДО. Модуль поставляет данные для баз регламентированного учета, для BI и много еще для кого.
Модуль клиентских документов – это очень сложная и высоконагруженная система. Ежемесячно он получает до миллиарда событий других модулей. На их основании формирует порядка трех миллионов первичных актов. Более четырех тысяч юридических лиц ведут в этом модуле учет продаж и услуг для своих 700 тысяч корпоративных клиентов. Все это – в одной базе данных.
Этот модуль – один из ключевых элементов ЭК5. Это не база регламентированного учета, в нем ведется оперативный учет деятельности кампании. Если не будет этого модуля, бизнес СДЭК не сможет существовать.
И у этого модуля были большие проблемы, в первую очередь архитектурные. Он был написан не универсально. Изменение договорных обвязок, изменение законодательства, появление новых видов услуг приводили к необходимости фактически полного его перестроения.
Архитектура модуля подразумевала хранение данных в плоских таблицах. За годы работы эти таблицы выросли до эпических размеров, что в конце концов привело модуль к деградации.
Модуль, помимо прочего, вел агрегированный учет. Представьте: есть некая таблица, в которой есть документ, номенклатура и сумма в рублях. Но провалиться в историю, узнать, каким темпом накапливалась эта сумма, из каких физических событий она была сформирована, было фактически невозможно.
Мало того, накопление актов происходило не онлайн. От момента события в реальном мире до появления начисления в акте проходило значительное время. А хотелось иначе.
Агрегированный учет не подходит. Нужна полная сторнирующая ретроспективная модель, чтобы можно было проследить, из какого физического события и каким темпом накапливалась каждая сумма в акте. Нужен drill-down от этой суммы акта до события в модуле-источнике, который ведет физический учет оперативной деятельности компании.
Нужна непрерывность, чтобы от события в реальном мире до начисления в акте проходили минуты. Надо, чтобы система была гибкой, чтобы она успевала за постоянно меняющимся законодательством и договорными обвязками. Нужен полноценный биллинг.
Выбор платформы 1С и переосмысление архитектуры
В компании было принято решение разработать новый модуль с нуля. Изначально были мысли построить модуль на Java. Но это дорого и долго. Помимо ресурсов разработки, нужны еще и методологи финансового учета. Так сложилось, что концентрация компетенций была в департаменте разработки финансовых продуктов, а в СДЭК это 1С.
В этой связи решили посмотреть на 1С попристальнее. Решения 1С из коробки уже имеют веб-фронт. Это среда быстрой разработки, кто бы что ни говорил. Она близка к базам регламентированного учета. А главное – есть ресурс.
Казалось бы, все есть. Однако решение сделать на 1С было сложным и выглядело как авантюра. С нагрузками не справлялись модули, написанные на Java, которые могли использовать всю мощь СУБД. Инструментарий Java в принципе не сравним с тем, что предоставляет платформа 1С.
Однако анализ показал, что непригодным старый модуль, написанный на Java, сделала его несовершенная архитектура. Непригодным его сделало неоптимальное хранение, а также очень сложные и запутанные взаимозависимости внутри объектов.
Это привело к огромному количеству костылей и косности. А если попытаться построить архитектуру правильно, то 1С выглядит вполне приемлемым решением. Главное – спроектировать его так, чтобы обойти слабые места 1С.
Архитектура данных – это ключ к успеху.
Принципы правильной архитектуры данных и пять слоев
Правильная архитектура данных – это такая архитектура, которая четко изолирует данные объектов друг от друга, уменьшает их взаимозависимости и взаимосвязи.
Данные физического объекта должны храниться отдельно от мысли об этом объекте. При этом даже сами мысли должны храниться слоями, если эти мысли возникают на различных основаниях.
Приведу простейший пример. Нам нужно хранить информацию о красивых камнях. Мы можем завести справочник «Красивые камни» – и совершить архитектурную ошибку.
Красивость – это мысль людей о физическом объекте. Мысли изменчивы, а объект неизменчив, он намного более стабилен. Создав такой справочник, мы обречем себя перезаписывать его элемент каждый раз, когда изменилась мысль. Хотя сам объект не изменился.
Заведя отдельный справочник для камней и регистр для хранения информации о его красивости, мы избавимся от этих проблем. Область изменения данных при смене мыслей будет значительно меньше. Это принцип.
При проектировании биллинга мы выделили условно пять слоев данных. Это физические события, финансовые события, расценки, расшифровки актов и сами акты.
Слои были спроектированы таким образом, чтобы максимально изолировать данные одного слоя от другого, чтобы изменение правил формирования информации одного слоя или его структуры минимально влияло на соседние слои.
Данные слоев связаны: как объекты слоев связаны напрямую друг с другом, так и имеются некоторые сквозные аналитики. На верхнем уровне – это акт, на нижнем, детальном уровне – заказ.
Давайте для упрощения понимания предположим, что заказ – это заказ на доставку посылки. Хотя в целом это, конечно же, не так. Посмотрим каждый слой данных.
Детальное описание слоев данных: от физических событий до актов
Физические события – это данные о событиях по заказу от других модулей, которые ведут оперативный учет.
К примеру, есть модуль «Склад», который зафиксировал выдачу посылки на ПВЗ. В момент этого события он выкладывает объект на шину, мы его считываем, сериализуем и сохраняем в независимый регистр сведений.
Для каждого вида события, для каждого типа события у нас есть свой независимый регистр сведений. Заказ – обязательная аналитика для всех физических событий.
На уровне логики системы зашито, что при наступлении некоторых физических событий есть шанс, что наступили некие финансовые события. Поэтому при фиксации физического события мы создаем задания на расчет финансовых событий.
Финансовые события формируются на основании физических событий плюс бизнес-правил работы компании. По сути, финансовые события – это перечень бизнес-событий по каждому заказу.
К примеру, в бизнес-логике есть понятие доставки груза. Это финансовое событие появляется в тот момент, когда были зафиксированы одновременно два физических события: событие от модуля заказа – прием заказа, и событие от модуля доставки – вручение этого заказа.
Финансовые события хранятся, в отличие от физических, в унифицированном виде, в единой таблице. У них множество типов, свои реквизиты, но таблица и структура хранения одна.
Изменчивость физических событий и бизнес-правил не приводит к необходимости изменения самих финансовых событий. Они изолированы друг от друга.
Финансовые события ретроспективны. Когда что-то изменяется, мы сторнируем старое событие и генерируем сторно-событие и новое финансовое событие с учетом изменившихся обстоятельств.
Важное про биллинг, что нужно знать: биллинг никогда не изменяет накопленные данные. Все данные, которые были биллингом порождены, остаются в неизменном виде навсегда. Биллинг только порождает новые данные.
Появление нового финансового события может быть источником появления расценок этого события. Мы генерируем задание на расценку и его обрабатываем.
Расценки. Слой расценок – это наша мысль о том, сколько стоит финансовое событие в деньгах и в каком акте это начисление должно быть отражено.
Расценки также ретроспективны, как финансовые события, и формируются на основании финансовых событий и пласта договорных отношений, законов, норм и правил, которые соответствуют территории ведения бизнеса.
К примеру, по заказу было зафиксировано финансовое событие SMS-информирования грузополучателя. Заказ был отправлен по договору. Из этого договора мы выясняем, что для грузоотправителя, для клиента СДЭК, это стоило 3 ?. При этом такие услуги мы должны фиксировать в отдельном акте на ежемесячной основе, отдельно от услуг доставки.
Обратите внимание: финансовые события – это интерпретация физических событий плюс бизнес-правила работы компании. Расценки – это интерпретация финансовых событий плюс пласт договорных отношений и законов. Это два совершенно разных слоя информации, которые формируются по разным правилам. Сами правила меняются различным темпом и в принципе независимы.
Расценки связаны с финансовыми событиями. При сторнировании финансового события сторнируются его расценки. При появлении новой расценки мы формируем задание на формирование актов по этим расценкам.
Слой актов и их детализации – это, по сути, агрегированная информация по расценкам и только по ним. Мы берем расценки и суммируем их в разрезе номенклатуры и акта, получаем классические объекты 1С, объекты учета. Это документы 1С.
Именно эти данные видит пользователь на фронте. И именно эти данные мы выгружаем нашим потребителям: в регламентированный учет, для системы и так далее.
В итоге, пройдя по слоям данных, мы можем получить максимально детальную информацию. От суммы акта мы можем перейти к позаказной детализации. От позаказной детализации – к расценкам и финансовым событиям по этому заказу. А уже от них – к физическим событиям и вплоть до модуля-источника, который ведет учет оперативной деятельности на земле.
Давайте посмотрим примитивный процесс биллинга.
В январе модуль заказа зафиксировал прием заказа. Это физическое событие не стало основанием финансового события, которое мы расцениваем.
В феврале модуль доставки зафиксировал вручение заказа. Совокупность двух этих физических событий стала основанием для появления финансового события – доставки груза. По договору это финансовое событие расценилось в первичный акт февраля, в номенклатуру комплекса курьерских услуг.
В марте модуль заказа по каким-то причинам изменил обстоятельства приема заказа. Это повлекло за собой сторнирование события доставки груза в старом виде и появление нового финансового события с учетом изменившихся обстоятельств.
Оба этих события были расценены, но уже в корректировочный акт марта, потому что первичный акт к этому моменту не мог вместить эти расценки: он уже был выставлен и закрыт.
Виды данных биллинга
Мы с вами обзорно посмотрели на слои данных. Давайте теперь разберемся, как мы эти данные храним в системе.
С точки зрения хранения данные биллинга разделяются на три вида.
Временный кэш – это данные физических событий. Их больше всего. Однако мастер-системой этих данных является не биллинг, а другие модули. А значит, мы эти данные можем хранить не полностью. Мы их можем терять.
Первичные данные биллинга – это расценки и финансовые события. Это единственно ценное, что есть в биллинге. Именно из этих объектов мы можем получить любые другие агрегаты для показа на фронте или для других систем. Мы их не можем терять, поэтому должны хранить надежно и экономно. Их много.
Интерфейсные данные – это человекочитаемые данные, данные фронта. А значит, они должны быть такими, чтобы мы могли их быстро и удобно показать.
Давайте пройдемся по каждому виду данных.
Хранение временных данных
Временные данные – это физические события. Мы их храним только для свежих заказов. У каждого заказа есть неизменная дата создания, и мы из системы регулярно подчищаем, удаляем данные о физических событиях старых заказов.
Мы вполне можем это себе позволить. В случае необходимости расчета финансовых событий по старому заказу мы можем по API синхронно обратиться в модули-источники и получить недостающие данные.
Обращение по API долгое, тем более синхронное. Но частота обращения минимальна, потому что стереотипно биллинг работает с актуальными заказами.
Таким образом, на самом деле проблемы хранения данных временного кэша нет. Он на то и временный. Мы храним столько данных временного кэша, сколько можем себе позволить комфортно хранить. Лимитирующим фактором является только глубина этого кэша. Чем короче кэш, тем чаще мы ходим по API в соседние модули.
Хранение первичных данных
Финансовые события и расценки – это первичные данные биллинга. Их очень много. Их нельзя терять. Мы являемся мастер-системой этих данных. Поэтому хранить мы их должны максимально надежно и экономно.
Храним мы их в независимых регистрах сведений. Реквизитный состав этих регистров сведений имеет максимально примитивные типы, а сами эти регистры имеют минимальную индексную нагрузку.
Первичные данные мы партиционируем. Причем, обратите внимание, не средствами СУБД, а на уровне метаданных 1С.
Для каждого месяца у нас есть отдельный регистр для финансовых событий и для расценок. Итого – 24 регистра на год.
При таком подходе каждый из месячных регистров в среднем содержит от 600 до 800 миллионов строк. Это приемлемый объем, который позволяет нам избежать наличия в системе таблиц-гигантов.
Хранение интерфейсных данных
Интерфейсные данные мы храним в классических объектах 1С. Именно эти объекты видит пользователь на фронте. Именно эти данные мы поставляем внешним источникам. И мы храним их так, чтобы быстро отобразить.
Интерфейсным данным свойственна некая неоптимальность хранения. Во-первых, там очень высокая индексная нагрузка. Там есть дублирование информации одних объектов в других. Все это сделано в угоду быстродействию фронта. При этом по интерфейсным данным настроено RLS для разграничения прав пользователей наших четырех тысяч организаций.
Важная особенность интерфейсных данных в том, что мы их можем легко обрезать по периоду. Потому что в любой момент по запросу можем полностью, без потерь восстановить их из расценок. Они являются прямым агрегатом.
Таким образом, на самом деле мы решили проблему хранения интерфейсных данных. Обрезка избавила нас от гигантских объемов, а некая неоптимальность хранения сделала наш фронт отзывчивым.
Холодные и горячие данные
Важная особенность. Ранее мы говорили о том, что мы партиционируем первичные данные по месяцам на уровне отдельных регистров в 1С. Это позволяет нам избежать наличия таблиц-гигантов, но база пухнет все равно. А большая база – это большие проблемы.
Чтобы уйти от проблемы большой базы данных, мы используем механику охлаждения.
Наш продуктивный контур на самом деле – это не одна база данных. Это две независимые базы данных с абсолютно идентичной структурой метаданных. Это база горячих данных и база холодных данных.
База горячих данных лежит на производительном железе и быстрых дисках. База холодных данных лежит на медленных дешевых дисках.
Все расчеты, интерфейсные данные и пользователи работают только в горячей базе. База холодных данных предназначена для хранения партиций старых данных. По мере старения данных мы выгружаем их из горячей базы в холодную целыми партициями.
В случае же, если нам необходимо прочитать данные старых заказов, мы в момент расчета получаем эти данные в горячую базу из холодной синхронно по API. Это не быстро. Но опять-таки, стереотипно биллинг преимущественно работает с актуальными заказами. Частота обращения, в общем-то, минимальна.
Архитектура данных – PROFIT
Подведем итоги. Чего мы добились, выстроив архитектуру данных подобным образом?
Слои данных позволили нам изолировать объекты друг от друга. Изменчивость данных одного слоя минимальным образом аффектит другие слои.
Интерфейсные данные позволили нам за счет неоптимальности хранения получить быстрый фронт. Мы можем их пересобирать, переформатировать на лету, обрезать.
Партиционирование избавило нас от таблиц-гигантов, связанных с этим длительных реструктуризаций и проблем с СУБД. Но при этом партиционирование на уровне метаданных дало нам еще один огромный плюс: мы можем реструктурировать их структуру хранения по мере необходимости.
То есть если, к примеру, сегодня возникает потребность изменить структуру хранения первичных данных, мы меняем ее с партиции этого месяца. Старые данные остаются неизменными, нам нет необходимости все это реструктурировать.
Таким образом, огромный объем накопленных исторических данных никоим образом не лимитирует наше текущее развитие.
Охлаждение сделало нашу горячую базу быстрой, комфортной. При этом мы очень дешево храним исторические данные, и они доступны нам в сериализованном виде.
Все это в целом сделало нашу систему масштабируемой. Мы готовы к двукратному росту данных и бизнеса без потери производительности, без ухода в деградацию.
Архитектура данных – это ключ к успеху. Инструменты вторичны, причем инструменты в широком смысле этого слова. Но пару слов об инструментах именно 1С, которые мы использовали, все-таки стоит сказать.
Многопоточная обработка
Суть процесса биллинга на самом деле – это порождение данных одного слоя при изменении данных другого слоя. Мы формируем задания на это, и эти задания обрабатываем многопоточным конвейером.
Мы используем конфигурацию «Пакеты данных». Это моя давняя разработка. Суть работы проста. Наш регистр заданий – это, по сути, стек. Регламентное задание раз в несколько секунд выбирает некий объем заданий из этого стека, нарезает его на порции и складывает их в пакеты.
Пакет данных – это, по сути, порция многопоточной обработки. Далее многопоточный конвейер подхватывает эти пакеты, обрабатывает их во множество потоков, независимо друг от друга. В конце обработки каждого пакета задания удаляются из строк. И так по кругу.
Пакеты данных – это ключевой инструмент, который мы используем в биллинге. Именно пакеты данных позволили нам добиться той производительности, которую система умеет.
Мы реализовали благодаря пакетам данных биллинг только платформенными инструментами. Мы вообще, в принципе, никогда не лезем на СУБД. Только платформенные инструменты и ничего более.
Пакеты данных – это главный инструмент. Это основа.
Асинхронные взаимодействия
Биллинг очень активно взаимодействует с шиной. Порядка миллиарда событий ежемесячно вычитываются примерно из сорока очередей RabbitMQ.
Для подключения к RabbitMQ мы используем компоненту от «Серебряной пули», однако обвязка внутри 1С у нас своя.
Из интересного: мы реализовали адаптивную настройку количества консьюмеров в зависимости от того, сколько в данный момент находится событий в очереди.
Также мы очень сильно заморочились над производительностью. Наша оснастка складывает полученные с шины события сразу же в пакеты данных – по сути, в порции для многопоточной обработки.
Их подхватывает конвейер, и таким образом мы получили непрерывную, отказоустойчивую обработку и сериализацию физических событий, а также формирование заданий на финансовые события.
Наблюдаемость
Наблюдаем наш продуктивный контур мы в Grafana. У нас организована классическая связка «1С – Prometheus – Grafana». Настроено множество графиков и алертов.
Из интересного – способ оценки, насколько база хорошо себя чувствует. Как вы помните, у нас есть регистр заданий, которые порождаются в момент изменения данных слоев. Информацию по этим регистрам мы вывели на графики и алерты.
У нас есть информация об общем количестве заданий в текущий момент времени и среднем времени ожидания обработки каждого задания. Такую пару графиков вы видите на изображении.
Если среднее время ожидания обработки задания менее минуты, значит, с базой все хорошо. При этом количество заданий в моменте на самом деле может скакать от нуля до миллионов.
Бывает такое, что база молотит как не в себя, и сложно понять, хорошо она себя чувствует или нет. А эта метрика нам очень четко дает понять: нагрузка есть, но мы справляемся, и с каким запасом мы справляемся.
Очень информативные графики.
Web-клиент 1С inFrame
На самом деле 1С уже давным-давно выведена на веб-фронт ЭК5 в inFrame. 1С и веб-клиенты открываются наряду с другими вкладками на веб-фронте.
Чтобы все это работало, мы настроили единую авторизацию на базе SSO KeyCloack нашей компании. Авторизация 1С происходит токеном доступа.
То есть когда пользователь в родительском окне на сайте ЭК5 нажимает на вкладку 1С, родительское окно открывает фрейм и формирует ссылку на подключение с этим токеном. Этот токен проверяется на сервере 1С. Таким образом происходит авторизация.
Мы настроили кросс-кликабельные ссылки из 1С в другие модули ЭК5. Как это выглядит? В момент, когда пользователь нажимает на гиперссылку объекта, мастер-системой которого является другой модуль, мы из веб-клиента обращаемся к родительскому окну, вызываем некую функцию, куда передаем идентификатор этого объекта и сопутствующую информацию.
Родительское окно обрабатывает ее и рядышком открывает соседнюю вкладку, но уже с модулем ЭК5, который спозиционирован на интересующем пользователя объекте.
Таким образом мы реализовали как переходы из 1С в Java-модули, так и наоборот.
Интерфейс 1С
Изначально мы планировали запустить биллинг на интерфейсе «Такси». Но, честно говоря, выглядел он архаично и не очень красиво.
В конце 2025 года фирма 1С выпустила платформу 8.5, в которой был представлен новый интерфейс. Он нам визуально очень понравился, и мы рискнули вывести биллинг на продуктив на тестовой платформе, причем на одной из ранних версий.
На изображении вы сейчас видите интерфейс основного окна приложения. Здесь есть вкладки других модулей, рядом – 1С. Выглядит он легко и довольно современно.
Мы используем режим диалоговых окон в новом интерфейсе. Это концентрирует пользователя на выполняемой задаче, плюс выглядит очень похоже на поведение других модулей ЭК5 на Java.
На изображении представлен интерфейс окна просмотра акта. Посмотрите: здесь он виден как регламентная сущность, то есть видны дата, номер, номенклатура, суммы, ставки, НДС – регламентная информация. Но ниже уже есть переход на слой детализации этого акта по заказной расшифровке.
Заключение
Давайте подведем некоторые итоги.
Архитектура данных – это ключ к успеху. Инструменты вторичны. Инструменты в широком смысле этого слова: как инструменты, используемые в самой платформе 1С, так и сама платформа – это, по сути, инструмент.
Представленный в статье способ организации высоконагруженных систем – это общие принципы построения высоконагруженных систем. И свойственны они не только и не столько платформе 1С.
Надо понимать: как вы помните, старый модуль был реализован на Java. То, что имеют Java-разработчики и другие стеки, в принципе, даже нет смысла сравнивать с самой платформой 1С. Но тем не менее 1С может быть конкурентной, если ее правильно уметь готовить.
В целом же можно сделать вывод, что 1С в принципе пригодна для построения такого рода систем. Однако есть множество подводных камней, нюансов, которые надо учитывать.
При желании на самом деле все возможно. И более того, с определенной долей уверенности можно утверждать, что относительно реализации на некоторых других стеках реализация на 1С может быть быстрее и дешевле.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.