Что такое архитектура 1С:Предприятие 8

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

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

Ниже разобраны три уровня системы, режимы работы, состав кластера серверов, роль СУБД, механизмы расширения и критерии выбора варианта развёртывания для конкретной организации.

Три уровня системы: платформа, конфигурация, данные

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

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

Третий уровень — данные информационной базы: проведённые документы, остатки, настройки пользователей. В файловом режиме это один файл 1Cv8.1CD, в клиент-серверном — база в MS SQL Server, PostgreSQL, Oracle Database или IBM DB2. Важно понимать: платформа хранит данные в собственных структурах, и прямое изменение таблиц СУБД в обход платформы недопустимо — это гарантированный путь к повреждению базы.

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

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

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

Маршрут решения

Как выбрать режим работы

Пользователей до 5–10 и база небольшаяОставайтесь в файловом режиме, но настройте регулярное резервное копирование

Пользователей больше десятка или база быстро растётПланируйте переход на клиент-серверный режим

Требуется работа через веб-браузер и тонкий клиент извнеРазворачивайте веб-сервер публикации и клиент-серверную архитектуру

Критична непрерывность работыКлиент-серверный режим с резервированием и регламентным копированием СУБД

Клиентские приложения и варианты доступа

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

Веб-клиент запускается в браузере без установки платформы: базу публикуют на веб-сервере (Apache или IIS), и пользователи подключаются по ссылке. Это удобно для филиалов, удалённых сотрудников и партнёров, но требует настройки веб-сервера и защищённого соединения. Для мобильных сценариев существует мобильная платформа с автономной работой и синхронизацией.

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

Сервер 1С, кластер и роль СУБД

Клиент-серверный вариант строится вокруг кластера серверов 1С:Предприятия. Центральный процесс — агент сервера, он управляет списком информационных баз, сеансами и рабочими процессами. Рабочие процессы непосредственно исполняют код конфигурации и обслуживают клиентские соединения; их может быть несколько, в том числе на разных машинах, что даёт распределение нагрузки и отказоустойчивость.

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

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

Расширения и доработка без снятия с поддержки

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

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

Как спланировать развёртывание: порядок действий

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

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

1. 1
   Оцените число пользователей, объём данных и требования к отказоустойчивости
2. 2
   Выберите СУБД и спланируйте серверные мощности с запасом
3. 3
   Установите сервер 1С:Предприятия и создайте кластер
4. 4
   Разверните СУБД и создайте пустую базу с параметрами по документации
5. 5
   Загрузите конфигурацию и данные, настройте права и регламентные задания
6. 6
   Настройте резервное копирование средствами СУБД и проверьте восстановление
7. 7
   Проведите нагрузочную проверку ключевых операций до запуска пользователей

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

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

Часто задаваемые вопросы

Чем платформа отличается от конфигурации?

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

Можно ли перенести файловую базу в клиент-серверный режим?

Да. Стандартный путь — выгрузить базу в файл .dt через конфигуратор, создать пустую базу на сервере 1С с указанием СУБД и загрузить выгрузку туда. Перед переносом базу стоит протестировать и исправить, а после — проверить права пользователей и регламентные задания.

Нужна ли отдельная лицензия на сервер 1С?

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

Какую СУБД выбрать для клиент-серверной 1С?

Платформа поддерживает MS SQL Server, PostgreSQL (включая адаптированные сборки), Oracle Database и IBM DB2. Выбор определяется бюджетом, квалификацией администраторов и требованиями к нагрузке: коммерческие СУБД проще сопровождать при больших объёмах, свободные дешевле, но требуют грамотной настройки.

Что такое расширение конфигурации и когда его применять?

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

Опасно ли обновлять платформу без обновления конфигурации?

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