Какие сервисы предоставляет клиент серверная архитектура

Обновлено: 30.06.2024

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

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

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

Классическая архитектура клиент-сервер

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

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

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

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

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

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

Итак, рассмотренные выше модели имеют следующие недостатки.

1. "Толстый" клиент:

2. "Толстый" сервер:

Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент-сервер.

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

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

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

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

Многоуровневые клиент-серверные системы достаточно легко можно перевести на Web-технологию - для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. Для разработки этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java.

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

Менеджеры транзакций

Особенностью многоуровневых архитектур является использование менеджеров транзакций (МТ), которые позволяют одному серверу приложений одновременно обмениваться данными с несколькими серверами баз данных. Хотя серверы Oracle имеют механизм выполнения распределенных транзакций, но если пользователь хранит часть информации в БД Oracle, часть в БД Informix, а часть в текстовых файлах, то без менеджера транзакций не обойтись. МТ используется для управления распределенными разнородными операциями и согласования действий различных компонентов информационной системы. Следует отметить, что практически любое сложное ПО требует использования менеджера транзакций. Например, банковские системы должны осуществлять различные преобразования представлений документов, т. е. работать одновременно с данными, хранящимися как в базах данных, так и в обычных файлах, - именно эти функции и помогает выполнять МТ.

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

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

Первые менеджеры транзакций появились в начале 70-х гг. (например, CICS); с тех пор они незначительно изменились идеологически, но весьма существенно - технологически. Наибольшие идеологические изменения произошли в коммуникационном менеджере, так как в этой области появились новые объектно-ориентированные технологии (CORBA, DCOM и т.д.). Из-за бурного развития коммуникационных средств в будущем следует ожидать широкого использования различных типов менеджеров транзакций.

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

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

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

Любое веб-приложение, если оно работает в браузере, работает на 3 основных технологиях: HTML, CSS и JS. Ещё есть WASM, но о нём в этой статье мы говорить не будем.

Все приложения, которыми вы пользуетесь в браузере: GoogleDocs, Notion, Яндекс.Карты, Spotify, YouTube — сделаны с помощью этих технологий.

Но любое сложное приложение — это не только картинка в браузере, это ещё и данные, которые пользователи используют или создают. Эти данные нужно уметь хранить, обрабатывать и выводить.

Хранением и обработкой данных обычно занимается сервер или бэкенд.

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

А архитектура, в которой участвуют сервер (бэкенд) и клиент (браузер, фронтенд) называется клиент-серверной.

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

Начнём с самого понятия.

Архитектура — это описание системы на самом высоком уровне.

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

Самый канонический вид такой архитектуры таков:

Клиент

Клиент обращается с запросами к серверу.

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

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

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

Для веба клиент почти всегда браузер.

Сервер

Сервер принимает запросы от клиента.

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

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

База данных

База данных (БД) — это хранилище всей пользовательской и служебной информации.

Её роль в том, чтобы обеспечивать быстрый и бесперебойный доступ к этой информации и собственно хранение.

Пример

Возьмём Твиттер. В этом приложении клиентом будет выступать весь его фронтенд: HTML-страницы, CSS-стили, JS-скрипты для взаимодействия пользователя с UI.

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

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

Развитие веб-приложений

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

Первые приложения

Самые первые веб-приложения не сильно отличались от обычных сайтов.

По сути это и были сайты, потому что вся бизнес-логика реализовывалась на сервере. Клиент лишь показывал результат в виде HTML-страниц пользователю и посылал запросы на другие страницы.

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

AJAX (Asynchronous JavaScript and XML) — общение между клиентом и сервером без перезагрузки страницы.

При нажатии браузер пошлёт запрос на сервер, в котором сообщит, что ему необходимо отсортировать такой-то список по такому-то критерию.

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

Заметьте, что мы всё ещё не передаём данные в чистом виде. Сейчас на клиенте мы принимаем кусок HTML-разметки, который потом встраиваем в нужное место в документе.

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

Современные приложения

В современных приложениях между клиентом и сервером общение строится именно на данных, а не на отрендеренных кусках разметки. Чаще всего для такого общения выбирают JSON.

Сейчас большая часть приложений работает так:

