Foreversoft.ru

IT Справочник
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Трехуровневая архитектура клиент сервер

Трехуровневая клиент-серверная архитектура

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

Рисунок 1.9 – Схема трехуровневой архитектуры ИС

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

Ниже представлено описание взаимодействия компонентов трехуровневой архитектуры клиент-серверного приложения. Сервер БД представлен MySQL-сервером; сервер приложений технологиями: ADO.NET, ASP.NET и web-сервером IIS; роль клиента выполняет любой web-браузер.

Схематично работу системы можно представить в виде последовательности: Браузер клиента1-> Сервер IIS2-> Исполняющая среда ASP.NET 2.03-> Провайдер данных ADO.NET 2.04-> Сервер MySQL5-> Провайдер данных ADO.NET 2.06-> Исполняющая среда ASP.NET 2.07-> Сервер IIS8-> Браузер клиента.

Более детально функционирование системы происходит следующим образом.

1 — браузер клиента отправляет HTTP-запрос;

2 — на стороне сервера служба Web Internet Information Server (web-сервер IIS) определяет тип запрашиваемого ресурса, и для случая запроса *.aspx (расширение файлов страниц ASP.NET) загружает соответствующее ему (запросу) расширение Internet Server Aplication Programming Interface (ISAPI). Для страниц aspx это расширение isapi_aspnet.dll. IIS также осуществляет идентификацию и авторизацию пользователя от которого поступил запрос. В свою очередь расширение isapi_aspnet.dll загружает фабрику обработчиков ASP.NET. Далее, фабрика обработчиков создает объектную модель запрашиваемой страницы и обрабатывает действия пользователя.

3 — в ходе генерации ответа приложению ASP.NET может потребоваться обращение к БД, в этом случае используя библиотеки классов провайдера данных ADO.NET 2.0, выполняющая среда обращается к серверу БД;

4 — провайдер данных ADO.NET 2.0 передает запрос на операцию с БД серверу MySQL;

Рис.1.10 – Модель сервера приложений трехуровневой ИС

5 — сервер MySQL осуществляет обработку запроса, выполняя соответствующие операции с БД;

6 — провайдер данных ADO.NET 2.0 передает результаты запроса объекту страницы;

7 — объект страницы с учетом полученных данных осуществляет визуализацию (рендеринг) графического интерфейса страницы и направляет результаты в выходной поток;

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

Преимуществом трехуровневой архитектуры является:

1. Меньшая нагрузка на клиентское приложение («Тонкий клиент»).

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

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

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

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

6. Дешевле наращивать функциональность и обновлять ПО.

К недостаткам архитектуры можно отнести более высокие расходы на администрирование и обслуживание серверной части.

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

Важным фактором в трехуровневой архитектуре является возможность расширение ее функциональной наполненности. Для расширения функциональности не обязательно менять всюсистему как в случае 2.5-уровневой архитектуры, а достаточно установить новый сервер приложения с требуемой функцией. Отпадают и многие проблемы связанные с переустановкой клиентских частей программы на множестве компьютеров, быть может весьма удаленных, столь актуальные для 2-уровневой схемы — парадигма «тонкого» клиента предоставляет для этого целый ряд возможностей.

Читать еще:  Архитектура с параллельными процессорами

Трехуровневая архитектура. Достоинства и недостатки

В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

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

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

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

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

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

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

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

· низкие требования к скорости канала (сети) между терминалами и сервером приложений

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

Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

· более высокая сложность создания приложений;

· сложнее в разворачивании и администрировании;

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

· высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Студент — человек, постоянно откладывающий неизбежность. 11311 — | 7592 — или читать все.

Архитектурные особенности проектирования и разработки Веб-приложений

5.1.5. Многоуровневый «клиент-сервер»

Многоуровневая архитектура клиент-сервер ( Multitier architecture) – разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов [15]. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.

Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура ( трехзвенная архитектура , three- tier ), предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал ), подключенное к серверу приложений , который в свою очередь подключен к серверу базы данных [14, 17].

Схематически такую архитектуру можно представить, как показано на рис. 5.4.

  • Терминал – это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал .
  • Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы , а также погруженные в третий уровень хранимые процедуры и триггеры.
  • Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.
Читать еще:  Архитектура субд это

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

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

Плюсами данной архитектуры являются [12, 14, 16, 17]:

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

Некоторые авторы (например, Мартин Фаулер [18]) представляют многозвенную архитектуру (трехзвенную) в виде пяти уровней (рис. 5.5):

  1. Представление;
  2. Уровень представления;
  3. Уровень логики;
  4. Уровень данных;
  5. Данные.

К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы, таблицы стилей, изображения.

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

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

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

Данные системы обычно хранятся в базе данных.

5.1.6. Архитектура распределенных систем

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

Схематически такую архитектуру можно представить, как показано на рис. 5.6.

Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы [16]. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизится. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.

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

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

Читать еще:  Модель архитектуры клиент сервер

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

Распределенные системы с репликацией

Данными между различными рабочими станциями и централизованным хранилищем данных , передаются репликацией [19] (рис. 5.7). При вводе информации на рабочих станциях – данные также записываются в локальную базу данных, а лишь затем синхронизируются.

Распределенные системы с элементами удаленного исполнения

Существуют определенные особенности, которые невозможно качественно реализовать на обычной распределенной системе репликативного типа. К этим особенностям можно отнести [19]:

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

У каждого из описанных типов используется общий принцип: программа клиент или обращается к выделенному (удаленному) серверу непосредственно или обращается к локальной базе, которая инкапсулирует в себе обращение к удаленному серверу (рис. 5.8).

МИГКУ ИТ-51вс

Метки

Добавить страницу

Централизованная система

Все данные на одном ПК. Таких приложений вагон и маленькая тележка — от всяких наколенных поделок на M$ Access до Mozilla Firefox (он использует файловую СУБД SQLite для хранения некоторых данных)

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

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

Двухуровневая архитектура «клиент-сервер»

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

Трёхуровневая архитектура «клиент-сервер»

Позволяет помещать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс устанавливается связь клиентских рабочих станций (как Deathmatch в Quake). Работа клиентской части приложения сводится к вызову необходимых функций сервера приложения, которые называются «сервисами». Прикладные прогаммы в свою очередь обращаются к серверу баз данных с помощью SQL-запросов.
Плюсы:

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

Многоуровневая архитектура «клиент-сервер»

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

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

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

Ссылка на основную публикацию
Adblock
detector