Что такое клиент серверная архитектура тонкий и толстый клиент микросервисная архитектура
С. Орлик, Borland
Говоря о прикладных системах, предназначенных для работы с базами данных, чаще всего на ум приходит модель вычислений, основанная на двух взаимодействующих компонентах - клиенте, отвечающем за организацию диалога с пользователем и несущем на себе бизнес-логику, и сервере, обеспечивающем многопользовательскую работу с данными и их целостность. Описанная таким образом архитектура клиент-сервер является более фундаментальным явлением, чем просто способ построения приложений a-la "многопользовательская бухгалтерия". На нынешнем уровне зависимости бизнеса от информационных систем разработчикам приходится сталкиваться не только с задачами реализации адекватных техническим требованиям функциональности и пользовательского интерфейса, но и с оптимизацией обмена данным между различными компонентами системы. Учитывая, что корпоративные системы обладают достаточно высоким уровнем сложности, в процессе их эксплуатации возникает ряд вопросов связанных с надежностью и управляемостью такой системы. Появление такого рода акцентов в процессе проектирования и разработки корпоративных систем приводит к необходимости решения следующей важной задачи - выделения из клиентской и серверной части системы компонентов, несущие на себе строго определенную служебную функциональность.
Попытаемся разбить систему на функциональные фрагменты 2) .
- презентационная логика (Presentation Layer - PL);
- бизнес-логика (Business Layer - BL);
- логика доступа к ресурсам (Access Layer - AL).
- "Толстый" клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как 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
Тема построения многоуровневых клиент-серверных систем, наконец, стала уделом не только архитекторов, но и разработчиков. Многое из того, что казалась красивым и легким в теории, иногда оказывается нереализуемым на практике. Многоуровневые системы клиент-сервер уже доказывают свою жизнеспособность. Вероятно, пришло время начать их более детальное описание. Этот материал затронул только два взаимосвязанных подхода - серверов приложений и "многоуровневости от клиента", приводящих к системам с распределенной бизнес-логикой. Надеюсь, что это хорошая тема для детализации.
Типы клиентов в системе клиент-сервер
Толстый клиент, rich client архитектуре клиент-сервер — это приложение, обеспечивающее (в противовес тонкому клиенту) полную функциональность и независимость от центрального сервера. Часто сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента.
Толстый клиент обладает полной функциональностью работы с данными сервера, обеспечивает режим многопользовательской работы, предоставляет возможность работы даже при обрывах связи с сервером, имеет возможность подключения к банкам данных без использования сети Интернет, обладает высоким быстродействием.
Однако широкие функциональные возможности "толстого клиента" часто несовместимы с политикой безопасности информационной системы и стоимость его чрезмерно высока.
При работе с ним возникают проблемы с удаленным доступом к данным, выражающиеся в сложности обновления данных, согласования их с другими клиентами и связанной с этим неактуальностью данных.
Как правило "толстый клиент" имеет довольно сложный процесс установки и настройки.
Тонкий клиент
Тонкий клиент, thin client в компьютерных технологиях — компьютер или программа-клиент в сетях с клиент-серверной или терминальной архитектурой, где большая часть задач по обработке информации перенесена на сервер и права доступа клиента строго ограничены. Примером тонкого клиента может служить компьютер с браузером, использующийся для работы с веб-приложениями.
Web-клиенты
Программный Web-клиент, WEB client как программа — браузер.
Аппаратный Web-клиент - устройство, основным и часто единственным приложением которого (с точки зрения разработчика устройства или маркетолога является браузер.
Тонкие клиенты, работающие в терминальном режиме
Под термином “тонкий клиент” подразумевается достаточно широкий с точки зрения системной архитектуры ряд устройств и программ, которые объединяются общим свойством: возможность работы в терминальном режиме. Таким образом, для работы тонкого клиента необходим терминальный сервер. Этим тонкий клиент отличается от толстого клиента, который, напротив, производит обработку информации независимо от сервера, используя последний в основном лишь для хранения данных.
Кроме общего случая, следует выделить аппаратный тонкий клиент (например, Windows- и Linux-терминалы) — специализированное устройство, принципиально отличное от ПК. Аппаратный тонкий клиент не имеет жёсткого диска, использует специализированную локальную ОС (одна из задач которой организовать сессию с терминальным сервером для работы пользователя), не имеет в своём составе подвижных деталей, выполняется в специализированных корпусах с полностью пассивным охлаждением.
Для расширения функциональности тонкого клиента прибегают к его “утолщению”, например, добавляют возможности автономной работы, сохраняя главное отличие — работу в сессии с терминальным сервером. Когда в клиенте появляются подвижные детали (жёсткие диски), появляются возможности автономной работы, он перестаёт быть тонким клиентом в чистом виде, а становится универсальным клиентом.
Тонкий клиент в большинстве случаев обладает минимальной аппаратной конфигурацией, вместо жёсткого диска для загрузки локальной специализированной ОС используется DOM (DiskOnModule), то есть модуль с разъёмом IDE, флэш-памятью и микросхемой, реализующей логику обычного жёсткого диска, - в BIOS определяется как обычный жёсткий диск, только размер его обычно в 2-3 раза меньше. В некоторых конфигурациях системы тонкий клиент загружает операционную систему по сети с сервера, используя протоколы PXE, BOOTP, DHCP, TFTP и RIS (Remote Installation Services).
Протоколы, используемые тонкими клиентами
X11 - используется в Unix
SSH - мультиплатформенный защищённый аналог Telnet
NX NoMachine - протокол X11 со сжатием данных
Virtual Network Computing
ICA - Citrix Independent Computing Architecture
RDP - Remote Desktop Protocol, протокол для удалённой работы с использованием графического интерфейса пользователя для Microsoft Windows
SPICE - Simple Protocol For Independent Computing Environments
Кроме того могут применяться закрытые протоколы, специально созданные разработчиками программного обеспечения для повышения безопасности системы.
Примеры тонких клиентов
Virtual Network Computing
Применение толстого и тонкого клиентов в системе 1С:Предпирятие
Толстый клиент - это одно из клиентских приложений системы 1С:Предприятие 8. Исполняемый файл этого приложения - 1cv8.exe.
“Толстым” клиент называется потому, что может исполнять практически всю функциональность, предоставляемую встроенным языком, в том числе умеет работать с прикладными типами данных, такими как СправочникОбъект., ДокументОбъект. и т.д.
Но, по этой же причине, он требует значительного количества аппаратных ресурсов на компьютере пользователя и может “общаться” с базой данных или с сервером 1С:Предприятия 8 только посредством файлового доступа или по локальной сети.
Помимо работы в пользовательском режиме 1С:Предприятие, толстый клиент может работать в режиме Конфигуратор, в котором выполнятся администрирование информационных баз и разработка прикладных решений.
Тонкий клиент - это одно из клиентских приложений системы 1С:Предприятие 8. Исполняемый файл этого приложения - 1cv8c.exe.
“Тонким” клиент называется потому, что умеет исполнять ограниченный набор функциональности встроенного языка. В частности на тонком клиенте недоступны все прикладные типы данных. Вместо этого тонкий клиент оперирует ограниченным набором типов встроенного языка, предназначенным лишь для отображения и изменения данных в памяти. Вся работа с базой данных, объектными данными, исполнение запросов – выполняется на стороне сервера. Тонкий клиент только получает готовые данные, подготовленные для отображения.
Тонкий клиент обеспечивает работу только в пользовательском режиме 1С:Предприятие. Режим работы Конфигуратор тонким клиентом не поддерживается.
и главное - "тонкий клиент" позволяет работать с интерфейсом 1С:Предприятия через Интернет.
Архитектура «Клиент-Сервер» (также используются термины «сеть Клиент-Сервер» или «модель Клиент-Сервер») предусматривает разделение процессов предоставление услуг и отправки запросов на них на разных компьютерах в сети, каждый из которых выполняют свои задачи независимо от других.
В архитектуре «Клиент-Сервер» несколько компьютеров-клиентов (удалённые системы) посылают запросы и получают услуги от централизованной служебной машины – сервера (server – англ. «официант, обслуга»), которая также может называться хост-системой (host system, от host – англ. «хозяин», обычно гостиницы).
Клиентская машина предоставляет пользователю т.н. «дружественный интерфейс» (user-friendly interface), чтобы облегчить его взаимодействие с сервером.
Рис. 1. Архитектура «Клиент-Сервер».
Понятие тонкого клиента
Тонкий клиент — вид клиента, который может переносить выполнение задач по обработке информации на сервер, не применяя свои мощности по вычислению для их внедрения. Все вычислительные ресурсы подобного клиента максимально ограничены, важно, чтобы их хватало для старта нужного сетевого ПО, применяя, к примеру, веб-интерфейс.
Одним из наиболее распространенных примеров такого типа клиента считается ПК с заранее установленным веб-браузером, который применяется для функционирования с веб-програмами.
Характерная черта тонких клиентов — применение терминального режима функционирования. В такой ситуации, терминальный сервер применяется для процесса отправки и получения информации пользователя, что и является базовым отличием от процесса независимой обработки информации в толстых клиентах.
Плюсы тонкого клиента:
- Минимальное аппаратное обслуживание;
- Низкий риск возникновения неисправности;
- Минимальные технические требования к аппаратному оборудованию.
- При сбое на сервере «пострадают» все подключенные пользователи;
- Нет возможности работать без активного подключения к сети;
- При взаимодействии с большим массивом данных может снижаться объем производительности основного сервера.
Понятие толстого клиента
Толстый клиент — клиент, выполняющий запрашиваемые со стороны пользователя манипуляции независимо от ведущего сервера. Основной сервер в такой вариации системной архитектуры может применяться как особое хранилище информации, обработка и конечное предоставление которых просто переносится на локальную машину пользователя.
Толстый клиент – это рабочая машина или ПК, которые функционируют на основе своей ОС и наполнены полноценным набором ПО для требуемых задач пользователя.
Преимущества толстых клиентов:
- Большая функциональность;
- Наличие многопользовательского режима;
- Возможность работы в режиме оффлайн;
- Мгновенное быстродействие;
- Минимальная зависимость от сложных серверов.
- Все рабочие машины на постоянной основе нуждаются в техническом обслуживании;
- Нужда в индивидуальном обновлении аппаратного ПО каждого клиента до уровня программного обеспечения, которое будет использоваться;
- Массивные объемы дистрибутивов;
- Полная зависимость от платформ, под которую данные клиенты были созданы.
Итоги
В завершении стоит сказать, что выбор о том, какому клиенту отдать предпочтение, порой, зависит от того, какие именно задачи поставлены перед пользователем (проведение тестирования на проникновение или тестирования безопасности), какой ресурс аппаратной части ему открыт или какая программная составляющая ему доступна. Только исходя из положительных сторон и недостатков реализации каждого подхода, можно подобрать наиболее подходящий вариант именно для вас!
Примеры использования из повседневной практики пользователей
Все пользователи глобальной сети Интернет, так или иначе, сталкиваются как с толстыми, так и с тонкими клиентами.
С технической стороны, толстым клиентом может считаться локальная машина, которую пользователь применяет для внедрения своих намеченных целей.
Тонкий клиент может представлять собой отдельную рабочую станцию. Подобные тонкие клиенты могут быть весьма компактными, применять пассивное охлаждение. Порой, тонких клиентов используют в роли офисных локальных машин.
Если взглянуть с программной точки зрения, понятными примерами толстых клиентов можно считать программы для совместной деятельности, если они изначально установлены на определенные вычислительные устройства. Например: Yahoo Messenger, Office 365, Microsoft Outlook.
Все веб-браузеры и веб-приложения, наподобие WP, Google Docs и масса онлайн-игр могут считаться примерами тонкого клиента. Также, к данному типу клиентов относятся поисковые движки популярных сайтов от Google/Yahoo.
Преимущества и недостатки архитектуры «клиент-сервер»
К преимуществам архитектуры «клиент-сервер» можно отнести:
- Централизованность, поскольку все данные и управление сосредоточены в центральном сервере;
- Информационная безопасность, поскольку ресурсы общего пользования администрируются централизованно;
- Производительность, использование выделенного сервера повышает скорость работы ресурсов общего пользования;
- Масштабируемость, количество клиентов и серверов можно увеличивать независимо друг от друга.
К недостаткам архитектуры «клиент-сервер» следует отнести:
- Перегрузку трафика в сети, что является главной проблемой в сетях «клиент-сервер». Когда большое число клиентов одновременно запрашивают одну услугу на сервере, то число запросов может создать перегрузку в сети;
- Наличие единой точки отказа в небольших сетях с одним сервером. Если он отказывает, все клиенты остаются без обслуживания;
- Превышение пределов ресурсов сервера, когда новые клиенты, запрашивающие услугу, остаются без обслуживания. В таких случаях, требуется срочное расширение ресурсов сервера;
- Иногда клиентские программы могут не работать на терминалах пользователей, если не установлены соответствующие драйверы. Например, пользователь посылает запрос на печать документа, а на сервере нет подходящего драйвера для печати данного формата документа на определённом принтере.
Характеристики архитектуры «клиент-сервер»
Практические применения архитектуры «клиент-сервер»
Архитектуры «клиент-сервер» - один из основных принципов работы сети Интернет. Любой веб-сайт, или приложение в Интернет работает на сервере, а его пользователи являются клиентами. Социальные сети (Фейсбук, ВК и пр.), сайты электронной коммерции (Amazon, Озон и др.) , мобильные приложения (Instagram и т.д.), устройства Интернета вещей (умные колонки или смарт-часы) работают на основе клиент-серверной архитектуры.
Хорошим примером работы системы «клиент-сервер» является автомобильный навигатор. Приложение навигации на сервере собирает данные с многих смартфонов пользователей, на которых установлены клиенты приложения. Кроме того, приложение навигации использует ещё и данные с сервера базы данных – геоинформационной системы, который предоставляет данные, например, о текущих ремонтах дорог, о появлении новых дорог и пр. Данные со многих клиентов (местоположение, скорость) обрабатывается сервером навигации и выдаётся на смартфоны пользователей в виде информации о средней скорости движения по тому или иному участку маршрута.
Практически любая корпоративная сеть или ИТ-система предприятия, как правило, строится по архитектуре «клиент-сервер». В небольших сетях (3-5 компьютеров в компании) функции сервера может выполнять один из рабочих компьютеров. Если число машин в организации более 10, то лучше сделать выделенный сервер (почтовый сервер, приложений, баз данных и пр.), который будет заниматься обслуживанием клиентов – компьютеров и телефонов сотрудников организации.
В домашних сетях архитектура «клиент-сервер» тоже используется довольно часто. Например, в домашнюю сеть могут быть объединены компьютеры членов семьи, один из которых выполняет функции сервера. В домашнюю сеть также могут быть включены такие устройства, как умные колонки, умные домашние устройства (пылесосы-роботы, фотоаппараты, DVD-плееры и пр.), а также «умные» счётчики (вода, электричество) и т.д. Тогда в системе управления сервера, будут видны все параметры, данные и медифайлы (музыка, видео, фото), а также «умные устройства».
Итоги
Нюансы взаимодействия системы клиент-сервер позволяют пользователям разделять определенный функционал и вычислительную нагрузку между подключенными клиентскими веб-продуктами и серверными приложениями при разнообразных процессах тестирования (от тестирования БД до замеров общей производительности системы).
Понимание программистами и тестировщиками внутренней архитектуры приложения позволяют им более качественно не только создавать продукт, но и тестировать его, выполняя полноценные проверки от кросбраузерного соответствия до регрессионных тестов.
В среде компьютерной терминологии, понятие «клиент» означает определенное программное или аппаратное обеспечение, которое выполняет работу по взаимодействию с сервером для получения пользователем данных о выполненных системой действиях.
Клиент — очень важная составляющая системной архитектуры.
Простой пример клиента — это классический веб-браузер, способный выполнять передачу веб-запросов на веб-сервер, получая в ответ содержание необходимой веб-страницы. Все клиенты в клиент-серверной архитектуре условно делятся на два подтипа: толстые и тонкие.
Дополнительно есть архитектуры, которые могут объединять в себе «способности» тонких и толстых. Это гибридные клиенты.
Итак, разберем каждый вид по отдельности.
Виды сетевых протоколов
TCP/IP – совокупность протоколов передачи информации. TCP/IP – это особое обозначение всей сети, которая функционирует на основе протоколов TCP, а также IP.
TCP – вид протокола, который является связующим звеном для установки качественного соединения между 2 устройствами, передачи данных и верификации их получения.
MAC – вид протокола, на основании которого происходит процесс верификации сетевых устройств. Все устройства, которые подключены к сети Интернет, содержат свой оригинальный MAC-адрес.
ICMP – протокол, который ответственен за обмен данными, но не используется для процесса передачи информации.
UDP – протокол, управляющий передачей данных, но данные не проходят верификацию при получении. Этот протокол функционирует быстрее, чем протокол TCP.
FTP – протокол передачи информации из особого файлового сервера на ПК конечного пользователя.
POP3 – классический протокол простого почтового соединения, который ответственен за передачу почты.
SMTP – вид протокола, который может устанавливать правила для передачи виртуальной почты. Он ответственен за передачу и верификацию доставки, а также оповещения о возможных ошибках.
Одноуровневая архитектура (1-Tier)
Одноуровневая архитектура «клиент-сервер» (1-Tier) – такая, где все прикладные программы рассредоточены по рабочим станциям, которые обращаются к общему серверу баз данных или к общему файловому серверу. Никаких прикладных программ сервер при этом не исполняет, только предоставляет данные.
Рис. 2. Одноуровневая архитектура «клиент-сервер» (1-Tier).
В целом, такая архитектура очень надёжна, однако, ей сложно управлять, поскольку в каждой рабочей станции данные будут присутствовать в разных вариантах. Поэтому возникает проблема их синхронизации на отдельных машинах. В общем, как можно видеть из рисунка, в этой архитектуре просматривается ещё один уровень – базы данных, что даёт повод во многих случаях называть её двухуровневой.
Какая между ними разница?
Толстые клиенты работают с информацией на основе собственных аппаратных и программных возможностей, в то же время тонкие применяют ПО центрального сервера только чтобы обработать данные, предоставляя системе лишь требуемый графический интерфейс для выполнения работы пользователем. Это значит, что в роли тонких клиентов иногда мы можем увидеть устаревшие или не очень производительные ПК.
Заключение
В настоящее время можно встретить термин Serverless Architecture, т.н. «бессерверная архитектура». Однако, по сути, она представляет собой процесс получения функций сервера в виде облачной услуги. То есть, серверы в облаке тоже есть, но для конечного пользователя они не видны, и он получает их сервисы в виде абстрактной «функции как услуги» FaaS (Function as a Service).
Архитектура «клиент-сервер» является основой большинства корпоративных сетей и берёт свое начало от самых первых вычислительных машин, т.н. «мэйнфреймов». Программное обеспечение для локальных компьютерных сетей, подавляющее большинство которых основано на архитектуре «клиент-сервер», начало создаваться около 50 лет назад.
Дальнейшее развитие информационных технологий также будет происходить в значительной степени с использованием архитектуры «клиент-сервер».
Термин «клиент-серверная архитектура» – сборное понятие, состоящее из двух взаимодополняющих компонентов: сервера и, собственно, клиента.
Клиент – локальный компьютер на стороне виртуального пользователя, который выполняет отправку запроса к серверу для возможности предоставления данных или выполнения определенной группы системных действий.
Сервер – очень мощный компьютер или специальное системное оборудование, которое предназначается для разрешения определенного круга задач по процессу выполнения программных кодов. Он выполняет работы сервисного обслуживания по клиентским запросам, предоставляет пользователям доступ к определенным системным ресурсам, сохраняет данные или БД.
Особенности такой модели заключаются в том, что пользователь отправляет определенный запрос на сервер, где тот системно обрабатывается и конечный результат отсылается клиенту. В возможности сервера входит одновременное обслуживание сразу нескольких клиентов.
Если одновременно поступает более одного запроса, то такие запросы устанавливаются в определенную очередь и сервером выполняются по очереди. Порой запросы могут иметь свои собственные приоритеты. Часть запросов с более высокими приоритетами будут постоянно выполняться в первоочередном порядке!
Параметры, которые могут реализоваться на стороне сервера:
- Хранение, защита и доступ к данным;
- Работа с поступающими клиентскими запросами;
- Процесс отправки ответа клиенту.
Параметры, которые могут реализоваться на стороне клиента:
- Площадка по предоставлению пользовательского графического интерфейса;
- Формулировка запроса к серверу и его последующая отправка;
- Получение итогов запроса и отправка дополнительной группы команд (запросы на добавление, обновление информации, удаление группы данных).
Архитектура системы клиент-сервер формулирует принципы виртуального общения между локальными компьютерами, а все правила и принципы взаимодействия находятся внутри протокола.
Сетевой протокол – это особый набор правил, на основании которого выполняется точное взаимодействие между компьютерами внутри виртуальной сети.
Типы клиент-серверной архитектуры
Архитектуру «клиент-сервер» принято разделять на три класса: одно-, двух- и трёхуровневую. Однако, нельзя сказать, что в вопросе о таком разделении в сообществе ИТ-специалистов существует полный консенсус. Многие называют одноуровневую архитектуру двухуровневой и наоборот, то же можно сказать о соотношении двух- и трёхуровневой архитектур.
Постараемся внести ясность в этот вопрос.
Двухуровневая архитектура (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.
Есть сразу 2 вида клиент-серверных архитектур:
1. Двухуровневая, состоящая сразу из 2 узлов:
- сервер, который ответственен за получение входящих запросов и отправку ответа пользователю, применяя при этом собственные ресурсы системы;
- клиент, который может предоставлять пользовательский графический интерфейс.
Особенности работы заключаются в том, что на сервер приходит определенный запрос, потом его обрабатывают и дают напрямую, без дополнительного применения группы внешних ресурсов.
2. Трехуровневая система состоит из использования таких компонентов:
- предоставление информации – графический пользовательский, прикладной объект в виде сервера приложения;
- менеджмент ресурсов – сервер БД, который может предоставлять данные.
Особенность работы состоит в том, что сразу несколько серверов могут обрабатывать клиентские запросы. Процесс распределения операций может существенным образом снизить нагрузку на используемый сервер.
Трехуровневая архитектура может трансформироваться до многоуровневой, возможностью установки группы дополнительных серверов. Подобная виртуальная архитектура позволяет существенным образом повысить эффективность функционирования информационных систем, а также выполнить оптимизированное распределение части ее программно-аппаратных ресурсов.
Концепции постройки клиент-серверной системы
Слабый клиент – производительный сервер.
При такой модели весь процесс обработки информации перенесен на мощности сервера, а у пользователя права доступа очень строго ограничены. Сервер начинает отправлять ответ, который вообще не требует дополнительной работы по обработке. Клиент взаимодействует с пользователем: создает и отправляет запрос, принимает входящие итоги и выводит данные на экран пользователя.
Сильный клиент.
Концепция, при которой часть обработки данных предоставляет клиенту. В такой ситуации сервер является простым хранилищем информации, а вся деятельность по обработке и предоставлению данных переносится на ПК пользователя.
Продукт или система, которая говорит о том, что часть обрабатывающей информации предоставляется пользователю.
При такой ситуации сервер выступает особым хранилищем информации, а вся деятельность по обработке и предоставлению данных может переноситься на ПК пользователя.
Многоуровневая архитектура (N-Tier)
В отдельный класс архитектуры «клиент-сервер» можно вынести многоуровневую архитектуру, в которой несколько серверов приложений используют результаты работы друг друга, а также данные от различных серверов баз данных, файловых серверов и других видов серверов.
По сути, предыдущий вариант, трёхуровневая архитектура – не более, чем частный случай многоуровневой архитектуры.
Рис. 5. Многоуровневая архитектура «клиент-сервер» (N-Tier).
Преимуществом многоуровневой архитектуры является гибкость предоставления услуг, которые могут являться комбинацией работы различных приложений серверов разных уровней и элементов этих приложений.
Очевидным недостатком является сложность, многокомпонентность такой архитектуры.
Читайте также: