1С:Предприятие 8.3 изнутри: архитектура, режимы работы и администрирование

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

Архитектурно платформа умеет работать в двух режимах: файловом и клиент-серверном. От выбора режима зависит, где лежат данные, сколько пользователей выдержит база и как её администрировать. Клиентское приложение при этом может быть разным — тонкий клиент, веб-клиент или толстый клиент, — и все они обращаются к одной и той же базе.

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

Платформа и конфигурация: кто за что отвечает

Платформа не знает ничего про бухгалтерию. Она предоставляет объекты — справочники, документы, регистры, отчёты — как конструктор. Конкретный смысл этим объектам придаёт конфигурация: справочник «Номенклатура», документ «Реализация товаров», регистр накопления «Товары на складах».

Такое разделение даёт три практических следствия:

• 📦 Одна установленная платформа обслуживает сколько угодно баз с разными конфигурациями.
• 🔄 Обновление платформы и обновление конфигурации — независимые процессы. Можно поднять релиз Бухгалтерии, не трогая версию платформы, и наоборот.
• 🧩 Конфигурацию можно дорабатывать, не затрагивая ядро платформы: весь прикладной код живёт в конфигурации.

Номер платформы и номер конфигурации видны в меню Справка → О программе. Для работы нужна совместимость: конфигурация требует платформу не ниже определённого номера (это указано в её свойствах), и запускать её на более ранней платформе нельзя.

Файловый и клиент-серверный режимы: где лежат данные

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

Клиент-серверный вариант устроен иначе: данные хранит внешняя СУБД (PostgreSQL, Microsoft SQL Server, Oracle, IBM Db2), а между клиентом и СУБД стоит кластер серверов 1С. Получается трёхуровневая схема: клиентское приложение → кластер серверов 1С → сервер баз данных.

Чем клиент-серверный режим отличается на практике:

Кластер серверов: как клиент соединяется с базой

В клиент-серверном режиме работу обеспечивает кластер серверов 1С — набор служб на одном или нескольких компьютерах. Порядок соединения такой:

1. Клиент обращается к агенту сервера. По умолчанию агент слушает порт 1540.
2. Агент передаёт запрос менеджеру кластера (порт 1541 по умолчанию). Менеджер выбирает, какой рабочий процесс обслужит сеанс.
3. Рабочий процесс (rphost) выполняет прикладной код и общается с СУБД. Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера (по умолчанию 1560–1591).

Отсюда главное правило при настройке сетевого экрана: открывать нужно не только 1540 и 1541, но и весь диапазон портов рабочих процессов. Если открыт только 1540, клиент подключится к агенту, но не сможет начать сеанс.

Параметры отказоустойчивости, требования назначения функциональности и диапазон портов настраиваются в свойствах рабочего сервера в консоли администрирования. Не путайте их со свойствами кластера в целом.

Режимы запуска и виды клиентских приложений

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

• 🖥️ Тонкий клиент — основной режим 8.3. Почти вся логика выполняется на сервере, на клиенте — только интерфейс. Экономит трафик и ресурсы рабочего места, хорошо работает по медленным каналам.
• 🌐 Веб-клиент — та же конфигурация в браузере, без установки программы. Требует предварительной публикации базы на веб-сервере (Apache или IIS). Удобен для удалённых и временных пользователей.
• 🧰 Толстый клиент — исторический режим с полным доступом к данным с клиента. В современных типовых конфигурациях на управляемых формах почти не используется, но платформа его поддерживает.
• 🛠️ Конфигуратор — отдельный режим для разработки и администрирования: правка конфигурации, пользователи, выгрузка и загрузка .dt, тестирование и исправление базы.

Интерфейс платформы 8.3 — «Такси». Прежние названия команд из 8.2 («Все действия», «Настроить список…») к актуальным релизам не относятся.

Монопольный доступ к базе нужен не всегда. Он требуется для операций, меняющих структуру или целостность: обновление структуры конфигурации базы данных, загрузка .dt, тестирование и исправление. Обычная работа пользователей, открытие Конфигуратора для просмотра или выгрузка в .dt монополии не требуют — хотя загрузка .dt уже монопольна.

Хранение данных и транзакции

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

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

• 📈 Регистр накопления — остатки и обороты (товары на складах, взаиморасчёты).
• 📋 Регистр сведений — значения на дату или без привязки к времени (курсы валют, цены).
• 📒 Регистр бухгалтерии — проводки по плану счетов.
• 🧮 Регистр расчёта — начисления и удержания в зарплатных конфигурациях.

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

