В многоуровневой архитектуре сервер приложений

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

В последнее время многоуровневая ( multitier ) архитектура пользуется все большей популярностью, поскольку имеет массу преимуществ перед файл-серверными или клиент-серверными приложениями. Такая архитектура в различных публикациях также называется многозвенной, или распределенной архитектурой. Суть многоуровневой архитектуры в том, что помимо сервера БД и приложений-клиентов дополнительно присутствует еще один или несколько серверов приложений. Сервер приложений является промежуточным уровнем, обеспечивающим организацию взаимодействия клиентов и сервера БД . Сервер приложений также называют брокером данных ( broker — посредник). Чаще всего используют трехуровневую модель. Прежде, чем мы двинемся дальше, давайте разберемся, что же такое уровень. Имеется три основных уровня:

• Уровень данных. Этот уровень отвечает за хранение данных. Как правило, для этого уровня выделяется отдельный ПК, на котором устанавливают один из SQL -серверов, например, InterBase . Клиентские ПК непосредственно не имеют никакой связи с этим уровнем.
• Бизнес-уровень. Этот уровень предназначен для получения данных с уровня данных, выполнения окончательной проверки данных, и служит посредником между клиентами и данными. Как правило, сервера приложений находятся именно на этом уровне.
• Уровень представления данных. Этот уровень известен так же, как уровень графического интерфейса пользователя. На этом уровне полученные данные отображаются в таких компонентах вывода данных, как DBGrid , DBEdit , DBMemo и проч. Разумеется, этот уровень находится на клиентских ПК.

Взгляните на рисунок:

На рисунке представлены три уровня архитектуры: так называемый, «тонкий» клиент ( thin-client ), сервер приложений и сервер данных. На ПК сервера БД вместе с данными расположен один из SQL -серверов. Как видите, на клиентском ПК, помимо компонентов доступа к данным, располагается только компонент связи с сервером приложений, а довольно громоздкие механизмы доступа к данным отсутствуют. Из-за этого клиентское приложение и называется «тонким» клиентом. Такой подход не только облегчает распространение приложений, но и позволяет в качестве клиентских ПК использовать дешевые, неприхотливые компьютеры. На сервере приложений вы можете видеть область, обозначенную как » Интерфейс IAppServer «. Этот интерфейс обеспечивается специальным удаленным модулем данных, о котором дальше мы поговорим подробней. Интерфейс IAppServer используют компоненты-провайдеры TDataSetProvider на стороне сервера приложений, и компоненты TClientDataSet на стороне клиента.

При небольшом количестве клиентов ничто не мешает нам отказаться от использования SQL -сервера, расположив данные на самом сервере приложений, и используя к ним обычный локальный доступ через механизм BDE , ADO и т.п. При этом можно использовать обычные таблицы Paradox или MS Access , например. Такой подход удобней, чем файл -серверная архитектура , поскольку позволяет не только «облегчить» пользовательское приложение , но и обеспечивает безопасность данных . Ведь пользователи не будут иметь прямого доступа к самим данным, обмен информацией будет происходить через посредника, как на рисунке ниже:

Несмотря на кажущуюся сложность архитектуры, организовать такую модель достаточно просто. Delphi для этого предлагает технологию DataSnap (в старых версиях Delphi эта технология называлась MIDAS — Multi-tier Distributed Applications Services — Серверы многозвенных распределенных приложений ). Благодаря этой технологии, вы сможете создать простой сервер приложений буквально за минуту, не введя ни строчки кода.

Преимущества многоуровневых моделей

