Архитектура · 13 мин
Как LEM обслуживает команду: индексация, воркеры и свежесть Git
Два корпуса, отдельные очереди и воркеры, работа с Git и рост от одной обработки до нескольких команд.
LEM может помогать с одной обработкой 1С, а может обслуживать команду, которая одновременно развивает несколько конфигураций и версий продукта. В обоих случаях агенту нужны применимые знания и точное состояние кода. Для этого в LEM существуют две самостоятельные подсистемы: библиотечный корпус и корпус проектов. Их можно запустить вместе на одном сервере, а при росте нагрузки расширять по отдельности.
Библиотечный корпус и проекты решают разные задачи
Библиотечный корпус хранит версионированные источники, которыми пользуются разные задачи и команды: стандарты разработки, документацию платформы и БСП, внутренние библиотеки, контракты интеграций и подготовленные справочные материалы. Агент обращается к ним не только при большой доработке: он может много раз за день уточнять сигнатуры, ограничения метода или требования конкретной версии. Поэтому для библиотек важны собственная индексация, поиск с учётом источника и версии и достаточная пропускная способность чтения для множества агентов.
Корпус проекта отвечает на другие вопросы: что находится в конкретной конфигурации, расширении или обработке, какие модули и объекты связаны, что изменилось между версиями и на какой снимок кода опирается ответ. Построение проектного индекса может быть тяжёлой длительной работой; запрос на поиск и чтение связей должен оставаться доступным независимо от неё. Проектные снимки, граф и анализ изменений имеют собственный жизненный цикл и проверку свежести.
Это разные наборы данных, правила выдачи и нагрузки, но для пользователя они складываются в одну картину. Например, при правке общего модуля LEM помогает найти связанные места в проекте и одновременно проверить, допускает ли нужная версия БСП выбранный вызов. Права на библиотеки и проекты проверяются отдельно: команда видит только разрешённые ей ресурсы даже в общем развёртывании LEM.
Подготовленный проектный индекс служит и основой для проверок изменения: сигнатуры, признаки экспорта и связи уже структурированы, а типы для ограниченного кандидата выводятся с опорой на эти сведения. Библиотечный индекс отдельно помогает подобрать возможную стандартную замену самописной реализации. Так разделение корпусов сокращает повторную работу на пути от поиска кандидата до проверки конкретной правки и сохраняет версии источников.
Как разделены чтение и индексация
MCP-сервер принимает запросы агентов и возвращает поиск, статусы и доказательства. Короткое чтение не должно ждать завершения долгого импорта библиотеки или индексации конфигурации. Поэтому длительные операции выполняются через сохраняемые очереди и отдельные воркеры: у импорта библиотек своя очередь индексирования, у проектов — своя; клиент получает идентификатор операции и видит её результат. Незавершённую работу можно восстановить после перезапуска по правилам соответствующего контура.
Для чтения тоже предусмотрено разделение. Библиотечный поиск может обслуживать отдельный пул процессов со своей ёмкостью и ожиданием запросов. Поиск, граф и точные факты уже индексированного проекта можно вынести в другой, независимо настраиваемый пул. Число читателей и индексирующих воркеров в каждом контуре меняется по потребности: частые запросы к стандартам не требуют добавлять тяжёлые проектные индексаторы, а обновление большой конфигурации не должно занимать все библиотечные слоты.
Длительный анализ разницы и pull request тоже имеет отдельный управляемый цикл: его можно запустить, узнать состояние и получить результат, не удерживая один интерактивный запрос до конца проверки. Проектные и библиотечные снимки сохраняются раздельно, поэтому обновление одного корпуса не подменяет версию другого.
LEM не требует такой разнесённой схемы с первого дня. Для одной обработки или небольшого числа пользователей подойдёт объединённое развёртывание, в котором сервис выполняет задачи на одном узле. Когда появляются несколько разработчиков, множество агентов, частые изменения или крупные отраслевые и ERP-конфигурации, чтение и индексацию можно распределить между процессами и выделить каждому контуру подходящие ресурсы.
Откуда берётся код и как помогает Git
Внешний Git-сервер не обязателен для начала работы. LEM может принять бинарный артефакт 1С — конфигурацию, расширение, обработку или отчёт — и вести его версии во внутреннем управляемом Git-репозитории. Успешный импорт фиксирует неизменяемый тег релиза и запускает подготовку индекса. Это локальное хранилище версий LEM, а не требование поднять отдельный Git-сервер.
Если команда уже работает в Git, в том числе из 1C:EDT или через собственный Git-сервер, LEM можно подключить к её репозиторию. Он читает управляемый снимок проекта и связывает ответ с конкретным commit. Для импорта бинарных релизов можно указать разрешённый удалённый репозиторий: LEM сохраняет исходный артефакт и подготовленные файлы как версию с тегом. Доступ к Git задаётся отдельно, учётные данные хранятся в защищённом контуре, а сам факт наличия Git-репозитория не даёт пользователю прав читать чужой индекс LEM.
Для подключённого проекта предусмотрено автоматическое обновление после изменения main: отдельный reconciler обнаруживает новый commit, запускает обновление и сверяет конечный снимок. Этот режим включают и проверяют для конкретного развёртывания; наличие механизма в продукте не означает, что он уже активен на каждом сервере. Импорт нового релиза с тегом и слежение за изменениями main — разные процессы, у каждого свой статус завершения.
Что именно означает «индекс свежий»
Ответ по проекту должен быть привязан к project ID, commit и снимку индекса. Если main продвинулся, прежний снимок нельзя выдавать за новое состояние кода. Поэтому перед анализом изменения агент сверяет базовый и целевой commit, готовность нужного индекса и полноту анализа. Если обновление ещё идёт или завершилось ошибкой, это видно в статусе.
Такая проверка нужна и для обычного вопроса «где используется этот метод», и для разбора pull request. Сам анализ разницы, временных изменений агента и доказательств подробно разобран в отдельном материале; здесь важно, что он опирается на определённые снимки, а не на неопределённое «последнее состояние проекта».
Веб-консоль и наблюдаемость
Для LEM реализована отдельно развёртываемая веб-консоль. Там, где она подключена, пользователь видит доступные ему проекты и версии библиотек, выполняет поиск, просматривает граф, статусы и диагностические сведения. Монитор показывает доступные показатели нагрузки сервера и воркеров, очередей и задержек; если источник телеметрии не подключён или данные устарели, консоль обозначает это явно. По этим сведениям команда может понять, где требуется расширить ёмкость чтения или индексации.
Консоль позволяет запускать предусмотренные её интерфейсом действия и управлять доступными настройками наблюдаемости. Остальные административные операции выполняются через защищённый интерфейс LEM. Основной сервис проверяет права при каждом запросе, независимо от того, пришёл он из консоли или от агента.
От одной обработки до нескольких тяжёлых проектов
Один разработчик может начать с объединённого сервиса и нужной ему библиотеки или обработки. По мере роста команды LEM позволяет отдельно увеличивать число одновременных библиотечных запросов, проектных запросов и длительных операций индексирования. Это даёт путь к развёртыванию для нескольких команд и крупных конфигураций без переноса всех пользователей в отдельный экземпляр на каждый проект.
Конкретная конфигурация серверов и сервисов зависит от числа пользователей и агентов, размеров библиотек и проектов, частоты обновлений и желаемого времени ответа. Важная возможность архитектуры — добавлять ресурсы именно в тот контур, где выросла нагрузка, сохраняя версии, права и наблюдаемость. Запросить пилот LEM.