Чтобы параллельные сеансы не портили друг другу данные, работает механизм блокировок:

• 🔒 Транзакционные блокировки СУБД удерживают изменяемые записи до конца транзакции.
• 🧭 Управляемые блокировки 1С позволяют прикладному коду заранее заблокировать нужные данные (например, остатки по складу перед списанием) и этим снизить число конфликтов.

Параллельная запись в одни и те же данные может приводить к ожиданиям на блокировках и взаимоблокировкам (deadlock). Это не ошибка конфигурации сама по себе, а плата за одновременную работу; лечится она оптимизацией запросов и правильной расстановкой управляемых блокировок.

Язык запросов и производительность

Запросы в 1С пишут на встроенном языке запросов. Он декларативный и внешне похож на SQL, но объектно-ориентированный: к реквизитам можно обращаться через точку (Номенклатура.ЕдиницаИзмерения.Наименование), а платформа сама построит нужные соединения. В клиент-серверном режиме запрос транслируется в SQL и выполняется на стороне СУБД — считает сервер базы данных, а не клиент.

Производительность упирается именно в запросы. Несколько приёмов, которые реально ускоряют работу:

• ⏱️ Разбивайте сложную выборку на пакет запросов с временными таблицами вместо вложенных подзапросов в соединениях.
• 🎯 Не получайте данные «через точку» от полей составного типа в условиях и соединениях — платформа вынуждена перебирать все типы.
• 📊 Отбирайте только нужные поля и строки, а не «всё, потом отфильтруем в коде».
• 🧱 Следите за индексами по полям, участвующим в условиях и соединениях.
• 🗂️ Берите остатки и обороты из виртуальных таблиц регистров (например, таблицы остатков регистра накопления), а не считайте их вручную из таблицы движений — платформа посчитает итоги эффективнее.

Для поиска узких мест есть штатные инструменты: замер производительности в Конфигураторе, журнал регистрации, технологический журнал и методика APDEX для оценки времени ключевых операций. Начинать стоит с них, а не с догадок, какой именно отчёт «тормозит».

Расширяемость и интеграция с внешними системами

Дорабатывать типовую конфигурацию можно двумя путями. Первый — снять с поддержки и править основную конфигурацию, но тогда усложняется обновление. Второй, современный, — расширения конфигурации .

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

Для обмена с внешними системами платформа предлагает несколько механизмов:

• 🔗 HTTP-сервисы — приём и отдача данных по REST-подобным запросам.
• 🧾 Web-сервисы (SOAP) — строго описанные сервисы с WSDL.
• 📥 OData (стандартный интерфейс) — автоматический доступ к данным конфигурации по HTTP, включается при публикации.
• 🔌 COM-соединение — вызов функций 1С из внешней программы на той же машине или в сети.
• 📨 Планы обмена — встроенный механизм распределённых баз и обмена данными между конфигурациями (в том числе через формат EnterpriseData).

Выбор механизма зависит от задачи: разовая выгрузка в файл, постоянная синхронизация двух баз или онлайн-запросы от стороннего сайта решаются разными средствами.

Администрирование и мониторинг

Администрируют платформу из нескольких мест. Конфигуратор отвечает за пользователей, роли и обслуживание базы. Консоль администрирования серверов (оснастка MMC) и утилита rac управляют кластером: сеансами, соединениями, рабочими процессами, лицензиями.

Несколько полезных команд rac:

rac cluster list
rac session list --licenses

Первая покажет кластеры и их идентификаторы, вторая — активные сеансы с привязкой лицензий. Полный список подкоманд и параметров смотрите в справке rac help — не угадывайте параметры по памяти.

Для наблюдения за системой есть два разных журнала:

• 📘 Журнал регистрации — прикладные события: кто что провёл, вошёл, изменил. Доступен из Конфигуратора и из режима предприятия.
• 🧪 Технологический журнал — низкоуровневые события платформы: ошибки, блокировки, обращения к СУБД. Нужен при разборе инцидентов и оптимизации, включается настройкой.

Без действующей лицензии платформа не запустит рабочую базу (исключение — учебная версия с ограничениями). Лицензии бывают программные и аппаратные (USB), однопользовательские и многопользовательские; в клиент-серверном режиме их обычно выдаёт сервер лицензирования, а их расход виден в списке сеансов.

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