Часто у начинающих разработчиков и системных администраторов возникает резонный вопрос: если пользователи всё равно работают внутри одной физической машины (терминального сервера) по протоколу RDP, зачем усложнять систему разделением на «клиент» и «сервер»? Ведь кажется, что в рамках одного системного блока (или мощного сервера) передача данных и так происходит мгновенно. Однако архитектура 1С:Предприятие 8.3 строится на принципах, которые выходят далеко за рамки простой экономии сетевого трафика.
В этой статье мы подробно разберем, почему директивы &НаКлиенте и &НаСервере — это не просто «дань моде» или инструмент для локальных сетей, а жизненно важная необходимость даже внутри одного сервера. Мы проанализируем технические, экономические и архитектурные аспекты этого разделения.
Первое, что нам необходимо сделать, — это разграничить роли программного обеспечения. Рассмотрим ситуацию: когда пользователь подключается по RDP, он создает сессию на терминальном сервере (Remote Desktop Session Host). В этой сессии запускается графическая оболочка клиента 1С.
Однако сервер приложений 1С — это отдельная программная сущность (служба ragent), которая управляет кластером, сеансами и соединениями с базой данных (SQL). Даже если обе эти роли выполняет один физический компьютер, они работают как разные процессы с разными задачами. Разделение на тонкого и толстого клиента позволяет эффективно распределять нагрузку между визуализацией интерфейса (в RDP-сессии) и тяжелыми вычислениями (в контексте сервера приложений).
Давайте проанализируем, как ведут себя разные типы клиентов в памяти сервера. Это критически важно для терминальных ферм, где на одном сервере могут работать десятки и сотни пользователей.
Толстый клиент представляет собой «монолит». При запуске он подгружает в адресное пространство процесса огромное количество метаданных, библиотек для работы с файловой системой и компоненты для прямого взаимодействия с СУБД. Каждый запущенный экземпляр толстого клиента в терминальной сессии «отъедает» значительный объем RAM.
Тонкий клиент, напротив, является максимально облегченной оболочкой. Его задача — только отрисовать формочки и передать команды пользователя на сервер. Вся «тяжелая» работа по обработке кода и запросов к БД выполняется на стороне сервера приложений 1С. Разберем результат: использование тонкого клиента в терминале позволяет разместить на том же железе в 1.5–2 раза больше пользователей за счет снижения потребления памяти каждым индивидуальным сеансом.
Один из важнейших аргументов — это возможность писать код один раз для всех видов доступа. Рассмотрим типичный пример программного кода в современном приложении 1С:
&НаКлиенте
Процедура ВыполнитьДействие(Команда)
// Код, который выполняется непосредственно в окне пользователя
Если Вопрос("Запустить обработку?", РежимДиалогаВопрос.ДаНет) = КодВозвратаДиалога.Да Тогда
Результат = ОбработатьДанныеНаСервере();
ПоказатьОповещениеПользователя(Результат);
КонецЕсли;
КонецПроцедуры
&НаСервере
Функция ОбработатьДанныеНаСервере()
// Тяжелые вычисления, работа с запросами и БД
Запрос = Новый Запрос("ВЫБРАТЬ Ссылка ИЗ Справочник.Номенклатура");
Возврат "Данные успешно обработаны";
КонецФункции
Если бы мы не использовали разделение на &НаКлиенте и &НаСервере, нам пришлось бы поддерживать разные конфигурации для разных условий работы. Разработчику 1С не важно, сидит пользователь за соседним столом через Wi-Fi, работает через браузер из дома или подключен через RDP прямо на сервере. Механизм управляемых форм гарантирует, что логика интерфейса будет отделена от логики данных. Без этого разделения запуск тяжелых конфигураций (таких как ERP 2.5) в режиме веб-клиента был бы просто невозможен.
Проанализируем ситуацию критической ошибки. В архитектуре толстого клиента ошибка в коде или сбой графического драйвера в терминальной сессии часто приводит к аварийному завершению всего приложения. Если в этот момент шла транзакция записи в базу, последствия могут быть неприятными.
В тонком клиенте интерфейсная часть и серверная часть живут в разных процессах (а часто и под разными учетными записями ОС). Если «упадет» графическая оболочка тонкого клиента в RDP, сеанс на сервере приложений часто остается активным («спящим»), и пользователь, переподключившись, может продолжить работу. Это обеспечивает гораздо более высокую отказоустойчивость системы.
Представим ситуацию: сегодня ваша компания небольшая, и терминальный сервер совмещен с сервером 1С и SQL на одной «железке». Но завтра база вырастает до терабайта, и вам нужно вынести SQL на отдельный сервер, а сервер приложений 1С — на другой.
Если вы изначально использовали технологию тонкого клиента, этот переход пройдет бесшовно. Тонкий клиент просто сменит адрес подключения. Если же вы работали в режиме «толстого клиента» (особенно в файловом варианте через расшаренные папки внутри сервера), вы столкнетесь с тем, что система не способна масштабироваться горизонтально. Разделение логики подготавливает вашу информационную систему к любым нагрузкам в будущем.
Даже если задержка (latency) внутри сервера минимальна, каждый вызов с клиента на сервер — это контекстное переключение процессора. Тонкий клиент спроектирован так, чтобы минимизировать количество таких «походов».
В управляемом приложении платформа оптимизирует передачу данных: на сервер отправляется не вся форма целиком, а только измененные данные. Это снижает нагрузку на шину памяти и процессорное время сервера, что опять же позволяет системе работать быстрее при большом количестве одновременных пользователей.
Это важнейший аспект для системных администраторов. Рассмотрим разницу в правах доступа:
Подводя итог, можно сказать, что отделение тонкого клиента от серверной части при терминальном доступе — это стратегическое решение. Оно обеспечивает:
Таким образом, использование архитектуры управляемого приложения и тонкого клиента является стандартом современной разработки на платформе 1С, независимо от способа доставки интерфейса пользователю.