Методы горизонтального распределения

⇐ ПредыдущаяСтр 6 из 16Следующая ⇒

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

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

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

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

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

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

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

В этом случае мы обычно говорим об одноранговом распределении. Подобное происходит, например, если поль- зователь хочет связаться с другим пользователем. Оба они должны запустить одно и то же приложение, чтобы начать сеанс.

Третий клиент может общаться с одним из них или обоими, для чего ему нужно запустить то же самое приложе- ние.

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

Что дает архитектура клиент-сервер?

Посмотрим на данную архитектуру с точки зрения потребностей бизнеса. Какие же качества привносит клиент-сервер в информационную систему?

Надежность

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

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

независимость - транзакции, инициированные разными пользователями, не вмешиваются в дела друг друга;

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

Масштабируемость

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

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

Безопасность

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

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

Гибкость

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

пользовательского интерфейса;

правил логической обработки (бизнес-правил);

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

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

Рис. Трехуровневая модель клиент-серверного приложения

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

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

2) В двухуровневой клиент-серверной системе, если алгоритм расчета зарплаты реализован на сервере в виде правила расчета зарплаты, его выполняет сервер бизнес-правил, выполненный, например, в виде OLE-сервера, и мы обновим один из его объектов, ничего не меняя ни в клиентском приложении, ни на сервере баз данных.

Приложения клиент-сервер

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

Иллюстрация общего случая приведена на рис. 17.3. Как на клиенте, так и на сервере базовым программным обеспечением является, разумеется, операционная система.

Аппаратные платформы и операционные системы клиентов и серверов могут отличаться. В самом деле, в едином окружении могут использоваться разные типы клиентских и серверных платформ и операционных систем. Однако эти различия не имеют значения, если сервер и клиент используют одни и те же коммуникационные протоколы и поддерживают одинаковые приложения.

Взаимодействие клиента и сервера обеспечивается коммуникационным программным обеспечением. Примерами такого программного обеспечения являются набор протоколов TCP/IP, - протоколы OSI, а также различные фирменные архитектуры, вроде SNA.

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

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

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

Рис. 17.3. Общая архитектура клиент-сервер

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

В большинстве систем клиент-сервер графическому интерфейсу пользователя (Graphical User Interface, GUI) уделяется очень серьезное внимание — он должен быть простым и удобным, но одновременно мощным и гибким.

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

Базы данных

Рассмотрим концепцию распределенной между клиентом и сервером логики приложения на примере реляционной базы данных.

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

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

Специальное программное обеспечение связывает клиента и сервера, позволяя клиенту выполнять запросы и получать доступ к базе данных. Популярным примером такой логики является язык структурированных запросов (Structured Query Language, SQL).

Рис. 17.4. Архитектура клиент-сервер для баз данных

На рис. 17.4 предполагается, что вся прикладная логика — программы для обработки и анализа данных — располагается на клиентской стороне, тогда как сервер занимается только управлением базой данных.

Приемлемость такой конфигурации зависит от стиля и задачи конкретного приложения. Предположим, например, что основная цель приложения заключается в обеспечении доступа для поиска записей в режиме подключения (on-line).

Пример работы такой схемы показан на рис. 17.5, а.

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

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

На этот раз сервер отвечает, что в базе данных содержится 1000 записей, удовлетворяющих критериям поиска. Наконец, клиент посылает третий запрос с дополнительными критериями. Результатом поиска на этот раз является одна запись, которая возвращается клиенту.

Рис. 17.5. Использование базы данных в архитектуре клиент-сервер

Данное приложение хорошо соответствует архитектуре клиент-сервер по двум причинам.

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

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

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

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

⇐ Предыдущая 1 2 3 4 567 8 9 10 Следующая ⇒