• Централизованная бизнес-логика. Как мы уже знаем, бизнес-логикой называют некоторые правила обработки данных. Например, удаляя запись из одной таблицы, требуется удалить связанные с ней записи других таблиц. В обычных файл-серверных или клиент-серверных приложениях, часть бизнес-логики ложилась на клиентское приложение. При необходимости изменения каких-то правил, приходилось переделывать клиентское приложение, затем тратить усилия на его распространение на клиентские ПК. Теперь же эта бизнес-логика хранится на уровне сервера приложений, и при ее изменении клиенты сразу получают возможность работать по новым правилам.
• Архитектура «тонкого» клиента.Как известно, для получения данных из БД приложения используют один из механизмов доступа к данным — BDE , ADO , ODBC , IBX , dbExpress и т.п. Все это приводит к тому, что на ПК каждого клиента приходится устанавливать и настраивать соответствующие драйверы, а это сильно усложняет процесс распространения приложения. В многозвенной архитектуре механизмы доступа к данным располагаются на сервере приложений. Только там нужно устанавливать эти драйверы (например, BDE ). Клиентские же машины не нуждаются в них, за что и называются «тонкими».
• Модель «портфеля» (briefcase model).Модель «портфеля» подразумевает возможность отложенной обработки данных. Представьте, что вам в выходные дни требуется проделать какую-то работу с данными. При использовании файл-серверной или клиент-серверной модели, вам для этой работы придется прибыть в офис, иначе вы не сможете получить доступа к данным. В многоуровневой модели вы можете сохранить на переносном ПК все необходимые вам данные в виде локального файла. Дома вы сможете загрузить этот файл, и провести необходимую работу с данными. Затем, прибыв в офис, вы сможете перенести эти изменения в реальную базу данных.
• Снижение трафика сети. За счет возможности отложенной обработки данных значительно снижается нагрузка на сеть.

Сервер приложений

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

Delphi поддерживает следующие технологии удаленного доступа:

• DCOM ( Distributed Component Object Model — Распределенная компонентная модель объектов) Модель рассчитана на локальную сеть и позволяет использовать объекты, расположенные на другом ПК. Если клиентское приложение работает под управлением Windows 95 (что маловероятно в настоящее время), то придется также установить поддержку DCOM95 , остальные версии Windows в этом не нуждаются. Поскольку модель является «родной» для ОС Windows , использовать ее довольно просто. Вероятно, наиболее популярная модель на сегодняшний день.
• Сокеты — позволяют использовать сеть по протоколу TCP/IP . Эта модель, пожалуй, дает наиболее быстрое соединение, однако имеется ряд замечаний. Во-первых, программисту приходится прилагать дополнительные усилия для организации связи и слежением за возможными ошибками. Во-вторых, чтобы можно было загрузить сервер приложений, сначала на компьютере с этим сервером нужно загрузить утилиту SCKTSRVR.EXE. Эта утилита устанавливается вместе с Delphi и по умолчанию находится в папке C:PROGRAM FILESBORLANDDELPHIBIN. При загрузке программы ее ярлык появляется в трее (в правом нижнем углу экрана), и с этого момента клиентские ПК смогут соединяться с этим сервером. Обычно запуск этой утилиты прописывают на сервере в автозагрузке.
• MTS ( Microsoft Transaction Server — Сервер транзакций Microsoft ) — основана на DCOM и имеет некоторые дополнительные возможности.
• CORBA ( Common Object Request Broker Architecture — Общедоступная архитектура брокеров при запросе объектов).
• SOAP ( Simple Object Access Protocol — Простой протокол доступа к объекту.)

Загрузите Delphi и начните новый проект. Главная форма нам совсем не понадобится, назовите ее fMain , в свойстве Caption напишите » Сервер приложений «, уменьшите ее размер (например, Height =120, W >Main , а проекту в целом — MyNewServer . Основой сервера является удаленный модуль данных, который обеспечивает связь сервера с клиентами, а также является контейнером для размещения компонентов, вроде обычного Data Module. Delphi позволяет использовать следующие удаленные модули:

• Remote Data Module — используется для серверов DCOM , сокетов и OLEnterprise ;
• Transactional Data Module — используется для сервера MTS ;
• CORBA Data Module — для сервера CORBA ;
• SOAP Data Module — для сервера SOAP ;
• WebSnap Data Module — использует Web -службы и Web -броузер в качестве сервера.

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

Важно! Следует знать, что обмен данными между сервером приложений и «тонкими» клиентами обеспечивается динамической библиотекой Midas.dll, которая должна быть зарегистрирована на компьютере сервера приложений.

Мы будем использовать технологию DCOM , поэтому выберите команду меню File -> New -> Other, чтобы открыть окно депозитария Delphi . Перейдите на вкладку Multitier и выберите Remote Data Module . Откроется окно мастера создания удаленного модуля данных:

В первом поле » Co >MyRDM . Следующие два поля требуют более детального изучения.

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

• Internal — при такой модели сервер COM не сможет создаваться из внешних приложений. Используется редко, в основном, когда нужно управлять доступом с помощью промежуточного уровня прокси.
• Single Instance — при выборе этой модели для каждого клиентского соединения будет создан свой экземпляр сервера.
• Multiple Instance — в этой модели все клиентские соединения используют единый экземпляр сервера.

В этом поле оставляем способ по умолчанию Multiple Instance.

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

• Single (Одиночная) — для клиентов выделяется один поток, все клиенты работают последовательно. Выбор такой модели может оказаться неудачным в многопользовательской среде, и используется редко.
• Apartment (Раздельная) — для каждого клиента создается собственный поток. В сочетании с Multiple Instance этот способ дает самые высокие результаты и наиболее часто применяется.
• Free (Свободная) — один экземпляр модуля данных может одновременно отвечать на несколько запросов клиентов, используя разные потоки.
• Both (Оба) — объединяет модели Free и Apartment .
• Neutral (Нейтральный) — разные клиенты могут одновременно вызвать удаленный модуль данных из нескольких потоков, при этом модель COM следит, чтобы не было конфликта вызовов. Однако может возникнуть конфликт потоков, который отслеживается только в версии COM+ . При отсутствии этой версии нужно использовать модель Apartment .

В этом поле оставляем модель по умолчанию Apartment.

В многоуровневой архитектуре сервер приложений

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

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

С уважением,
команда разработчиков eManual.ru

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

С. Орлик, Borland

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

Попытаемся разбить систему на функциональные фрагменты 2).

На верхнем уровне абстрагирования достаточно четко можно выделить следующие компоненты: презентационная логика (Presentation Layer — PL); бизнес-логика (Business Layer — BL); логика доступа к ресурсам (Access Layer — AL).

Таким образом можно, можно придти к нескольким моделям клиент-серверного взаимодействия 1): «Толстый» клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL (см. Выше). Серверная часть, при описанном подходе, представляет собой сервер баз данных 2)., реализующий AL. К описанной модели часто применяют аббревиатуру RDA — Remote Data Access. «Тонкий» клиент. Модель 3), начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL. Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL.

1).Хотя, рассматриваемые в этой части варианты разделения функциональности между клиентом и сервером являются «классическими», далее будет использоваться не только устоявшаяся традиционная, но и более новая терминология, возникшая вследствие распространения в корпоративных средах Internet/intranet-технологий и стандартов.
2). Хотя в качестве серверной части, в общем случае, выступает менеджер доступа к информационным ресурсам, в этой статье будет сохраняться ориентация на серверы баз данных, как оконечное серверное звено.
3). Модели, основанные на Internet-технологиях и применяемые для построения внутрикорпоративных систем получили название intranet. Хотя intranet-системами сегодня называют все, что так или иначе использует стек протоколов TCP/IP, с ними скорее следует связать использование Web-браузеров в качестве клиентских приложений. При этом важно отметить тот факт, что броузер не обязательно является HTML-«окном», но, в не меньшей степени, представляет собой универсальную среду загрузки объектных приложений/компонент -Java или ActiveX.

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

Посмотрим на то, что же происходит в реальной жизни.

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

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

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

Таким образом, мы приходим к анализу существующих распределенных объектных моделей. На настоящий момент наибольшей проработанностью отличаются COM/DCOM/ ActiveX и CORBA/DCE/Java. Если в первом случае требуемые механизмы поддержки модели являются неотъемлемой частью операционной платформы Win32 (Windows 95/NT/CE), то во втором случае предусмотрена действительная кроссплатформенность (например, везде, где есть виртуальная машина Java). Если попытаться объективно оценить (хотя любая такая попытка во многом субъективна) перспективы применения этих моделей, то для этого необходимо понять требования к операционным платформам, выдвигаемые различными функциональными компонентами системы. При построении реальных систем корпоративного масштаба уже мало обходиться их разделением на три базовых фрагмента PL, BL, AL. Так как бизнес-логика является блоком, наиболее емким и специфичным для каждого проекта, именно ее приходится разделять на более мелкие составляющие. Такими составляющими могут быть, например, функциональные компоненты обработки транзакций (Transaction Process Monitoring), обеспечения безопасности (Security) при наличии разграничения прав доступа и выходе в Internet (Fire-wall), публикование информации в Internet (Web-access), подготовки отчетов (Reporting), отбора и анализа данных в процессе принятия решений (Decision Support), асинхронного уведомления о событиях (Event Alerts), тиражирования данных (Replication), почтового обмена (Mailing) и др. Вследствие наличия такого огромного количества функций, закладываемых в блоки поддержки бизнес-логики, появляется понятие сервера приложений (Application Server — AS). Причем, сервер приложений не просто является некоим единым универсальным средним BL-звеном между клиентской и серверной частью системы, но AS существует во множественном варианте, как частично изолированные приложения, выполняющие специальные функции, обладающие открытыми интерфейсами управления и поддерживающие стандарты объектного взаимодействия.

Проникновение информационных технологий в сферу бизнеса в качестве неотъемлемого условия успешного управления приводит к тому, что системы корпоративных масштабов требуют сочетания различных клиент-серверных моделей в зависимости от задач, решаемых на различных конкретных направлениях деятельности предприятия. Вспомнив, снова, о правиле 20/80 можно придти к выводу, что наиболее оптимальным выбором, с точки зрения управляемости и надежности системы, является сочетание различных моделей взаимодействия клиентской и серверной части. По сути, мы приходим даже не к трех-уровневой, а многоуровневой (N-tier) модели, объединяющей различных по «толщине» клиентов, серверы баз данных и множество специализированных серверов приложений, взаимодействующих на базе открытых объектных стандартов. Существенным облегчением в реализации многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного ПО. В отличие от продуктов middleware, обеспечивающих верхний транспортный уровень (универсальные интерфейсы доступа к данным ODBC, JDBC, BDE; Message Oriented Middleware — MOM; Object Request Broker — ORB; . ) , переходное ПО отвечает за трансляцию вызовов в рамках одного стандарта обмена в вызовы другого — мосты ODBC/JDBC и BDE/ODBC, COM/CORBA, Java/ActiveX и т.п.

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

Многоуровневая клиент-серверная модель

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

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

Эволюция многоуровневой модели «от клиента», на примере Borland Delphi

Концептуально, архитектура Delphi ориентирована на использование цепочек объектов «DataControl — DataSource — DataSet», то есть «элементы пользовательского интерфейса — компоненты перенаправления ввода/вывода — компоненты доступа к данным». Введение в Delphi 2, на равне с формами, контейнеров невизуальных компонент — модулей данных (Data Modules) — обеспечило использование трехуровневой логической модели в рамках одного приложения. На основе поддержки технологии DCOM, Delphi 3 предоставляет возможности создания автономных модулей данных, доступ к которым осуществляется из нескольких клиентских приложений, содержащих в себе только PL. Соответственно, появились и компоненты поддержки транспортного уровня (TL) объектного взаимодействия клиента и сервера приложений RemoteServer и Provider, а множества данных (DataSets) — таблицы (Table), запросы (Query) и хранимые процедуры (Query), связанные с конкретной бизнес-логикой, оказались реально перенесенными на сервер приложений и подмененными на клиенте виртуальным множеством данных Client DataSet. Соответственно, клиент «утоньшился» и на интерфейс доступа к данным BDE (Borland Database Engine), что позволяет уменьшить ресурсоемкость клиентского места, с одной стороны, и увеличить управляемость системой с точки зрения администратора, с другой.

Логическая структура организации сервера приложений с использованием удаленного модуля данных (Remote DataModule) в распределенной архитектуре Delphi 3

Логическая структура организации «тонкого клиента» в распределенной архитектуре Delphi 3

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

МИГКУ ИТ-51вс

Метки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами

• 28.07.2016
• Сервера и протоколы
• Комментариев нет

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

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

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

Концепция взаимодействия клиент-сервер

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

Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).

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

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

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

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

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

Простая схема взаимодействия клиент-сервер

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

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

Почему веб-мастеру нужно понимать модель взаимодействия клиент-сервер

Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?». Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.

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

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

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

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

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

Двухуровневая модель взаимодействия клиент-сервер

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер). Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.

Многоуровневая архитектура взаимодействия клиент-сервер

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

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

Преимущества и недостатки архитектуры клиент-сервер

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

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

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