Плюсов такого общения (когда передаются только данные) несколько:

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

Разделение ответственности

Такое общение между сервером и клиентом очень напоминает паттерн MVC.

MVC (Model-View-Controller) — структура приложения, в которой за данные, их обработку и их вывод отвечают три разных сущности.

Модель (model) отвечает за данные и их структуру.
Представление (view) — за их отображение.
Контроллер (controller) — за их обработку.

Если попробовать сравнить классическую клиент-серверную архитектуру с MVC, то можно сравнить БД с моделью, сервер с контроллером, а клиент с представлением.

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

MVC на клиенте

Возьмём для примера Notion. Его веб-версия работает прямо в браузере, однако это полноценный текстовый редактор.

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

Одной из таких практик как раз является разделение данных и представления.

Как бы текстовый редактор сделали 20 лет назад

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

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

Текстовые редакторы сейчас

. чаще всего делают, разделяя данные от их представления.

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

Это делает работу с данными сильно проще — можно выгрузить документ в разных форматах: .md , .html , .txt .
С таким представлением проще работать в самом коде — отчего и сам код становится проще для понимания.
Его удобнее хранить в памяти, как состояние приложения.

Состояние приложения

Текстовый редактор из нашего примера выше — это приложение с состоянием.

Состояние приложения — это все данные этого приложения на текущий момент.

В случае с текстовым редактором — это весь текст, который пользователь ввёл, а также результаты преобразований над этим текстом.

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

Плюсы в выделении состояния те же:

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

Как правило, состояние в приложениях на JS — это какой-то объект или массив объектов в памяти.

Такой вид состояния не только удобен в использовании внутри приложения, но ещё и прост в сохранении с помощью JSON.

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

Сейчас есть много подходов и инструментов для управления состоянием. Из самых популярных можно назвать: Redux (и основанные на его подходе Vuex, NgRx), MobX, Overmind.

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

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

Состояние из примера выше в формате JSON выглядело бы так:

Запросы и ответы

Как мы помним, клиент-серверная архитектура строится на запросах и ответах. Разберёмся, что использует браузер, чтобы послать на сервер какой-то запрос.

fetch

На уровне приложения мы используем встроенное браузерное API, а именно — fetch . Это глобальный метод для отправки запросов.

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

Здесь мы отправляем запрос по адресу /api/save-text с телом JSON.stringify(State) . Адрес и тело (данные) — понятно, а что такое method: "POST" ?

Они указывают, какое действие мы хотим выполнить. В примере method: "POST" сообщит серверу, что мы хотим создать новый ресурс и сохранить в него содержимое body .

Если бы мы хотели получить какой-то ресурс, мы бы использовали GET . Для редактирования — PATCH , для замены — PUT , а для удаления — DELETE .

Описывать сам протокол мы не будем, это большая спецификация, для которой бы понадобилась отдельная статья.

REST (Representational State Transfer) — стиль общения компонентов, при котором все необходимые данные указываются в параметрах запроса.

Отличительная особенность этого стиля — это стиль построения адресов и выбор метода.

Как мы можем видеть, основа адреса не меняется, а желаемое действие выражается методом.

Сейчас именно на основе REST работает множество сервисов и приложений.

Развитие веба и объёмы данных

С развитием веба и интернета в целом пришло время больших объёмов данных. Картинки по 10 МБ уже никого не удивляют.

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

Кэширование

Отчасти решением стало кэширование ресурсов. С картинками это помогло — картинки из кэша не съедают трафик, потому что не гонятся по сети.

Со скриптами и стилями — помогло отчасти, потому что объём лишь одна часть проблемы. Вторая часть — это парсинг и исполнение. Особенно остро эта проблема стоит со скриптами, потому что скрипты весом в 10 МБ уже тоже не редкость.

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

Код-сплиттинг

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

Middle-end

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

REST известен не только своим удобством, но и (иногда) чрезмерной избыточностью.

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

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

Поэтому сейчас сообщество смотрит в сторону некого мидл-энда — такого слоя между клиентом и сервером (или сразу БД), который бы удалял всё лишнее, что клиенту не требуется, и отдавал бы лишь необходимые данные, таким образом сократив объём. Как, например, GraphQL.

Заключение

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

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

