1С BACKEND ДЛЯ WEB? ДА ВЫ СМЕЕТЕСЬ.

Заголовок провокационный, но вопрос я слышу регулярно: можно ли использовать 1С как backend для веба, а не только как учётную систему за забором. Короткого честного ответа тут нет — «можно» и «нет» одинаково неточны. Ниже — разбор с цифрами: что показывает нагрузочный тест HTTP-сервисов 1С, где 1С веб сервер реально упирается в потолок, а где неожиданно не уступает Node.js, и дерево решений, по которому я сам определяю, тянет 1С backend для конкретного проекта или нет.

Сразу оговорка по методике: тест ниже — простой, локальный, с тестовым HTTP-сервисом, который просто отдаёт статичный JSON без обращения к бизнес-логике, документам и блокировкам. Это не production sizing, а способ понять порядок величин и найти, где именно упирается 1С веб сервер — в саму платформу или в конкретный web-сервер перед ней.

Что тестировалось

Инструмент — Apache Benchmark (ab), он входит в стандартную поставку Apache. Все тесты — на одной локальной машине; на реальном железе и с реальным сетевым каналом абсолютные цифры будут другими, но соотношение между вариантами обычно сохраняется.

Тест 1. Обычный сайт на Apache

Простая локальная html-страница без PHP и прочей динамики.

Команда:
ab -c 100 -n 10000 http://post24/

100 конкурентных запросов, 10 000 запросов всего. Результат — максимум около 260 параллельных запросов, дальше сервер начинал захлёбываться.

Тест 2. HTTP-сервис 1С поверх Apache

HTTP-сервис 1С, тоже простой — на GET отдаёт JSON без обращения к базе.

Команда:
ab -c 100 -n 10000 http://localhost/httpsrv/hs/ex/product

Результат — те же примерно 260 параллельных запросов. Важный момент: цифра совпала с обычным статичным сайтом на том же Apache. Это не характеристика 1С — это потолок конкретной конфигурации Apache «из коробки» на Windows. Сам backend для 1С в лице HTTP-сервиса тут ни при чём, узкое место — web-сервер перед ним.

Тест 3. HTTP-сервис 1С, автономный сервер

Автономный сервер 1С не идёт через Apache/IIS как модуль расширения, а поднимает собственный HTTP-стек и обслуживает запросы напрямую.

Команда запуска:
“C:\Program Files\1cv8\8.3.16.1148\bin\ibsrv” –db-path=”Z:\1S\03 Обучение\HTTPTEST\Server” –name=serv1 –address=10.10.1.10

Тест:
ab -c 100 -n 10000 http://10.10.1.10:8314/hs/ex/product

Автономный сервер выдержал 15 000 параллельных запросов и обработал 30 000 GET-запросов за тест — в разы больше, чем связка с Apache в тесте 2.

Тест 4. HTTP-сервис на Node.js

Для сравнения — минимальный HTTP-сервис на Node.js, порт 3000.

Запуск:
node z:\www\testnode\test.js

Тест:
ab -c 100 -n 10000 http://localhost:3000/

var http = require("http");

http.createServer(function(request, response){

var body = []; // объявление массива

body[0] = {
UUID: "86fabe85-8300-11ea-847a-3085a93c8c97",
Name: "Товар 1"
}

body[1] = {
UUID: "86fabe85-8300-11ea-847a-3085a93c8c97",
Name: "Товар 2"
}

body[2] = {
UUID: "86fabe85-8300-11ea-847a-3085a93c8c97",
Name: "Товар 3"
}

body[3] = {
UUID: "86fabe85-8300-11ea-847a-3085a93c8c97",
Name: "Товар 4"
}

// Устанавливаем заголовки
response.setHeader('Content-Type', 'application/json');
response.end(JSON.stringify(body));

}).listen(3000);

Результат — тоже около 15 000 параллельных соединений и 30 000 запросов, то есть практически идентично автономному серверу 1С. Скорее всего, дальше упирались уже ограничения самой операционной системы, а не платформ.

Что эти цифры значат на самом деле

Формальный вывод «автономный сервер 1С не уступает Node.js» — правда, но опасно неполная. Есть три вещи, которые тест не показывает, а на практике решают всё:

  • Тестовый HTTP-сервис ничего не делает. Он просто возвращает статичный JSON — ни чтения из базы, ни записи документа, ни управляемых блокировок. Как только HTTP-сервис 1С начинает реально работать с бизнес-логикой — проводить документ, писать в регистр, брать управляемую блокировку — параллелизм резко падает: 1С:Предприятие сериализует конкурентный доступ к одним и тем же данным, и это архитектурное свойство платформы, а не настройка, которую можно подкрутить.
  • Лицензирование считается по-другому. У Node.js или Django рост числа воркеров/процессов упирается только в железо. У 1С рост числа одновременных клиентских подключений упирается в клиентские лицензии — это не бесплатный ресурс, и при проектировании backend для 1С это нужно закладывать в расчёт стоимости так же, как ядра CPU.
  • Нет по-настоящему асинхронного event loop. Модель 1С — процессы-воркеры кластера, а не событийный цикл, как у Node.js. Для равномерной синхронной нагрузки «запрос-ответ» это не проблема, но под WebSocket, SSE или тысячи вялых долгоживущих соединений 1С веб сервер не подходит по конструкции, а не потому что «плохо настроен».

