Как устроена платформа 1С:Предприятие и из каких частей она собрана

«1С» на рабочем столе выглядит как одна программа, но это не так. 1С:Предприятие — это платформа (движок) и прикладное решение (конфигурация) поверх неё. В клиент-серверном варианте добавляется третий уровень, и вся работа распределяется по трём звеньям: клиент, сервер приложений 1С и система управления базами данных.

Эта трёхуровневая архитектура объясняет большинство практических вопросов: где физически лежат данные, почему при одновременной работе возникают блокировки, что именно обновляется при смене релиза и зачем вообще нужен отдельный сервер. Разберём каждый компонент по порядку — от клиента, с которым сидит пользователь, до хранилища данных.

Три уровня платформы и как они связаны

В платформе 8.3 есть два варианта развёртывания, и от выбора зависит вся схема.

Файловый режим. Вся база — это один файл 1Cv8.1CD в каталоге на диске или в сетевой папке. Клиент сам читает и пишет этот файл, отдельного сервера нет. Режим простой, но при нескольких пользователях файл по сети становится узким местом.

Клиент-серверный режим. Между пользователем и данными встаёт сервер приложений 1С (кластер серверов ), а сами данные хранит промышленная СУБД. Получается классическая трёхуровневая схема:

• 🖥️ уровень представления — клиентское приложение на компьютере пользователя;
• ⚙️ уровень логики — кластер серверов 1С, где выполняется прикладной код и запросы;
• 🗄️ уровень данных — СУБД (PostgreSQL, MS SQL Server и другие), которая физически держит таблицы.

Смысл разделения в том, что тяжёлые вычисления и работа с данными уходят на сервер, а по сети между клиентом и сервером передаётся минимум — только то, что нужно показать на экране. Поэтому клиент-серверный вариант держит десятки и сотни одновременных сеансов там, где файловая база уже встала бы.

Клиентские приложения: тонкий, толстый и веб-клиент

Клиент — это то, что запускает пользователь. В 8.3 их три, и выбирает платформа чаще сама.

1. Тонкий клиент. Основной режим для типовых конфигураций. Вся логика выполняется на сервере, клиент только отображает формы. По сети идёт мало данных, поэтому тонкий клиент нормально работает даже на медленном канале.
2. Толстый клиент. Часть кода выполняется на стороне пользователя. Нужен в основном при разработке и для некоторых старых режимов. Для повседневной работы в типовых решениях почти не используется.
3. Веб-клиент. Запускается в браузере без установки, достаточно опубликовать базу на веб-сервере (Apache или IIS). Удобно для доступа снаружи и с чужих компьютеров.

Запускается всё это исполняемым файлом 1cv8.exe (или 1cv8c.exe для тонкого клиента ). Список баз и параметры запуска хранятся в файле ibases.v8i.

Важно не путать клиент и конфигурацию. Тонкий и толстый клиент — это способ запуска одной и той же базы, а не разные программы. Одну базу можно открыть и тонким клиентом в режиме 1С:Предприятие, и Конфигуратором для изменения структуры.

Кластер серверов 1С: из чего состоит и как общается с клиентом

Сервер приложений в терминах 1С — это кластер серверов. Даже на одной машине это именно кластер, просто из одного рабочего сервера. Внутри работают несколько служебных процессов.

• Агент сервера (ragent) — центральный процесс, который держит реестр кластеров и принимает входящие подключения. Слушает порт 1540.
• Менеджер кластера (rmngr) — управляет сеансами, соединениями и распределением нагрузки. Порт 1541.
• Рабочие процессы (rphost) — здесь и выполняется прикладной код, запросы, фоновые задания. Им выделяется диапазон портов, который задаётся в свойствах рабочего сервера (по умолчанию 1560–1591).

Как клиент доходит до данных: сначала он обращается к агенту на порт 1540, тот передаёт его менеджеру кластера (1541), а менеджер назначает рабочий процесс из диапазона рабочего сервера. Консоль администрирования идёт через тот же агент.

Управляют кластером через оснастку «Администрирование серверов 1С Предприятия» либо утилитой командной строки rac (например, rac cluster list, rac session list). Если не уверены в подкоманде — лучше свериться со справкой rac help, чем гадать параметры.

СУБД: где физически хранятся данные

В клиент-серверном режиме платформа 1С сама таблицы не хранит — она отдаёт это промышленной СУБД. Платформа 8.3 официально работает с несколькими:

Важный момент: напрямую лезть в таблицы СУБД и править их руками нельзя. Платформа сама формирует структуру таблиц из метаданных конфигурации, и ручное вмешательство в базу на уровне SQL ломает целостность. Все изменения вносятся только через 1С — через документы, обработки или Конфигуратор.

В файловом же режиме СУБД как отдельного продукта нет вообще: роль хранилища выполняет файл 1Cv8.1CD, а движок базы данных встроен в саму платформу.

Это различие заметно и при резервном копировании. Файловую базу можно сохранить, просто скопировав каталог с 1Cv8.1CD (когда в базе никто не работает ). Клиент-серверную так не скопируешь — резервная копия делается либо средствами самой СУБД, либо выгрузкой в файл .dt из Конфигуратора. Копировать «на горячую» файлы работающей СУБД из-под Windows нельзя: получите битую копию.

Блокировки и транзакции: как платформа защищает данные

Когда с базой работают несколько человек, платформа должна не дать двум сеансам одновременно испортить одни и те же данные. За это отвечают два механизма.

Транзакции. Любое проведение документа или запись в регистр идёт в транзакции: либо все изменения применяются целиком, либо не применяется ничего. Оборванная на середине операция не оставит базу в «половинчатом» состоянии.

Управляемые блокировки. Это блокировки на уровне самой 1С, а не только СУБД. В управляемом режиме платформа блокирует ровно те данные, которые нужны операции (например, остатки конкретного товара на складе), и отпускает их после завершения транзакции. Другие пользователи в это время работают с остальными данными свободно.

Отсюда растут знакомые сообщения вроде Конфликт блокировок при выполнении транзакции. Обычно это не ошибка, а штатная ситуация: два сеанса одновременно обратились к одному ресурсу, и один ждёт освобождения. Лечится чаще не «перезагрузкой сервера», а разбором, какая операция держит блокировку дольше положенного.

Конфигурация и прикладные объекты: из чего собрано решение

Платформа сама по себе ничего не умеет про бухгалтерию или зарплату — она даёт только конструктор. Готовый учёт описан в конфигурации: «Бухгалтерия предприятия», «Зарплата и управление персоналом», «Управление торговлей» и другие.

Конфигурация собрана из прикладных объектов — это кирпичики, из которых платформа сама строит таблицы в СУБД и формы на экране:

• 📒 Справочники — списки (номенклатура, контрагенты, сотрудники);
• 📄 Документы — операции (поступление, реализация, начисление зарплаты);
• 📊 Регистры — хранилища итогов: накопления (остатки и обороты), сведений, бухгалтерии (проводки), расчёта;
• 🧮 Отчёты и обработки — то, что считает и показывает данные или меняет их пачкой.

Поведение всех этих объектов описано на встроенном языке 1С, а выборки данных — на языке запросов. Редактируют конфигурацию в Конфигураторе или в современном режиме разработки.

Отдельно стоит знать про расширения конфигурации : они появились в версии не ниже 8.3.6 и позволяют дорабатывать типовое решение, не снимая его с поддержки. Своя доработка живёт в отдельном файле .cfe, а типовая конфигурация остаётся «чистой» и спокойно принимает обновления от вендора.

Отсюда понятно, что именно происходит при смене релиза. Данные (справочники, документы, остатки в регистрах) остаются на месте — обновляется только сама конфигурация: описание объектов, формы, код. Поэтому обновление идёт в два шага: сначала платформа принимает новую конфигурацию в хранилище, затем выполняет «Обновить конфигурацию базы данных», перестраивая структуру таблиц в СУБД под новое описание.

Лицензирование и ключи защиты

Без лицензии платформа 8.3 просто не запускает базу — это не «демо-режим с ограничениями», а отказ открыть информационную базу (исключение — отдельная учебная версия платформы). Поэтому лицензирование — такая же часть архитектуры, как сервер или СУБД.

Лицензии бывают двух видов по способу хранения:

• 🔑 Аппаратные ключи HASP — USB-ключ (локальный) или сетевой ключ, который раздаёт лицензии по сети через службу hasplm.
• 💾 Программное лицензирование — лицензия привязывается к параметрам компьютера пин-кодом, без физического ключа.

По назначению лицензии делятся на клиентские (на число одновременных рабочих мест) и серверную (нужна для запуска кластера серверов 1С). Клиентская лицензия может быть выдана как на конкретный компьютер, так и на сеанс из общего пула кластера.

Если база вдруг перестала запускаться с сообщением про лицензию, порядок простой: проверить, виден ли ключ (hasplm работает, USB-ключ на месте), доступен ли сервер лицензирования по сети, не исчерпан ли пул сеансов. Про конкретные ограничения базовой версии в каждом случае лучше свериться с документацией — у разных поставок они отличаются.

Журнал регистрации и технологический журнал: чем диагностируют

Когда что-то идёт не так, у платформы есть два разных журнала, и их постоянно путают.

Журнал регистрации — это история действий внутри информационной базы: кто вошёл, что провёл, где выскочила ошибка приложения. Открывается прямо из программы: Главное → Все функции → Стандартные → Журнал регистрации или из Конфигуратора. Это первое место, куда смотрят при разборе «кто изменил документ» и «когда появилась ошибка».

Технологический журнал — низкоуровневая диагностика самой платформы: обращения к СУБД, ожидания на блокировках, аварийные завершения процессов, дампы. Он не включён по умолчанию — его настраивают файлом logcfg.xml в каталоге платформы, указывая, какие события и куда писать. Это инструмент уже для администратора и специалиста техподдержки, а не для бухгалтера.

Грубое правило: вопрос «что сделал пользователь» — журнал регистрации; вопрос «почему тормозит или падает платформа» — технологический журнал.

Чтобы закрепить, из каких частей собрана платформа и за что каждая отвечает:

Если вы только выбираете схему развёртывания, короткое дерево поможет не промахнуться:

Частые вопросы