В какой архитектуре используется большое количество серверов баз данных и серверов приложений
В предыдущей статье данного цикла, опубликованной в № 4’2000 нашего журнала, мы рассмотрели наиболее популярные настольные СУБД, такие как dBase, Paradox, FoxPro, Access, MSDE. Настоящая статья посвящена серверным СУБД — Oracle, Informix, DB2, Sybase, Microsoft SQL Server.
Прежде чем обратиться к конкретным продуктам, следует рассмотреть, что представляет собой архитектура «клиент-сервер», чем серверные СУБД отличаются от настольных и каковы общие черты современных серверных СУБД.
Архитектура «клиент-сервер»
Как было отмечено в предыдущей статье, обработка данных с помощью мэйнфреймов и мини-ЭВМ, популярная в 70-е годы, имела свои преимущества, в определенной степени утраченные позже, в эпоху персональных компьютеров и настольных СУБД. В частности, одним из таких преимуществ была централизация хранения и обработки данных. Однако повсеместное увлечение настольными СУБД и их сетевыми версиями, вызванное доступностью и дешевизной как самого программного обеспечения, так и его эксплуатации, заставило многих пользователей на долгие годы забыть о «мэйнфреймовой» модели вычислений.
Мы уже говорили о том, что недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики — это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используют для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос (это может быть одна или несколько таблиц целиком либо, если повезет, один или несколько индексов и выбранные с их помощью части таблиц), должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор столь популярны утилиты для «ремонта» испорченных файлов настольных СУБД.
Известно много случаев, когда для решения подобных проблем закупалось дорогое сетевое оборудование с целью увеличения пропускной способности сети, а также применялись иные «ухищрения» наподобие хранения метаданных или наиболее часто используемых данных в клиентских приложениях или просто на локальных жестких дисках. Нередко также применялся подход, приводящий к децентрализации хранения данных. Типичный пример подобного подхода — создание нескольких однотипных локальных баз данных, например для различных подразделений компании или для разных временных периодов (лет, кварталов, месяцев), что облегчало работу, связанную с вводом данных, но повышало стоимость их статистической обработки и анализа — в этом случае нужно было обрабатывать данные из разных источников. Однако все эти меры позволяли лишь отложить на время решение проблемы снижения производительности, но не устраняли главного недостатка информационных систем, основанных на настольных СУБД, — обработки данных в клиентском приложении.
Радикальным решением проблемы сетевого трафика и иных проблем, возникающих при увеличении объема данных и числа пользователей, стал переход к архитектуре «клиент-сервер», позаимствовавшей многие достоинства старой «мэйнфреймовой» модели вычислений, в частности централизацию хранения и обработки данных.
Принцип централизации хранения и обработки данных является базовым принципом архитектуры «клиент-сервер». Для его реализации используется так называемый сервер баз данных, выполненный как приложение или сервис операционной системы, и только он может реально манипулировать файлами, в которых хранятся данные, — для клиентских приложений эти файлы абсолютно бесполезны (и, при правильной организации доступа пользователей к файлам в сети, вообще не должны быть доступны).
Сервер баз данных осуществляет целый комплекс действий по управлению данными. Основными его обязанностями являются:
-
выполнение пользовательских запросов на выбор и модификацию данных и метаданных, получаемых от клиентских приложений, функционирующих на персональных компьютерах локальной сети;
В качестве рабочего места пользователя может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды. Иными словами, в простейшем случае клиент-серверная информационная система состоит из двух основных компонентов:
-
сервера баз данных, управляющего данными и выполняющего запросы клиентских приложений;
Существуют и более сложные реализации архитектуры «клиент-сервер», например многозвенные информационные системы с использованием серверов приложений, реализующих бизнес-логику и осуществляющих обработку данных. Однако обсуждение архитектуры таких систем находится за пределами данного обзора — о подобных системах мы, возможно, поговорим в конце данного цикла.
Преимущества архитектуры «клиент-сервер»
Информационные системы, использующие архитектуру «клиент-сервер», обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД. Ниже будут рассмотрены наиболее важные из них.
Одним из важнейших преимуществ архитектуры «клиент-сервер» является снижение сетевого трафика при выполнении запросов. Hапример, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен, компилируется, оптимизируется и выполняется. После этого результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно клиенту. При этом, формулируя запрос, можно не задумываться о том, есть ли в базе данных индексы, способные облегчить поиск нужных записей, — если они есть, то они будут использованы сервером, а если нет,запрос все равно будет выполнен, хотя, возможно, это займет больше времени, чем при использовании индексов. Но в любом случае — есть индексы или нет — в клиентское приложение передается только результат запроса, и в этом случае сетевой трафик не зависит ни от их наличия, ни от числа записей в таблицах, к которым произведен запрос.
Вторым преимуществом архитектуры «клиент-сервер» является возможность хранения бизнес-правил (например, правил ссылочной целостности или ограничений на значения данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Кроме того, в этом случае любое редактирование данных, в том числе и редактирование средствами, не предусмотренными разработчиками информационной системы (например, различными утилитами администрирования сервера), может быть произведено только с учетом этих правил. Если последние версии некоторых настольных СУБД и способны хранить ограничения на значения данных либо тексты SQL-запросов, триггеры и хранимые процедуры в них, как правило, отсутствуют — их просто некому выполнять. Исключением здесь, пожалуй, является только Microsoft Data Engine, но, как мы уже говорили в предыдущей статье данного цикла, отнести к настольным эту СУБД можно весьма условно — фактически MSDE представляет собой локальный сервер баз данных, обладающий всеми характерными для серверной СУБД атрибутами, включая отдельный серверный процесс.
В первой статье данного цикла (см. КомпьютерПресс 3’2000) мы уже упоминали о том, что для описания серверных бизнес-правил в наиболее типичных ситуациях (например, при реализации связей master/detail) нередко используются так называемые CASE-средства (CASE означает Computer-Aided System Engineering) для создания диаграмм «сущность-связь». Эти инструменты позволяют описать подобные правила на уровне логической и физической моделей данных без какого бы то ни было программирования, а затем сгенерировать код соответствующих серверных объектов — триггеров, хранимых процедур, серверных ограничений. В этом случае клиентские приложения будут избавлены от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще больше «облегчить» клиентское приложение, а это означает, что требования к рабочим станциям могут быть не столь высоки. Это в конечном итоге снижает стоимость информационной системы даже при использовании дорогостоящих серверной СУБД и аппаратного обеспечения.
Помимо перечисленных выше трех преимуществ следует также отметить, что современные серверные СУБД обладают широкими возможностями управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. Как правило, в базе данных хранятся сведения о ее пользователях, их паролях и привилегиях, а каждый объект базы данных принадлежит какому-либо пользователю. Владелец объекта может предоставить другим пользователям право использовать его тем или иным способом (например, позволить читать из него данные какому-либо другому пользователю). Большинство серверных СУБД поддерживает так называемые роли, представляющие собой совокупность прав на доступ к тем или иным объектам базы данных. В этом случае каждый пользователь может иметь одну или несколько ролей и соответственно определенные в этих ролях привилегии.
Современные серверные СУБД обладают также широкими возможностями резервного копирования и архивации данных, а нередко и оптимизации выполнения запросов. Они также, как правило, предоставляют возможность параллельной обработки данных, особенно в случае использования многопроцессорных компьютеров в качестве сервера баз данных.
Итак, мы рассмотрели преимущества архитектуры «клиент-сервер» и убедились, что эта технология решает многие проблемы, возникающие при использовании настольных СУБД. Однако перед тем, как обсуждать наиболее популярные серверные СУБД, давайте обратим внимание на то, какими способами решается проблема модернизации устаревших информационных систем, основанных на настольных СУБД, с целью перехода к архитектуре «клиент-сервер», и с какими проблемами можно при этом столкнуться.
Модернизация устаревших информационных систем
С проблемой модернизации устаревших информационных систем рано или поздно сталкивается почти каждый разработчик или IT-менеджер. В нашей стране все еще нетрудно встретить банковские системы, использующие dBase, а также относительно свежие коммерческие разработки, созданные с помощью Clipper, средством обмена данными которым служат отнюдь не Internet и не сетевые протоколы, а курьер с дискетами и электричка (это вовсе не всегда происходит из-за неосведомленности разработчиков — просто у их клиентов нет и в ближайшее время не будет денег на приличное оборудование и соответствующую инфраструктуру). Именно поэтому мы полагаем, что проблема модернизации информационных систем в России еще долго будет оставаться актуальной.
В целом варианты модернизации информационной системы можно условно разделить на следующие категории:
1. Замена СУБД с сохранением структуры базы данных и пользовательских приложений (или относительно небольшой их модернизацией).
2. Замена и СУБД, и пользовательских приложений с сохранением структуры базы данных.
3. Замена СУБД, пользовательских приложений и одновременная модернизация структуры базы данных.
На первый взгляд, первый вариант представляется наиболее безболезненным для пользователей и разработчиков, и он широко пропагандировался несколько лет назад. Именно в тот период на рынке программного обеспечения появились две категории продуктов, «обслуживающих» подобный вариант модернизации.
Первая категория представляла собой драйверы различных серверных СУБД для средств разработки, ориентированных в целом на использование настольных баз данных (например, драйверы Oracle для Clipper, преобразовывающие функции Clipper в вызовы функций клиентского API Oracle — Oracle Call Interface); обычно эти драйверы поставлялись в виде библиотек, компилируемых вместе с приложением. «Потомки» подобного программного обеспечения существуют и сейчас — одним из них является, например, библиотека Borland SQL Links, изначально предназначенная для использования приложений Paradox с серверными СУБД.
Вторая категория продуктов, ныне практически забытая, представляла собой некое подобие серверов баз данных, управлявших набором файлов настольных СУБД. Типичными примерами таких продуктов являлись разнообразные «dBase-серверы», управлявшие набором dBase-таблиц и перехватывавшие обращения к ним клиентских приложений. Подобные «серверы» в определенной степени решали проблему сетевого трафика и даже поддержки ссылочной целостности, но в силу ограничений, накладываемых на хранимый объем данных, характерных для форматов настольных СУБД, достаточно быстро уступили место «настоящим» серверам баз данных.
Если говорить о первом варианте модернизации, в этом отношении больше всего повезло пользователям Microsoft Access — процесс замены базы данных Microsoft Access на MSDE (или Microsoft SQL Server) происходит достаточно безболезненно, и пользовательские приложения при этом обычно сохраняют свою работоспособность. Так как в данном случае все эти СУБД (Access, MSDE и SQL Server) принадлежат одному производителю, перенос данных между ними осуществляется вполне корректно, с сохранением всех определенных в базе данных бизнес-правил. Кроме того, утилиты переноса данных из Access содержатся в комплекте поставки и других серверных СУБД (например, Oracle). Относительно безболезненно можно осуществить перенос данных из Visual FoxPro в Microsoft SQL Server.
Что касается замены других версий настольных СУБД на серверные, здесь могут возникнуть определенные проблемы. Например, при переносе данных из dBase или Paradox в какую-нибудь серверную СУБД обслуживающее их приложение, написанное на Delphi, вполне может отказаться работать даже после корректной перенастройки библиотек доступа к данным, особенно если оно содержит сведения о метаданных. Возможны также различные неприятности, связанные с использованием строчных и прописных букв в наименованиях полей, применением русских наименований полей (и вообще локализованных версий, поддерживающих национальные традиции написания чисел и дат и нередко превращающих числовые данные и даты в при переносе в другую СУБД в нечто невообразимое), несовместимости некоторых типов данных (это особенно часто происходит при переносе таблиц Paradox в другие СУБД). Наконец, если в серверной СУБД определены какие-либо бизнес-правила, нет никакой гарантии, что они идеально соблюдались в настольной СУБД, из которой переносятся данные, и в этом случае некоторое количество «ручного» труда по разбору данных, не соответствующих этим правилам, вам или вашим пользователям гарантировано.
Отметим, однако, что переход к архитектуре «клиент-сервер» отнюдь не исчерпывается переносом данных в новую СУБД. Чтобы воспользоваться всеми преимуществами этой архитектуры, следует также реализовать бизнес-правила, содержащиеся в клиентском приложении, в виде триггеров и хранимых процедур, а затем модифицировать код клиентского приложения, удалив реализацию бизнес-правил или заменив ее на обращения к соответствующим объектам базы данных. И если исходное клиентское приложение содержало код, отличный от чисто презентационного, было бы более чем наивно полагать, что оно не нуждается в модернизации, что бы ни говорилось в рекламе средств разработки по поводу масштабируемости созданных с их помощью приложений или о их независимости от СУБД. Как известно, реальные приложения очень отличаются от тех, что демонстрируются на выставках и презентациях.
Второй вариант модернизации информационной системы представляет собой по существу создание нового проекта по готовой модели данных плюс только что рассмотренный перенос данных в новую СУБД. Что касается третьего варианта модернизации, его можно рассматривать как два самостоятельных проекта. Первый из них представляет собой создание информационной системы практически «с нуля», второй — заполнение базы унаследованными данными. При этом, поскольку структуры баз данных различны, стандартными утилитами переноса данных (имеющимися в комплектах поставки многих средств разработки и серверных СУБД) здесь обычно обойтись не удается — как правило, в этом случае создаются «одноразовые» приложения, производящие нужные преобразования данных в процессе их переноса.
Обсудив проблемы, возникающие при переносе информационных систем, использовавших настольные СУБД, в архитектуру «клиент-сервер», можно перейти к обсуждению того, какие сервисы предоставляют современные серверные СУБД и чем с этой точки зрения следует руководствоваться при их выборе.
Цель лекции: показать основные варианты технологии работы нескольких пользователей с одной базой данных, связанные как с основными свойствами вычислительной техники, так и с развитием программного обеспечения.
Как уже отмечалось, понятие базы данных изначально предполагало возможность решения многих задач несколькими пользователями. В связи с этим, важнейшей характеристикой современных СУБД является наличие многопользовательской технологии работы. Разная реализация таких технологий в разное время была связана как с основными свойствами вычислительной техники, так и с развитием программного обеспечения. Дадим краткую характеристику этих технологий в хронологическом порядке.
3.1. Централизованная архитектура
При использовании этой технологии база данных , СУБД и прикладная программа ( приложение ) располагаются на одном компьютере (мэйнфрейме или персональном компьютере) (рис.3.1.). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе. Работа построена следующим образом:
- База данных в виде набора файлов находится на жестком диске компьютера.
- На том же компьютере установлены СУБД и приложение для работы с БД .
- Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
- Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.
- СУБД инициирует обращения к данным, обеспечивая выполнение запросов пользователя (осуществляя необходимые операции над данными).
- Результат СУБД возвращает в приложение.
- Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Подобная архитектура использовалась в первых версиях СУБД DB2 , Oracle , Ingres [ [ 3.1 ] ].
Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнение их программ). Такая технология была распространена в период "господства" больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей.
3.2. Технология с сетью и файловым сервером (архитектура "файл-сервер")
Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры файл-сервер . Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных [ [ 3.2 ] ]. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных ( рис. 3.2.).
Работа построена следующим образом:
- База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).
- Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.
- На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
- Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.
- СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).
- При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.
- Результат СУБД возвращает в приложение.
- Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
В рамках архитектуры " файл-сервер " были выполнены первые версии популярных так называемых настольных СУБД , таких, как dBase и Microsoft Access.
В литературе [ [ 3.2 ] ] указываются следующие основные недостатки данной архитектуры:
Архитектура «Клиент-Сервер» (также используются термины «сеть Клиент-Сервер» или «модель Клиент-Сервер») предусматривает разделение процессов предоставление услуг и отправки запросов на них на разных компьютерах в сети, каждый из которых выполняют свои задачи независимо от других.
В архитектуре «Клиент-Сервер» несколько компьютеров-клиентов (удалённые системы) посылают запросы и получают услуги от централизованной служебной машины – сервера (server – англ. «официант, обслуга»), которая также может называться хост-системой (host system, от host – англ. «хозяин», обычно гостиницы).
Клиентская машина предоставляет пользователю т.н. «дружественный интерфейс» (user-friendly interface), чтобы облегчить его взаимодействие с сервером.
Рис. 1. Архитектура «Клиент-Сервер».
Типы клиент-серверной архитектуры
Архитектуру «клиент-сервер» принято разделять на три класса: одно-, двух- и трёхуровневую. Однако, нельзя сказать, что в вопросе о таком разделении в сообществе ИТ-специалистов существует полный консенсус. Многие называют одноуровневую архитектуру двухуровневой и наоборот, то же можно сказать о соотношении двух- и трёхуровневой архитектур.
Постараемся внести ясность в этот вопрос.
Одноуровневая архитектура (1-Tier)
Одноуровневая архитектура «клиент-сервер» (1-Tier) – такая, где все прикладные программы рассредоточены по рабочим станциям, которые обращаются к общему серверу баз данных или к общему файловому серверу. Никаких прикладных программ сервер при этом не исполняет, только предоставляет данные.
Рис. 2. Одноуровневая архитектура «клиент-сервер» (1-Tier).
В целом, такая архитектура очень надёжна, однако, ей сложно управлять, поскольку в каждой рабочей станции данные будут присутствовать в разных вариантах. Поэтому возникает проблема их синхронизации на отдельных машинах. В общем, как можно видеть из рисунка, в этой архитектуре просматривается ещё один уровень – базы данных, что даёт повод во многих случаях называть её двухуровневой.
Двухуровневая архитектура (2-Tier)
К двухуровневой архитектуре «клиент-сервер» следует относить такую, в которой прикладные программы сосредоточены на сервере приложений (Application Server), например, сервере 1С или сервере CRM, а в рабочих станциях находятся программы-клиенты, которые предоставляют для пользователей интерфейс для работы с приложениями на общем сервере.
Рис. 3. Двухуровневая архитектура «клиент-сервер» (2-Tier).
Такая архитектура представляется наиболее логичной для архитектуры «клиент-сервер». В ней, однако, можно выделить два варианта. Когда общие данные хранятся на сервере, а логика их обработки и бизнес-данные хранятся на клиентской машине, то такая архитектура носит название “fat client thin server” (толстый клиент, тонкий сервер). Когда не только данные, но и логика их обработки и бизнес-данные хранятся на сервере, то это называется “thin client fat server” (тонкий клиент, толстый сервер). Такая архитектура послужила прообразом облачных вычислений (Cloud Computing).
Преимущества двухуровневой архитектуры:
- Легко конфигурировать и модифицировать приложения;
- Пользователю обычно легко работать в такой среде;
- Хорошая производительность и масштабируемость.
Однако, у двухуровневой архитектуры есть и ограничения:
- Производительность может падать при увеличении числа пользователей;
- Потенциальные проблемы с безопасностью, поскольку все данные и программы находятся на центральном сервере;
- Все клиенты зависимы от базы данных одного производителя;
Трёхуровневая архитектура (3-Tier)
В трёхуровневой архитектуре сервер баз данных, файловый сервер и другие представляют собой отдельный уровень, результаты работы которого использует сервер приложений. Логика данных и бизнес-логика находятся в сервере приложений. Все обращения клиентов к базе данных происходят через промежуточное программное обеспечение (middleware), которое находится на сервере приложений. Вследствие этого, повышается гибкость работы и производительность.
Рис. 4. Трёхуровневая архитектура «клиент-сервер» (3-Tier).
Преимущества трёхуровневой архитектуры:
- Целостность данных;
- Более высокая безопасность, по сравнению с двухуровневой архитектурой;
- Защищённость базы данных от несанкционированного проникновения.
- Более сложная структура коммуникаций между клиентов и сервером, поскольку в нём также находится middleware.
Многоуровневая архитектура (N-Tier)
В отдельный класс архитектуры «клиент-сервер» можно вынести многоуровневую архитектуру, в которой несколько серверов приложений используют результаты работы друг друга, а также данные от различных серверов баз данных, файловых серверов и других видов серверов.
По сути, предыдущий вариант, трёхуровневая архитектура – не более, чем частный случай многоуровневой архитектуры.
Рис. 5. Многоуровневая архитектура «клиент-сервер» (N-Tier).
Преимуществом многоуровневой архитектуры является гибкость предоставления услуг, которые могут являться комбинацией работы различных приложений серверов разных уровней и элементов этих приложений.
Очевидным недостатком является сложность, многокомпонентность такой архитектуры.
Характеристики архитектуры «клиент-сервер»
Практические применения архитектуры «клиент-сервер»
Архитектуры «клиент-сервер» - один из основных принципов работы сети Интернет. Любой веб-сайт, или приложение в Интернет работает на сервере, а его пользователи являются клиентами. Социальные сети (Фейсбук, ВК и пр.), сайты электронной коммерции (Amazon, Озон и др.) , мобильные приложения (Instagram и т.д.), устройства Интернета вещей (умные колонки или смарт-часы) работают на основе клиент-серверной архитектуры.
Хорошим примером работы системы «клиент-сервер» является автомобильный навигатор. Приложение навигации на сервере собирает данные с многих смартфонов пользователей, на которых установлены клиенты приложения. Кроме того, приложение навигации использует ещё и данные с сервера базы данных – геоинформационной системы, который предоставляет данные, например, о текущих ремонтах дорог, о появлении новых дорог и пр. Данные со многих клиентов (местоположение, скорость) обрабатывается сервером навигации и выдаётся на смартфоны пользователей в виде информации о средней скорости движения по тому или иному участку маршрута.
Практически любая корпоративная сеть или ИТ-система предприятия, как правило, строится по архитектуре «клиент-сервер». В небольших сетях (3-5 компьютеров в компании) функции сервера может выполнять один из рабочих компьютеров. Если число машин в организации более 10, то лучше сделать выделенный сервер (почтовый сервер, приложений, баз данных и пр.), который будет заниматься обслуживанием клиентов – компьютеров и телефонов сотрудников организации.
В домашних сетях архитектура «клиент-сервер» тоже используется довольно часто. Например, в домашнюю сеть могут быть объединены компьютеры членов семьи, один из которых выполняет функции сервера. В домашнюю сеть также могут быть включены такие устройства, как умные колонки, умные домашние устройства (пылесосы-роботы, фотоаппараты, DVD-плееры и пр.), а также «умные» счётчики (вода, электричество) и т.д. Тогда в системе управления сервера, будут видны все параметры, данные и медифайлы (музыка, видео, фото), а также «умные устройства».
Преимущества и недостатки архитектуры «клиент-сервер»
К преимуществам архитектуры «клиент-сервер» можно отнести:
- Централизованность, поскольку все данные и управление сосредоточены в центральном сервере;
- Информационная безопасность, поскольку ресурсы общего пользования администрируются централизованно;
- Производительность, использование выделенного сервера повышает скорость работы ресурсов общего пользования;
- Масштабируемость, количество клиентов и серверов можно увеличивать независимо друг от друга.
К недостаткам архитектуры «клиент-сервер» следует отнести:
- Перегрузку трафика в сети, что является главной проблемой в сетях «клиент-сервер». Когда большое число клиентов одновременно запрашивают одну услугу на сервере, то число запросов может создать перегрузку в сети;
- Наличие единой точки отказа в небольших сетях с одним сервером. Если он отказывает, все клиенты остаются без обслуживания;
- Превышение пределов ресурсов сервера, когда новые клиенты, запрашивающие услугу, остаются без обслуживания. В таких случаях, требуется срочное расширение ресурсов сервера;
- Иногда клиентские программы могут не работать на терминалах пользователей, если не установлены соответствующие драйверы. Например, пользователь посылает запрос на печать документа, а на сервере нет подходящего драйвера для печати данного формата документа на определённом принтере.
Заключение
В настоящее время можно встретить термин Serverless Architecture, т.н. «бессерверная архитектура». Однако, по сути, она представляет собой процесс получения функций сервера в виде облачной услуги. То есть, серверы в облаке тоже есть, но для конечного пользователя они не видны, и он получает их сервисы в виде абстрактной «функции как услуги» FaaS (Function as a Service).
Архитектура «клиент-сервер» является основой большинства корпоративных сетей и берёт свое начало от самых первых вычислительных машин, т.н. «мэйнфреймов». Программное обеспечение для локальных компьютерных сетей, подавляющее большинство которых основано на архитектуре «клиент-сервер», начало создаваться около 50 лет назад.
Дальнейшее развитие информационных технологий также будет происходить в значительной степени с использованием архитектуры «клиент-сервер».
Клиент-серверная архитектура
Составляющие клиент-серверной архитектуры
Клиент — из названия становится понятно, что это пользователь сервиса (веб-приложения), который обращается к серверу для получения какой-то информации.
Сеть — все просто: обеспечивает обмен информацией между клиентом и сервером.
Трехуровневая архитектура
Клиентский слой — интерфейс пользователя. Это может быть веб-браузер, которому отправляются HTML-страницы, или графическое приложение, написанное с помощью JavaFX. Главное, чтобы с его помощью пользователь мог отправлять запросы на сервер и обрабатывать его ответы.
Слой данных — сервер баз данных: к нему обращается наш сервер. В этом слое сохраняется вся необходимая информация, которой пользуется приложение при работе.
Преимущества трехуровневой архитектуры
Возможность построить защиту от SQL-инъекций — это атака на сервер, при которой передается SQL-код, и при выполнении этого кода злоумышленник может воздействовать на нашу базу данных.
Разграничение данных, к которым мы хотим регулировать пользовательский доступ.
Возможность модифицировать данные перед отправкой клиенту.
Масштабируемость — возможность расширить наше приложение на несколько серверов, которые будут использовать одну и ту же базу данных.
Меньшие требования к качеству соединения пользователя. Формируя ответ на сервере, мы часто берем из базы данных много различной информации, форматируем ее, оставляя только то, что нужно юзеру. Таким образом мы сокращаем объем информации, который отправим в качестве ответа клиенту.
Читайте также: