Файл: Варианты архитектуры клиент-сервер (Основные понятия клиент-серверной архитектуры).pdf

Введение

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

Но, не следует считать, что распределенные системы - изобретение последних лет. Три-четыре десятилетия назад была популярной модель "хост-компьютер + терминалы". Реализованная на мэйнфреймах, например IBM-360/370 или их советских аналогов - компьютеров серии ЕС ЭВМ.

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

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

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

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

---

Архитектура “клиент-сервер” определяет общие принципы организации взаимодействия в сети, где имеются сервера, узлы-поставщики специализированных функций (сервисов) и клиенты, потребители этих функций (сервисов). Реализацию данной архитектуры называется клиент-серверной технологией. Каждая технология определяет собственные или использует имеющиеся правила взаимодействия между клиентом и сервером, которые называются протоколом обмена (протоколом взаимодействия).

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

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

Глава I. Основные понятия клиент-серверной архитектуры.

1.1 Двухуровневая модель

Использование двухзвенной архитектуры клиент-сервер, подразумевает организацию сети и выполнение каким-либо компьютером в ней роли сервера. Компания Gartner Group предлагает следующие варианты двухзвенной архитектуры:

Рис.1. Варианты двухзвенной архитектуры по Gartner Group

Основные модели взаимодействия клиента и сервера в рамках двухзвенной архитектуры:

• файл-сервер — доступ к удаленной базе данных и файловым ресурсам;
• сервер терминалов — распределенное представление данных;
• сервер базы данных — удаленное представление данных;
• сервер приложений — удаленное приложение.

---

Первой была реализована модель сервера терминалов. Она базировалась на мэйнфрейме, выступавшего в роли сервера, с подключенными терминалами. Пользователи выполняли ввод данных с периферийный устройств (клавиатуры терминала, устройства считывания перфокарт или перфоленты), которые затем передавались на мэйнфрейм и там выполнялась их обработка, включая формирование «картинки» с результатами. Эта «картинка» и возвращалась пользователю на экран терминала или на принтер.

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

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

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

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

---

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

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

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

• возможно централизованное администрирование прикладных функций;
• снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;
• значительное снижение сетевого трафика (т.к. передаются не SQL-запросы, а вызовы хранимых процедур).

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

1.2 Многоуровневая архитектура

Следующий шаг в развитии двухзвенной архитектуры - “разделение обязанностей”. Появление языка программирования Java привело к возникновению апплетов - промежуточного звена, которое можно было вынести на клиентскую машину, тем самым перенеся часть вычислений с сервера на клиентскую машину.

---

Проблемы двухзвенной архитектуры следующие:

• при тонком клиенте возникают проблемы с производительностью и масштабируемостью системы;
• при толстом клиенте возникают проблемы с управляемостью системы;

Поэтому следующий шаг очень логичен, хоть и появился не сразу:

• Представление (отображение) данных, обработка действий пользователя остается на стороне клиентского приложения;
• Логика работы системы (бизнес-логика) остается на сервере приложений;
• Работа с данными отдается СУБД.

Таким образом каждый слой остается независимым и легко разделяемым между инфраструктурой. Клиентскому приложению остается небольшая часть функций и можно рассматривать (а в настоящий момент не иметь web-интерфейс считается моветоном) web-браузер в качестве клиента. Клиентская часть не знает о том, сколько и каких серверов обрабатывает ее запросы или хранит данные за отображением которых она обращается. Например, клиент может находиться в Европе, а данные которые он запросит могут легко находиться в ЦОДе через океан. Сервер приложений тоже не знает, сколько физически серверов будет обрабатывать и хранить данные за которыми он обращается. Для него это логическая прослойка “Сервер базы данных” к которой будут направлены его запросы.

Многие информационные системы сейчас сохранили “толстого” клиента, но это скорее для сохранения “обратной совместимости” или необходимости проведения интенсивных вычислений или визуализации на клиентском компьютере (например CAD/CAM системы). Некоторые крупные информационные системы имеют только web-интерфейс, например NetSuite. Одна из крупнейших платформ имеет в своем составе множество отраслевых решений, имеет только web-интерфейс и предоставляется только по модели SaaS.

Преимущества подобного архитектурного подхода трудно переоценить, но конечно есть и недостатки:

• большая сложность разработки информационной системы, а следовательно и большая стоимость в том числе и стоимость поддержки и развития;
• низкие требования к клиентскому “железу” формируют высокие требования к инфраструктуре сервера приложений и сервера баз данных, а следовательно к их стоимости;
• также низкие требования к каналу связи между клиентом и сервером приложений, формируют требования к высокопроизводительному каналу связи между сервером приложений и сервером баз данных, а следовательно к стоимости их реализации и поддержки.

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

---