Дерево решений: когда 1С как backend имеет смысл

Вместо универсального «да» или «нет» — конкретные условия. Если у вас совпадает большинство пунктов в левой колонке каждого блока — 1С HTTP-сервис как backend жизнеспособен. Если больше пунктов справа — нужен отдельный backend-слой.

  • Профиль нагрузки.
    • Десятки-сотни, не тысячи, одновременных клиентов, в основном чтение → 1С справляется.
    • Тысячи одновременных запросов в секунду, много записи и конкурентных блокировок → нужен отдельный backend (Django/FastAPI/Node) перед 1С.
  • Состав команды.
    • Только 1С-разработчики, нет отдельной backend/frontend-команды → HTTP-сервис 1С снижает time-to-market и не плодит вторую копию бизнес-логики на другом языке.
    • Есть выделенная команда веб-разработки → логичнее вынести web-слой отдельно, а 1С оставить системой учёта, а не веб-сервером.
  • Тип интеграции.
    • Мобильное приложение синхронизирует остатки и заказы с периодичностью в минуты → HTTP-сервис 1С справляется без дублирования инфраструктуры.
    • Публичный сайт или SPA с непредсказуемым, в том числе рекламным, трафиком → перед 1С нужен буфер: кэш, очередь, отдельный backend, принимающий пиковую нагрузку на себя.
  • Протокол и характер соединений.
    • Синхронный REST запрос-ответ на нечастых событиях → 1С справляется.
    • WebSocket, SSE, push в реальном времени, тысячи долгоживущих соединений → нужен слой на Node.js/FastAPI, 1С тут не архитектурно предназначена для такой роли.
  • Предсказуемость нагрузки.
    • Ровная, прогнозируемая нагрузка без резких всплесков → 1С HTTP-сервис как backend приемлем.
    • Спайки трафика (рассылка, распродажа, вирусный пост) без возможности заранее подготовиться → нужна очередь и отдельный сервис перед 1С, чтобы не положить кластер сериализацией блокировок.

Гибридная архитектура: 1С плюс отдельный backend

На практике выбор редко стоит как «1С или Node.js». Рабочий паттерн для проектов с реальным веб-трафиком — гибрид: 1С остаётся источником истины по бизнес-логике и данным, а перед ней стоит тонкий сервис на Python или Node.js, который берёт на себя веб-специфику — кэширование, авторизацию, rate-limiting, WebSocket — и обращается к HTTP-сервисам 1С уже во внутренней сети, без публичного трафика напрямую на кластер.

Разбор именно такого паттерна — на примере обёртки бизнес-логики 1С в отдельный микросервис — есть в статье «Python 1C. Микросервис на FastAPI».

Если хотите не просто прочитать про паттерн, а собрать такую архитектуру руками: на курсе «B2B-сервис для 1С» на Django разбирается связка 1С и полноценного backend на Django с очередями и веб-интерфейсом, на курсе «NuxtJS + 1С» — фронтенд поверх этой архитектуры. Если ещё не работали с HTTP-сервисами 1С вообще — стартовая точка это курс «HTTP в 1С для начинающих», без него дерево решений выше будет чисто теоретическим.

Итог

1. Apache «из коробки» на Windows — не показатель производительности ни обычного сайта, ни HTTP-сервиса 1С поверх него: у обоих одинаковый потолок в районе 260 параллельных запросов, и упирается именно web-сервер, а не платформа 1С.

2. Автономный сервер 1С в этом тесте выдержал нагрузку на уровне простого HTTP-сервиса на Node.js — 15 000 параллельных соединений. Но это тест на статичный ответ; с реальной бизнес-логикой, документами и блокировками параллелизм 1С упадёт заметно раньше, чем у Node.js или Django.

3. 1С backend имеет смысл как integration point для внутренних и мобильных сценариев с предсказуемой, не запредельной нагрузкой, когда команда и так работает в 1С. Как публичный web backend с непредсказуемым трафиком и требованиями к реальному времени — нет, для этого нужен отдельный backend-слой перед 1С, а не вместо него.

Если вы уже трогали HTTP-сервисы 1С и есть свой опыт нагрузочного тестирования на реальном железе — пишите в комментариях, будет интересно сравнить цифры.