exam

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

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

Основные компоненты

  1. Клиент — приложение или устройство, запрашивающее услуги или ресурсы:
    • браузер;
    • мобильное приложение;
    • десктопное приложение;
    • терминал.
  2. Сервер — мощный компьютер или система, предоставляющая услуги клиентам:
    • обрабатывает запросы;
    • хранит данные;
    • выполняет бизнес‑логику;
    • управляет доступом.
  3. Сеть — среда передачи данных (интернет, локальная сеть).
  4. База данных — хранилище информации (может быть частью сервера или отдельным компонентом).
  5. Протоколы взаимодействия — правила обмена данными:
    • HTTP/HTTPS — для веб‑приложений;
    • TCP/IP — базовый сетевой протокол;
    • WebSocket — для постоянного соединения;
    • FTP — для передачи файлов;
    • SMTP/IMAP — для электронной почты.

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

  1. Запрос клиента: пользователь инициирует действие (открывает страницу, отправляет форму).
  2. Отправка запроса: клиент формирует запрос и отправляет его на сервер по сетевому протоколу.
  3. Приём запроса сервером: сервер получает запрос, проверяет его валидность и авторизацию.
  4. Обработка запроса: сервер выполняет необходимые операции (выборка из БД, вычисления, генерация контента).
  5. Формирование ответа: сервер готовит ответ (HTML, JSON, файл) и отправляет его клиенту.
  6. Получение ответа клиентом: приложение получает данные и отображает их пользователю.
  7. Повторение цикла: процесс повторяется при каждом новом взаимодействии.

Пример: при открытии интернет‑магазина браузер (клиент) запрашивает каталог товаров, сервер обращается к БД, формирует HTML‑страницу и отправляет её обратно.

Виды клиент‑серверной архитектуры

  1. Двухуровневая (2‑tier):
    • Уровень 1: клиент (UI + простая логика);
    • Уровень 2: сервер (бизнес‑логика + БД);
    • Плюсы: простота разработки и развёртывания;
    • Минусы: ограниченная масштабируемость;
    • Пример: простой веб‑сайт с CMS.
  2. Трёхуровневая (3‑tier):
    • Уровень 1: клиент (только UI);
    • Уровень 2: сервер приложений (бизнес‑логика);
    • Уровень 3: сервер БД (хранение данных);
    • Плюсы: лучшая масштабируемость и безопасность;
    • Минусы: сложность разработки;
    • Пример: корпоративная ERP‑система.
  3. Многоуровневая (n‑tier):
    • несколько серверов приложений с разной функциональностью;
    • балансировка нагрузки между серверами;
    • Плюсы: высокая отказоустойчивость и масштабируемость;
    • Минусы: высокая сложность и стоимость;
    • Пример: крупные маркетплейсы (Яндекс Маркет, Ozon).

Типы клиентов

  1. Толстый клиент (Fat Client):
    • большая часть логики на стороне клиента;
    • требует установки;
    • работает в оффлайн‑режиме;
    • Пример: десктопные приложения (Microsoft Office, Photoshop).
  2. Тонкий клиент (Thin Client):
    • минимальная логика на стороне клиента;
    • основная обработка на сервере;
    • не требует установки (веб‑браузер);
    • Пример: веб‑почта, онлайн‑банкинг.
  3. Гибридный клиент:
    • сочетает черты толстого и тонкого клиента;
    • часть логики кэшируется локально;
    • может работать в оффлайн с последующей синхронизацией;
    • Пример: мобильные приложения соцсетей.

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

  • Централизованное управление: все данные и логика в одном месте.
  • Масштабируемость: можно добавлять серверы при росте нагрузки.
  • Безопасность: контроль доступа и защита данных на сервере.
  • Обновления: изменения применяются централизованно.
  • Совместная работа: несколько клиентов одновременно работают с одними данными.
  • Стандартизация: использование общепринятых протоколов.
  • Разделение обязанностей: клиенты отвечают за UI, серверы — за логику и данные.
  • Резервное копирование: централизованное хранение упрощает бэкапы.

Недостатки клиент‑серверной архитектуры

  • Зависимость от сети: без подключения клиент не может работать (для тонких клиентов).
  • Нагрузка на сервер: при большом числе клиентов возможны сбои.
  • Стоимость инфраструктуры: мощные серверы и каналы связи дороги.
  • Единая точка отказа: сбой сервера останавливает всю систему.
  • Сложность администрирования: требуется квалифицированный персонал.
  • Задержки: время передачи данных между клиентом и сервером.
  • Ограниченная автономность: тонкие клиенты бесполезны без сервера.

Где применяется

Клиент‑серверная архитектура лежит в основе большинства современных систем:

  • веб‑сайты и веб‑приложения;
  • мобильные приложения с бэкендом;
  • электронная почта (Gmail, Яндекс Почта);
  • онлайн‑банкинг и платёжные системы;
  • социальные сети (ВКонтакте, Telegram);
  • облачные сервисы (Google Drive, Яндекс Диск);
  • онлайн‑игры с мультиплеером;
  • корпоративные системы (ERP, CRM);
  • системы видеонаблюдения;
  • IoT‑платформы.

Альтернативы

  1. Peer‑to‑Peer (P2P):
    • равноправные узлы без центрального сервера;
    • высокая отказоустойчивость;
    • сложность управления;
    • Примеры: BitTorrent, Skype (ранние версии).
  2. Edge Computing:
    • обработка данных ближе к источнику (на устройствах);
    • снижение задержек;
    • подходит для IoT и реального времени.
  3. Serverless:
    • код выполняется в облаке по событиям;
    • автоматическое масштабирование;
    • зависимость от провайдера;
    • Примеры: AWS Lambda, Azure Functions.

Рекомендации по выбору

Выбирайте клиент‑серверную архитектуру, если:

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

Рассмотрите альтернативы, если:

  • критичны задержки (Edge Computing);
  • нагрузка нерегулярная (Serverless);
  • нужна максимальная отказоустойчивость (P2P).

Клиент‑серверная архитектура остаётся стандартом для большинства приложений благодаря балансу между функциональностью, масштабируемостью и управляемостью. Её выбор оправдан для 90 % веб‑ и мобильных проектов.