Архитектура "Клиент-сервер"

Архитектура «клиент-сервер»

Эффективность функционирования информационной системы во многом зависит от ее архитектуры.

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

Однако повсеместное увлечение настольными СУБД и их сетевыми версиями, вызванное:

o        доступностью,

o        дешевизной как самого программного обеспечения,

o        так и дешевизной  его эксплуатации,

заставило многих пользователей на долгие годы забыть о «мэйнфреймовой» модели вычислений.

Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно большими. Это приводит к снижению производительности приложений, использующих такие СУБД. Наиболее популярные настольные СУБД: dBase, Paradox, FoxPro, Access. Информационные системы, написанные с использованием сетевых версий настольных СУБД, используют выделенные файл-сервера (т.е. реализованы с использованием архитектуры файл-сервера – исторически первая архитектура)

Рис. Классическое представление информационной системы в архитектуре "файл-сервер"

В любом приложении выделяются следующие компоненты:

o        прикладная часть приложения

o        часть управления данными

o        часть отвечающая за сетевой доступ.

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

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

Рис. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре

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

Известно много случаев, когда для решения подобных проблем:

o        закупалось дорогое сетевое оборудование с целью увеличения пропускной способности сети,

o        применялись иные <ухищрения> наподобие хранения наиболее часто используемых данных в клиентских приложениях или просто на локальных жестких дисках.

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

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

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

Принцип централизации хранения и обработки данных является базовым принципом архитектуры «клиент-сервер». Для его реализации используется так называемый сервер баз данных, только он может реально манипулировать файлами, в которых хранятся данные. Сервер баз данных осуществляет целый комплекс действий по управлению данными.

Основными его обязанностями являются:

        выполнение пользовательских запросов на выбор и модификацию данных, получаемых от клиентских приложений, функционирующих на персональных компьютерах локальной сети;

        хранение и резервное копирование данных;

        поддержка целостности данных согласно определенным в базе данных правилам;

        обеспечение авторизованного доступа к данным на основе проверки прав и привилегий пользователей;

        протоколирование операций и ведение журнала транзакций.

В качестве рабочего места пользователя может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды.

В простейшем случае «клиент-серверная» информационная система состоит из двух основных компонентов:

        сервера баз данных, управляющего данными и выполняющего запросы клиентских приложений;

        клиентских приложений, предоставляющих интерфейс пользователя и посылающих запросы к серверу.

Рис. Общее представление информационной системы в архитектуре "клиент-сервер"

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

Как видно, в клиент-серверной организации клиенты могут являться достаточно "тонкими", а сервер должен быть "толстым" настолько, чтобы быть в состоянии удовлетворить потребности всех клиентов.

Рис. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре

Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL:

1.       Сервер производит компиляцию полученного оператора.

2.       Если компиляция завершилась успешно, происходит выполнение оператора:

o         При выполнении оператора создания элемента схемы базы данных (домены, таблицы, ограничения целостности, триггеры, привилегии пользователей, хранимые процедуры) соответствующая информация помещается в таблицы-каталоги самой БД.

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

o         При выполнении операторов модификации содержимого базы данных (INSERT, UPDATE, DELETE) проверяется, что не будут нарушены определенные к этому моменту ограничения целостности (те, которые относятся к классу немедленно проверяемых), после чего выполняется соответствующее действие (сопровождаемое модификацией всех соответствующих индексов и журнализацией изменений). Далее сервер проверяет, не затрагивает ли данное изменение условие срабатывания какого-либо триггера, и если такой триггер обнаруживается, выполняет процедуру его действия. Эта процедура может включать дополнительные операторы модификации базы данных, которые могут вызвать срабатывание других триггеров т.е., выполняться серверная часть приложения.

o         При выполнении оператора вызова ранее определенных и сохраненных в базе данных хранимых процедур она выполняется. Если хранимая процедура определяется с помощью достаточно развитого языка (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента.

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

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

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

Рис.  "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

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

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

Существуют и более сложные реализации архитектуры «клиент-сервер», например многозвенные информационные системы с использованием нескольких серверов приложений:

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

Информационные системы, основанные на архитектуре «клиент-сервер» являются приближением к распределенным системам БД. Очень часто возникает необходимость предоставить доступ к одним и тем же данным группам пользователей, территориально удаленным друг от друга. В качестве примера можно привести банк, имеющий несколько отделений. Эти отделения могут находиться в разных городах, странах или даже на разных континентах, тем не менее необходимо организовать обработку финансовых транзакций (перемещение денег по счетам) между отделениями. Результаты финансовых операций должны быть видны одновременно во всех отделениях. Для построения таких информационных систем используется технология распределенной БД. Такая база включает фрагменты данных, расположенные на различных узлах сети. Основная задача систем управления распределенными базами данных состоит в обеспечении средства интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных. С точки зрения пользователей она выглядит так, как будто все данные хранятся в одном месте. Естественно, такая схема предъявляет жесткие требования к производительности и надежности каналов связи.