Недостатки технологии клиент-сервер

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

Нетрудно заметить, что большинство недостатков классической или 2-х слойной архитектуры клиент-сервер проистекают от использования клиентской станции в качестве исполнителя бизнес-логики ИС. Поэтому очевидным шагом дальнейшей эволюции архитектур ИС явилась идея "тонкого клиента", то есть разбиения алгоритмов обработки данных на части связанные с выполнением бизнес-функций и связанные с отображением информации в удобном для человека представлении. При этом на клиентской машине оставляют лишь вторую часть, связанную с первичной валидацией и отображением информации, перенося всю реальную функциональность системы на серверную часть.

Как видно, такая организация системы весьма напоминает организацию первых унитарных систем с той лишь разницей, что на пользовательском месте стоит не терминал (с пресловутым зеленым экраном), а персональный компьютер, обеспечивающий ГИП, например, в последнее время в качестве клиентских программ часто применяют стандартные www-броузеры. Конечно, такой возврат к почти унитарным системам произошел уже на ином технологическом уровне. Обязательным стало использование СУБД со всеми их преимуществами. Программы для серверной части пишут, в основном, на специализированных языках, пользуясь механизмом хранимых процедур сервера БД. Таким образом, на уровне логической организации, ИС в архитектуре клиент-сервер с тонким клиентом расщепляется на три слоя - слой данных, слой бизнес-функций (хранимые процедуры) и слой представления. К сожалению, обычно, в такой схеме построения ИС не удается написать всю бизнес-логику приложения на не предназначенных для этого встроенных языках СУБД. Поэтому, очень часто часть бизнес-функций реализуется в клиентской части систем, которая от этого неотвратимо "толстеет". Отчасти поэтому, отчасти потому, что физически такие ИС состоят из двух компонентов, эту архитектуру часто называют 2.5-слойный клиент-сервер.

В отличие от 2-х слойной архитектуры 2.5-слойная архитектура обычно не требует наличия высокоскоростных каналов связи между клиентской и серверной частями системы, так как по сети передаются уже готовые результаты вычислений - почти все вычисления производятся на серверной стороне. Существенно улучшается также и защита информации - пользователям даются права на доступ к функциям системы, а не на доступ к ее данным и т.д. Однако вместе с преимуществами унитарного подхода архитектура 2.5 перенимает и все его недостатки, как-то: ограниченную масштабируемость, зависимость от программной платформы, ограниченное использование сетевых вычислительных ресурсов. Кроме того программы для серверной части системы пишутся на встроенных в СУБД языках описания хранимых процедур, предназначенных для валидации данных и построения несложных отчетов, а вовсе не для написания ИС масштаба предприятия. Все это снижает быстродействие системы, повышает трудоемкость создания с модификации ИС и самым негативным образом сказывается на стоимости аппаратных средств, необходимых для ее функционирования.

Для решения этих проблем и была предложена так называемая 3-х слойная архитектура клиент-сервер. Основным ее отличием от архитектуры 2.5 является физическое разделение программ, отвечающих за хранение данных (СУБД) от программ эти данные обрабатывающих (сервер приложения (СП), application server (AS)). Такое разделение программных компонент позволяет оптимизировать нагрузки как на сетевое, так и на вычислительное оборудование комплекса.

Начнем с клиентской стороны. Использование действительно "тонкого" клиента позволяет использовать на рабочих местах маломощные компьютеры или терминалы. Медленная работа одного клиентского устройства не может привести к замедлению работы всей системы, как это бывает с 2-х слойной архитектурой. Между клиентской программой и сервером приложения передается лишь минимально необходимый поток данных - аргументы вызываемых функций и возвращаемые от них значения. Это теоретический предел эффективности использования линий связи, даже работа с ANSI-терминалами (не говоря уже об использование протокола http) требует большей нагрузки на сеть. Сервер приложения ИС может быть запущен в одном или нескольких экземплярах на одном или нескольких компьютерах, что позволяет использовать вычислительные мощности организации столь эффективно и безопасно как этого пожелает администратор ИС. Трафик между сервером приложений и СУБД может быть большим, однако это всегда трафик локальной сети, а их пропускная способность достаточно велика и дешева. В крайнем случае, всегда можно запустить СП и СУБД на одной машине, что автоматически сведет сетевой трафик к нулю. Ну, и, наконец, СУБД обрабатывают лишь запросы по извлечению и изменению данных, а не выполняют сложные бизнес-функции, что позволяет снизить нагрузку на сервер данных по сравнению с 2.5-слойной схемой, а значит и повысить скорость работы системы в целом.