Эти понятия помогут вам понять работу большей части приложений, с которыми вы можете столкнуться.

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

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

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

Рис.1. Компоненты сетевого приложения

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

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

Автономная система (компьютер, не подключенный к сети) представляет все эти компоненты как на различных уровнях (ОС, служебное ПО и утилиты, прикладное ПО), так и на уровне приложений (не характерно для современных программ). Так же и сеть — она представляет все эти компоненты, но, в общем случае, распределенные между узлами. Задача сводится к обеспечению сетевого взаимодействия между этими компонентами.

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

Двухзвенная архитектура

В любой сети (даже одноранговой), построенной на современных сетевых технологиях, присутствуют элементы клиент-серверного взаимодействия, чаще всего на основе двухзвенной архитектуры. Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером).

Рис.2. Двухзвенная клиент-серверная архитектура

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

Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:

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

Перечисленные модели с вариациями представлены на рис. 3.

Рис.3. Модели клиент-серверного взаимодействия

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

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

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

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

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

Основной недостаток — ограниченность средств разработки хранимых процедур по сравнению с языками высокого уровня.

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

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

Трехзвенная архитектура

Рис.4. Трехзвенная клиент-серверная архитектура

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

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

Рис.5. Многозвенная (N-tier) клиент-серверная архитектура

Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier) путем выделения дополнительных серверов, каждый из которых будет представлять собственные сервисы и пользоваться услугами прочих серверов разного уровня. Абстрактный пример многозвенной модели приведен на рис. 5.

Сравнение архитектур

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

Трехзвенная архитектура сложнее, но благодаря тому, что функции распределены между серверами второго и третьего уровня, эта архитектура представляет:

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

Клиент-серверные технологии

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

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

Заключение

Понятие клиент-серверных систем

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

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

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

Архитектура клиент-сервер предъявляет специфические требования как к клиенту, так и к серверу. Программа, удовлетворяющая этим требованиям, может считаться клиент-серверным приложением, выполняющим распределенную обработку данных (рис. 6.5).

Рис. 6.5 Клиент, связывающийся с сервером по сети

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

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

Проектирование клиент-серверной системы

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

Стадии разработки

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

Рис. 6.6 Стадии проектирования клиент-серверной базы данных

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

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

Физическое решение

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

Перспектива

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

Особенности клиента

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

Особенности сервера

В состав серверной части должны входить основные исполняемые файлы, библиотеки и все остальные файлы, необходимые для поддержки доступа пользователей по сети. Кроме того, надо изучить требования к ресурсам сервера и на их основе принять решение относительно аппаратной конфигурации, учитывая тип процессора (например, SQL Server поддерживает процессоры Alpha AXP, MIPS и 32-разрядные процессоры семейства Intel x86) и ресурс памяти (чем больше клиентов, тем больше потребуется ОЗУ для сохранения и увеличения быстродействия).

Системы клиент-сервер

Рис. 6.7 Бизнес-логика реализована на клиенте

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

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

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

Рис. 6.8 Бизнес-логика реализована на центральном сервере

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

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

Смешанные системы

В рамках двухуровневой реализации возможны и смешанные варианты, обладающие достоинствами как интеллектуальных серверов, так и интеллектуальных клиентов (рис. 6.9). Например, клиентский компонент смешанного решения, разработанный средствами Visual Basic, может вызывать хранимые процедуры SQL Server.

Рис. 6.9 Смешанные системы: интеллектуальные клиенты и интеллектуальный сервер

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

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

Многоуровневые системы

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

Рис. 6.10 Пользовательский интерфейс, бизнес-правила и база данных размешены отдельно

В многоуровневой системе бизнес-правила реализуются как отдельные библиотеки (DLL). Их (например, написанные на Visual Basic) можно разместить на сервере. Клиент, библиотеки и база данных составляют распределенные сервисы многоуровневой системы.

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

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

Типы сервисов

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

Достоинства многоуровневых систем

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

Недостатки многоуровневых систем

Необходимы сервер и сеть. Увеличивается сетевой трафик.

Знаете ли Вы, что класс, Class - Класс в программировании - это множество объектов, которые обладают одинаковой структурой, поведением и отношением с объектами из других классов.

Читайте также: