Эксперты в подборе IT-оборудования
Клиент-серверная модель - основа почти всего, с чем вы работаете: от корпоративных CRM до стриминга и онлайн-игр. Суть простая. Одна сторона (клиент) отправляет запрос, другая (сервер) его обрабатывает и отдаёт результат. Два компонента, чёткое разделение ролей.
Дальше начинаются детали, из-за которых одинаковые на бумаге системы ведут себя по-разному: сколько в схеме уровней, где живёт бизнес-логика, что происходит, когда пользователей становится втрое больше.
Клиент-серверная архитектура - это схема, в которой одни программы (клиенты) запрашивают данные или действия, а другие (серверы) их выполняют и возвращают ответ. Роли жёстко разделены и заданы заранее: клиент всегда инициирует, сервер всегда отвечает.
Слово «сервер» здесь означает роль, а не железный ящик в стойке. Один физический сервер может выполнять роль веб-сервера, сервера БД и файлового сервера одновременно - и наоборот, одну роль может обслуживать десяток машин.
Что нужно для работы такой схемы:
При этом важно правильно выбрать сервер для офисной инфраструктуры, чтобы он справлялся с нагрузкой от всех клиентских устройств.
Проще всего понять архитектуру, проследив за одним запросом. Схема клиент-сервер в жизни выглядит так - пользователь нажал кнопку в браузере, и дальше:
Каждый шаг общается по согласованному протоколу - HTTP, TCP/IP, MQTT для устройств интернета вещей. Протокол определяет формат запроса и ответа, чтобы стороны понимали друг друга независимо от того, на чём написаны.
Смысл разбора не академический. Когда пользователи говорят «всё тормозит», тормозит один из семи шагов, и пока вы не знаете какой, менять железо бессмысленно. Чаще прочих подводит пятый - тяжёлый запрос к базе, которому не хватает индекса.
Три базовых типа - по тому, сколько работы берёт на себя клиент:
Граница между тонким и толстым подвижна, и в одной системе они часто уживаются. В 1С, например, разница между толстым и тонким клиентом напрямую определяет, сколько ресурсов съест терминальный сервер.
Любую клиент-серверную систему можно разложить на три функциональных слоя. Уровень представления - это интерфейс, с которым работает пользователь. Уровень логики - правила, расчёты и проверки прав. Уровень данных - СУБД, которая хранит информацию и отвечает за её целостность.
Слои есть всегда, даже в самой простой программе. Отличаются архитектуры тем, по скольким узлам эти слои разнесены и живут ли узлы на отдельном железе или на виртуальных машинах (тогда встаёт отдельный вопрос, какой гипервизор выбрать). Отсюда деление на одно-, двух-, трёх- и многоуровневые схемы.
Все три слоя живут на одной машине. Интерфейс, логика и данные лежат рядом, сеть не участвует вообще.
Так работает Access-база на рабочем столе бухгалтера или локальная утилита с файлом настроек. Просто, быстро, не требует администрирования. Проблема одна, зато принципиальная: у каждого пользователя своя копия данных. Как только за одну таблицу садятся двое, начинается расхождение версий, и починить это внутри одноуровневой схемы нечем.
Клиент обращается к серверу базы данных напрямую - без промежуточного звена. Отсюда и «два уровня»: клиентское приложение и СУБД.
Бизнес-логика при этом делится между толстым клиентом и хранимыми процедурами на стороне базы. Классический пример - десктопное приложение, которое само открывает соединение с MS SQL или PostgreSQL и шлёт туда запросы.
Схема живучая и до сих пор массово работает. Упирается она в две вещи. Первая - каждый клиент держит собственное соединение с базой, и на сотнях рабочих мест СУБД начинает захлёбываться. Вторая - логика размазана по клиентам, поэтому любое изменение правил требует обновления приложения на всех машинах. Отдельная развилка этого уровня - файл-серверный и клиент-серверный режимы СУБД, которые путают чаще всего.
Между клиентом и базой появляется сервер приложений. Клиент показывает интерфейс, сервер приложений выполняет логику, СУБД хранит данные.
Что это даёт: клиент больше не ходит в базу напрямую, поэтому проверка прав и валидация происходят в одной точке. Раньше каждое приложение делало это по-своему, теперь правила живут на сервере приложений и меняются для всех разом. Соединений к СУБД становится меньше, ими управляет пул на среднем уровне.
Чего это не даёт: сама по себе трёхуровневая схема ни от кого не защищает и ничего не гарантирует. Она лишь создаёт место, где централизованно наводится порядок. Если в этом месте не проверять права, дыра будет ровно та же, что и в двухуровневой. Плата за схему - лишний узел, который надо разворачивать, мониторить и держать в живых.
Развитие трёхуровневой: слоёв больше трёх, каждый отвечает за свою функцию и живёт на отдельных узлах. Отдельно шлюз API, отдельно сервисы бизнес-логики, отдельно кэш, отдельно очередь сообщений, отдельно хранилище.
Каждую часть можно масштабировать независимо: уперлись в обработку заказов - добавили нод именно туда, не трогая остальное. Расплата - сложность. Отладка распределённой системы, где запрос проходит через шесть сервисов, требует сквозной трассировки и зрелого мониторинга. Для небольшой компании это чаще минус, чем плюс.
| Схема | Где логика | Где данные | Что обновлять при изменении правил | Когда выбирать |
|---|---|---|---|---|
| 1-Tier | На клиенте | На клиенте | Каждую машину | Один пользователь, данные не общие |
| 2-Tier | Клиент и хранимые процедуры | Отдельный сервер БД | Клиентов и процедуры | До нескольких десятков рабочих мест, простые правила |
| 3-Tier | Сервер приложений | Отдельный сервер БД | Один сервер приложений | Общие правила для всех, много пользователей, веб-доступ |
| N-Tier | Разнесена по сервисам | Хранилища и кэши по сервисам | Отдельный сервис | Неравномерная нагрузка, независимое масштабирование частей |
Кроме деления по уровням, разновидности клиент-серверной архитектуры описывают и по тому, как распределены мощности и как устроена серверная часть.
По балансу мощности:
Серверную часть тоже строят по-разному. Монолит - это когда вся логика собрана в одно приложение: разворачивать просто, отлаживать просто, а масштабировать по частям нельзя, растёт всё целиком. Для небольших проектов это до сих пор разумный выбор по умолчанию, что бы ни говорила мода. Микросервисы разбивают приложение на независимые сервисы, каждый со своей зоной ответственности; деплоятся и масштабируются они отдельно, но отладка и мониторинг усложняются заметно. Облачные и serverless-схемы идут дальше: клиент общается с API, серверная часть живёт у провайдера и масштабируется сама, а вместе с управлением инфраструктурой туда уходит и часть контроля над ней.
Технология клиент-сервер строится на разделении ролей и ответственности между двумя сторонами:
Из этого разделения и вырастает главное свойство: клиенты могут находиться где угодно относительно сервера. Отсюда удалённая работа, мобильные приложения и филиальные сети.
Что характерно для технологии клиент-сервер, так это четыре свойства, ради которых её и выбирают.
Первое - горизонтальное масштабирование. Нагрузка выросла, вы добавили серверные ноды и балансировщик, клиентская часть при этом не изменилась. Пользователи ничего не заметили. Второе - консистентность данных: один источник правды вместо коллекции файлов с приписками «финал», «финал2» и «финал_правки_окончательные» по рабочим столам.
Третье свойство - отказоустойчивость, и вот с ним нужна оговорка. Кластеризация, репликация и health-чеки действительно позволяют пережить выход одного узла, но появляются они не сами: архитектура лишь даёт для них место. Схема без настроенного резервирования падает так же, как одиночная машина, просто уносит с собой сразу всех.
Четвёртое - управление доступом из одной точки. Политики, аутентификация, шифрование настраиваются централизованно, и чтобы поменять правило, не нужно обходить рабочие станции. Сюда же примыкает гибкость в распределении логики: её двигают между клиентом и сервером, подбирая баланс между отзывчивостью интерфейса и нагрузкой на серверную часть.
Если перевести характеристики архитектуры клиент-сервер в практические выгоды, получится короткий список.
Администрирование сжимается до одной точки: обновления, бэкапы, права доступа. Данные не разъезжаются по рабочим станциям, поэтому резервное копирование становится осмысленным - вы бэкапите сервер, а не двадцать разных папок «Мои документы». Нагрузка распределяется: сервер обрабатывает запросы многих клиентов параллельно, и железо используется полнее, чем когда у каждого стоит мощная машина под редкие пиковые задачи. Рост системы тоже дешевле - новое рабочее место добавляется без пересмотра архитектуры.
Практическое применение архитектуры клиент-сервер начинается ровно там, где данные должны быть общими. Область применения покрывает почти всё корпоративное ПО: веб-приложения, где клиентом работает браузер; мобильные приложения, которые синхронизируются через удалённый сервер; корпоративные сети с обменом данными между подразделениями и централизованным управлением. Дома по той же схеме работают «умные» колонки, бытовая техника и счётчики.
Какие бывают клиент-серверные системы по типу сервера:
| Тип системы | Что делает сервер | Что видит пользователь |
|---|---|---|
| Веб-сервер | Отдаёт страницы и данные по HTTP | Сайт или веб-приложение в браузере |
| Сервер БД | Хранит данные, выполняет запросы, следит за целостностью | Отчёт, справочник, форма в программе |
| Почтовый сервер | Принимает, хранит и доставляет письма | Почтовый клиент или веб-почта |
| Файловый сервер | Хранит документы и раздаёт доступ по правам | Сетевая папка |
| Прокси-сервер | Посредник между клиентом и внешней сетью | Прозрачно для пользователя |
| Сервер транзакций | Проводит банковские операции и покупки | Подтверждение платежа |
| Медиасервер | Раздаёт видео и музыку на устройства | Фильм на телевизоре |
Раздел, которого обычно не хватает: выбранная схема прямо определяет, какой узел станет узким местом и во что вкладываться при закупке.
В двухуровневой схеме всё упирается в сервер базы данных. Он один обслуживает соединения всех клиентов, поэтому там критичны оперативная память под кэш и дисковая подсистема с хорошими показателями на случайных операциях. Процессор важен, но обычно не он заканчивается первым. Подробности - в разборе того, каким должен быть сервер баз данных.
В трёхуровневой нагрузка расщепляется. Сервер приложений упирается в процессор и память - он считает логику и держит пул соединений. Сервер БД остаётся чувствительным к дискам и памяти. Это позволяет не покупать одну огромную машину, а взять две умеренные под разные профили нагрузки.
Тонкие клиенты переносят на сервер всё сразу. В терминальном сценарии память и процессорные ядра расходуются на каждый пользовательский сеанс, и рост числа сотрудников бьёт по серверу линейно. Здесь считать конфигурацию нужно от количества одновременных сессий и профиля их работы, а не от «примерно как раньше».
Про сеть забывают чаще всего. В любой схеме сложнее одноуровневой канал между узлами - полноценный компонент. Гигабита между сервером приложений и сервером БД хватает далеко не всегда, и упершись в него, вы будете безуспешно наращивать процессоры.
Практическое следствие. Прежде чем смотреть серверы в каталоге, определитесь с числом уровней. Одна и та же сумма, вложенная в сервер БД при двухуровневой схеме и в сервер приложений при трёхуровневой, даёт совершенно разный результат.
У модели есть слабые места, и их стоит учитывать при проектировании.
Зависимость от сети. Пропал канал - клиенты ослепли. Высокая латентность портит работу даже при формально живой связи. Лечится кэшированием на клиенте, офлайн-режимами и вынесением статики ближе к пользователю.
Узкое горлышко на сервере. Один сервер и тысяча клиентов - и вот уже посыпались ошибки шлюза. Помогают балансировка нагрузки, горизонтальное масштабирование и очереди сообщений, которые сглаживают пики.
Единая точка отказа. Централизация, ради которой всё затевалось, оборачивается тем, что падение сервера останавливает всех сразу. Отсюда кластеры, реплики и резервное питание - и отсюда же расходы, которых в одноранговой схеме просто нет.
Сложность обновлений. Серверную часть обновить просто. С толстыми клиентами хуже: каждое устройство нужно обновлять отдельно, и парк неизбежно разъезжается по версиям. Тонкие клиенты и веб-приложения снимают эту проблему.
Модель хороша не всегда, и честный ответ на вопрос «нужен ли нам сервер» иногда отрицательный.
Если пользователей двое и они работают с разными данными, централизация не окупится: вы получите узел, который надо администрировать, бэкапить и чинить, без выигрыша в удобстве. Если данные по своей природе локальные - монтаж, обработка фотографий, расчёты на одной машине - гонять их через сервер бессмысленно, канал станет тормозом. Если связь нестабильна, а работа должна продолжаться при её потере, схема с обязательным обращением к серверу будет постоянно подводить.
Наконец, есть задачи, где равноправные узлы работают лучше централизованных: раздача больших объёмов между многими участниками, прямая связь между двумя абонентами. Там уместнее одноранговая схема.
Разница принципиальная. В P2P-сети все узлы равноправны - каждый одновременно и клиент, и сервер. Данные передаются напрямую между участниками, центрального узла нет. В клиент-серверной модели роли жёстко разделены: клиент просит, сервер отдаёт.
Следствия расходятся по всем направлениям. P2P не имеет единой точки отказа и дешевле в железе - отдельный сервер не нужен. Но управлять такой сетью тяжело: нет места, где применяются политики доступа, сложно обеспечить согласованность данных, аудит превращается в отдельную задачу. Клиент-серверная модель проще в администрировании и предсказуемее в поведении, поэтому в корпоративной среде, где нужны контроль доступа и журналирование, выбирают её.
В чём отличие понятий «клиент» и «сервер»?
Это роли в конкретном обмене, а не типы устройств. Клиент - тот, кто инициирует запрос. Сервер - тот, кто на него отвечает. Роль определяется в момент взаимодействия.
Может ли компьютер быть клиентом и сервером одновременно?
Да, и это обычное дело. Сервер приложений отвечает клиентам как сервер и тут же обращается к СУБД как клиент. На рабочей станции разработчика локальная база и приложение живут вместе, меняя роли по ходу работы.
Где расположены программы пользователя и программы СУБД в архитектуре клиент-сервер?
Пользовательская часть - на клиентском устройстве, СУБД - на сервере. В двухуровневой схеме они общаются напрямую, в трёхуровневой между ними стоит сервер приложений.
Нужен ли отдельный физический сервер для клиент-серверной архитектуры?
Не обязательно. Серверные роли живут на виртуальных машинах и в контейнерах, и в небольшой инфраструктуре несколько ролей спокойно уживаются на одной машине. Разделять их начинают, когда роли мешают друг другу по ресурсам или по требованиям к доступности.
Проектируете инфраструктуру под клиент-серверное приложение?
Инженеры ITTELO подберут конфигурацию под вашу схему - от одной машины под небольшой офис до разнесённых серверов приложений и баз данных. Соберём и протестируем под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
Сервер для офиса на 5 компьютеров · +7 (800) 551-80-12 · info@ittelo.ru