Масштабируемость систем выполненных в 3-х слойной архитектуре впечатляет. Одна и та же система может работать как на одном отдельно стоящем компьютере, выполняя на нем программы СУБД, СП и клиентской части, так и в сети, состоящей из сотен и тысяч машин. Как уже было отмечено, единственным фактором, препятствующим бесконечной масштабируемости, является лишь требование ведения единой базы данных.

Помимо требования увеличения производительности системы с ростом масштабов деятельности важным фактором является и расширение ее функциональной наполненности. И здесь 3-х слойная схема выигрывает у своих предшественников. Для расширения функциональности не обязательно менять всю систему как в случае 2.5-слойной схемы - достаточно установить новый сервер приложения с требуемой функцией. Отпадают и многие проблемы связанные с переустановкой клиентских частей программы на множестве компьютеров, быть может весьма удаленных, столь актуальные для 2-х слойной схемы - парадигма "тонкого" клиента предоставляет для этого целый ряд возможностей (подробности в следующих статьях).

Здесь стоит отметить, что помимо описанных слоев прикладного ПО, для работы современных распределенных ИС необходимо и множество других программ, выполняющих системные функции. Эти функции могут обеспечиваться как программами, входящими в состав операционной системы (например, TCP/IP стек), так и внешними по отношению к ОС - в этом случае такие программы называются MiddleWare. На MiddleWare часто возлагают задачи по межсерверному взаимодействию, управлению транзакциями, разграничения доступа к сервисам системы, шифрования и т.п. Однако MiddleWare ни в коем случае нельзя считать дополнительным слоем прикладного ПО. 2-х слойный клиент-сервер остается 2-х слойным вне зависимости от работы с MiddleWare.

Какие же недостатки имеются у 3-х слойной модели и почему эта технология не получила такого широкого распространения, как ее предшественницы? На наш взгляд основной недостаток этой технологии состоит в сложности разработки систем на ее основе. Опытные разработчики знают, как сложно стыковать взаимосвязанные модули программ, в особенности написанные разными группами. Изменения в одном из модулей способно зачастую вызвать лавинообразные изменения в других частях комплекса. С этой точки зрения даже простейшая система, выполненная по 3-х слойной схеме в 2 раза сложнее систем в архитектурах 2 и 2.5 - в ней два уровня взаимодействия - клиент-СП и СП-СУБД. Когда же речь идет о многокомпонентной системе с использованием MiddleWare, то сложность разработки возрастает многократно. Ситуацию усугубляет и неразвитый по сравнению с более ранними архитектурами рынок инструментальных средств создания крупных ИС в 3-х слойной архитектуре.

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

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

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

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

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

Мнение о том, что клиент-сервер - это дорого имеет под собой основания. Действительно, компьютер, обслуживающий базу данных, обычно стоит дороже, чем файл-сервер, немалых денег стоит соответствующее количество лицензий на СУБД, на фоне этого повышенные цены поставщика ИС уже не выглядят невероятными, хотя, конечно, тоже вносят свой вклад в очень круглые цифры стоимости ИС в целом. Выход, на наш взгляд, лежит опять-таки в использовании трехслойной архитектуры. При этом можно значительно разгрузить сервер СУБД и снизить требуемую мощность компьютера (скажем, для ведения 30-40 тыс. счетов частных лиц в банке достаточно будет двухпроцессорного компьютера), вам не потребуется покупать лицензии СУБД для каждого пользователя ИС (например, для работы 200 пользователей будет достаточно 8 лицензий на СУБД).

Типичная схема взаимодействия клиента и сервера по протоколу HTML