Журнал PC Magazine/RE №12/2009
Шрифт:
Во-первых, «горячее» резервирование кластера серверов. У администратора информационной системы появилась возможность объединить несколько кластеров в группу резервирования. Обслуживанием пользователей занимается первый кластер из группы, а остальные поддерживают у себя в актуальном состоянии все важные данные первого кластера. В случае выхода из строя первого кластера, активным становится следующий кластер из группы резервирования. Для рабочих процессов, функционирующих внутри кластера, реализована другая схема – рабочие процессы подразделяются на активные и резервные. В случае плановой или аварийной остановки активного процесса кластер запускает один из резервных процессов и переводит на него имеющуюся нагрузку.
Практически это означает, что при грамотно спроектированной структуре кластера завершение любого из серверных процессов и даже отключение любого из физических компьютеров
Во-вторых, масштабирование управляющих процессов (менеджеров) кластера. Общие данные и сервисные функции кластера теперь могут быть распределены между несколькими процессами-менеджерами, функционирующими на разных физических компьютерах. Эта позволяет существенно разгрузить главный менеджер кластера и переложить часть «сервисной» нагрузки на другие процессы.
В-третьих, новая модель клиент-серверного взаимодействия. Теперь платформа обладает устойчивостью к обрывам каналов связи между клиентом и сервером: в случае, если клиентское приложение не было завершено штатным образом, но перестало подавать признаки жизни, пользовательский сеанс продолжает поддерживаться на стороне сервера в течение довольно длительного времени (20 мин). Если за это время связь будет восстановлена, пользователь сможет продолжить работу с того самого места, где она была прервана.
Следует отметить, что устойчивостью к обрыву связи в любом случае обладают тонкий и Web-клиент, а в случае толстого клиента «воскрешение» пользовательского сеанса зависит главным образом от того, какая именно операция выполнялась клиентским приложением в момент обрыва связи. Некоторые операции (например, работа с транзакциями), к сожалению, требуют непрерывной связи между клиентом и сервером и не могут быть временно прерваны.
В-четвертых, динамическая балансировка нагрузки между рабочими процессами кластера. Кластер постоянно отслеживает загруженность своих рабочих процессов и вычисляет интегральную доступную производительность каждого процесса. Если доступная производительность разных процессов существенно различается, происходит переключение части пользовательских сеансов с более нагруженных процессов на менее нагруженные.
В предыдущих версиях «1С: Предприятия 8» анализ загруженности рабочих процессов тоже выполнялся, но только в момент возникновения нового клиентского соединения – кластер принимал решение, какому из рабочих процессов передать это соединение для обслуживания. Но на практике разные пользователи создают непропорциональную нагрузку на кластер – например, одни просто листают список документов, а другие формируют «тяжелые» отчеты. И при неблагоприятном стечении обстоятельств (несколько «тяжелых» пользователей попали в один рабочий процесс) возникали проблемы производительности информационной системы. Конечный пользователь вовсе не обязан знать о существовании рабочих процессов и тонкостях распределения нагрузки между ними, но на ситуацию «вдруг все стало тормозить» он обязательно отреагирует, причем реакция будет строго негативной.
Механизм динамической балансировки нагрузки на рабочие процессы, появившийся в версии «1С: Предприятие 8.2», позволяет насколько это возможно равномерно распределять активность пользователей по рабочим процессам кластера и использовать аппаратные ресурсы наиболее эффективно.
В предыдущих версиях «1С: Предприятия 8» пользовательский интерфейс целиком и полностью создавался разработчиком прикладного решения. Платформа практически никогда не принимала самостоятельных решений о выводе того или иного элемента на какую-либо форму, а изменения в структуре метаданных конфигурации никоим образом не влияли на интерфейсную часть. Разработчик должен был в явной форме создать командный интерфейс (главное
меню и панели инструментов) и в буквальном смысле «нарисовать» все необходимые формы. При этом разработчик получал полную свободу действий – можно было поместить любой элемент в любое место любой формы, придать любой размер, раскрасить в любые цвета и т. д. К сожалению, у полной свободы действий есть и своя оборотная сторона – при работе через Интернет или по медленным каналам связи передача информации о такой форме между клиентом и сервером стала бы очень затратным мероприятием. Более эффективный способ – передача не собственно формы, а правил ее формирования.В «1С: Предприятии 8.2» реализована принципиально новая интерфейсная модель, называемая управляемым приложением. Управляемое приложение базируется на следующих концепциях.
• Оконная система. Каждое окно «1С: Предприятия 8» в режиме управляемого приложения – независимо и представлено отдельном элементе на панели задач ОС (или же отдельное окно браузера при работе с Web-клиентом). Основное окно предназначено для навигации по функциям конфигурации и данным информационной базы, а вспомогательные окна используются для доступа к данным (например, через формирование отчетов) и модификации объектов информационной базы.
• Декларативное описание интерфейса. Управляемое приложение позволяет разработчику перейти от конструирования интерфейса к декларированию, т. е. к явному или неявному указанию платформе, какой элемент и в какой ситуации выводить или не выводить в пользовательский интерфейс. Наиболее простой пример такого декларирования – настройка прав доступа к объектам конфигурации. Платформа автоматически исключит из интерфейса функции, выполнять которые текущий пользователь не имеет права. Могут применяться и более сложные способы – например, механизм функциональных опций, при помощи которого разработчик может описать зависимость между элементами интерфейса и данными информационной базы.
• Управляемый командный интерфейс. В режиме управляемого приложения «1С: Предприятие 8» формирует командный интерфейс прикладного решения на основании правил, описанных разработчиком. Структура разделов командного интерфейса и состав команд каждого раздела формируются платформой «на лету» (автоматически). При формировании командного интерфейса учитывается иерархия подсистем прикладного решения, права доступа пользователя, функциональные опции информационной базы, а также настройки порядка следования и видимости элементов, установленные разработчиком конфигурации по умолчанию и конкретным пользователем лично для себя.
• Управляемые формы. Как и все остальные элементы пользовательского интерфейса, управляемые формы объектов конфигурации создаются путем декларативного описания. Разработчик не «рисует» форму, а задает состав элементов формы и правила их отображения. Разработчик может также предоставить пользователю возможность изменять форму по своему предпочтению, причем как для всей формы вообще, так и для отдельных элементов и групп элементов. Функциональность управляемой формы распределена между клиентом и сервером «1С: Предприятия», причем главную роль играет сервер. Подготовка формы, бизнес-логика формы, модификация данных информационной базы – все это выполняется на стороне сервера, а на стороне клиента производятся только отрисовка формы и некоторые самые простые операции (арифметические вычисления, вывод сообщений и вопросов и т. п.).
Дизайн визуального интерфейса финальной версии «1С: Предприятия 8.2» по сравнению с бета-версией был почти полностью переработан, изменились цветовые палитры, текстуры, обводки, внешний вид элементов и кнопок, были перерисованы практически все иконки и картинки.
Следует отметить очень важный момент: в отличие от предыдущих версий, разработчики прикладных решений больше не могут произвольно изменять элементы визуального стиля в своих конфигурациях. В управляемом режиме все прикладные решения, разработанные на платформе «1С: Предприятие 8», будут иметь схожий внешний вид и полностью идентичный визуальный дизайн приложения. Можно привести ряд аргументов как «за», так и «против» такого решения разработчиков платформы, но это стало бы пустой тратой бумаги. Решение было принято осознанно, и оно – вот такое.