Серверная часть приложения: архитектура и взаимодействие с клиентом

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

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

Что такое серверная часть приложения

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

Серверная часть включает:

• Серверное приложение (backend) — код, написанный на языках вроде Python, Java, PHP, Node.js, Go или C#
• Базу данных — хранилище структурированных данных (PostgreSQL, MySQL, MongoDB, Redis)
• Системы кеширования — ускоряют обработку повторяющихся запросов (Redis, Memcached)
• Файловое хранилище — для загруженных файлов, изображений, документов (S3-совместимые хранилища, NAS)
• Очереди сообщений — для асинхронной обработки задач (RabbitMQ, Kafka, Celery)
• API-шлюзы — управляют маршрутизацией запросов и балансировкой нагрузки (Nginx, HAProxy, Traefik)

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

Из чего состоит серверная часть

Серверная часть приложения — это многослойная система. Каждый слой выполняет свою задачу и взаимодействует с соседними.

Слой представления (API)

Слой представления отвечает за приём запросов от клиента и возврат ответов. Обычно это REST API, GraphQL или gRPC. Клиент отправляет HTTP-запрос на определённый эндпоинт, сервер обрабатывает его и возвращает JSON, XML или другой формат данных.

Пример REST API:

• GET /api/products — получить список товаров
• POST /api/orders — создать новый заказ
• PUT /api/users/123 — обновить данные пользователя с ID 123
• DELETE /api/products/456 — удалить товар с ID 456

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

Слой бизнес-логики

Здесь происходит вся обработка данных: проверка прав доступа, валидация входных данных, расчёты, применение бизнес-правил. Например, при оформлении заказа бизнес-логика проверяет наличие товара на складе, рассчитывает стоимость с учётом скидок и налогов, резервирует товар и создаёт запись в базе данных.

Бизнес-логика изолирована от клиента и базы данных. Это упрощает тестирование и изменение правил без переписывания всего кода.

Слой доступа к данным

Этот слой взаимодействует с базой данных. Он выполняет SQL-запросы (для реляционных БД) или NoSQL-операции (для документных БД), получает данные, преобразует их в объекты приложения и возвращает бизнес-логике.

Слой доступа к данным абстрагирует бизнес-логику от конкретной СУБД. Можно заменить PostgreSQL на MySQL или перейти с MongoDB на Cassandra, изменив только этот слой, не трогая остальной код.

База данных

База данных хранит постоянные данные: пользователей, товары, заказы, транзакции. Выбор типа базы зависит от задачи:

• Реляционные (PostgreSQL, MySQL, MariaDB) — для структурированных данных со сложными связями
• Документные (MongoDB, Couchbase) — для гибких схем данных и быстрого прототипирования
• Ключ-значение (Redis, Memcached) — для кеширования и сессий
• Графовые (Neo4j, ArangoDB) — для анализа связей между объектами
• Колоночные (ClickHouse, Cassandra) — для аналитики больших объёмов данных

Очереди и фоновые задачи

Некоторые операции занимают много времени: отправка email, обработка изображений, генерация отчётов. Если выполнять их синхронно, клиент будет долго ждать ответа. Вместо этого сервер ставит задачу в очередь и сразу возвращает ответ клиенту. Фоновый воркер (worker) забирает задачу из очереди и выполняет её асинхронно.

Популярные системы очередей: RabbitMQ, Apache Kafka, AWS SQS, Redis Streams.

Кеширование

Кеш хранит часто запрашиваемые данные в оперативной памяти. Это ускоряет ответ сервера в десятки раз. Вместо повторного запроса к базе данных сервер берёт данные из кеша.

Кешируют:

• Результаты сложных SQL-запросов
• Данные пользовательских сессий
• Статические данные (список категорий, курсы валют)
• HTML-фрагменты страниц

Самые популярные решения для кеширования — Redis и Memcached.

Как серверная часть обрабатывает запросы клиента

Разберём путь запроса от клиента до ответа сервера.

Шаг 1: клиент отправляет запрос

Пользователь нажимает кнопку «Добавить в корзину» в веб-приложении. JavaScript-код на клиенте формирует HTTP-запрос и отправляет его на сервер:

POST /api/cart/add
Content-Type: application/json
Authorization: Bearer abc123xyz
{"product_id": 456, "quantity": 2}

Шаг 2: запрос попадает на балансировщик нагрузки

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

Балансировщик выбирает сервер по одному из алгоритмов:

• Round Robin — по очереди
• Least Connections — выбирает сервер с наименьшим количеством активных соединений
• IP Hash — один и тот же пользователь всегда попадает на один сервер

Шаг 3: аутентификация и авторизация

Сервер проверяет токен авторизации (Bearer abc123xyz). Если токен валидный, сервер извлекает ID пользователя. Если токен невалидный или истёк — возвращает ошибку 401 Unauthorized.

Затем сервер проверяет права доступа (авторизацию): может ли этот пользователь добавлять товары в корзину. Если у него заблокирована учётная запись — возвращает 403 Forbidden.

Шаг 4: валидация входных данных

Сервер проверяет, что product_id и quantity — числа, quantity больше нуля, product_id существует в базе. Если данные некорректны — возвращает 400 Bad Request с описанием ошибки.

Шаг 5: выполнение бизнес-логики

Сервер проверяет наличие товара на складе. Если товара нет — возвращает ошибку. Если есть — добавляет товар в корзину пользователя. Корзина может храниться в базе данных или в Redis (для временных данных).

Шаг 6: запись в базу данных

Сервер выполняет SQL-запрос для добавления записи в таблицу cart_items:

INSERT INTO cart_items (user_id, product_id, quantity) VALUES (123, 456, 2)

База данных сохраняет запись и возвращает подтверждение.

Шаг 7: формирование ответа

Сервер формирует JSON-ответ с обновлённым содержимым корзины:

{"status": "success", "cart_items_count": 5, "total_price": 12500}

HTTP-статус 200 OK.

Шаг 8: отправка ответа клиенту

Сервер отправляет ответ через балансировщик обратно клиенту. JavaScript-код на клиенте получает ответ и обновляет интерфейс: показывает уведомление «Товар добавлен в корзину» и обновляет счётчик товаров.

Логирование и мониторинг

На каждом этапе сервер записывает логи: кто отправил запрос, что запрашивал, сколько времени заняла обработка, были ли ошибки. Системы мониторинга (Prometheus, Grafana, ELK Stack) собирают метрики и алертят администраторов при сбоях.

Отличия серверной архитектуры от клиентской

Клиентская и серверная части приложения решают разные задачи и строятся по разным принципам.

Местоположение

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

Функции

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

Производительность

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

Безопасность

Клиент работает в недоверенной среде. Пользователь может открыть код JavaScript, изменить параметры запроса, попытаться обойти проверки. Поэтому все критические проверки выполняются на сервере.

Сервер контролирует доступ к данным, проверяет права пользователя, валидирует входные данные. Даже если клиент скомпрометирован, сервер защищён.

Хранение данных

Клиент хранит временные данные: кеш, токены авторизации, настройки интерфейса. Постоянные данные хранятся на сервере в базе данных.

Обновления

Обновить серверную часть можно мгновенно для всех пользователей — достаточно задеплоить новую версию кода. Обновление клиента требует загрузки новой версии приложения или очистки кеша браузера.

Язык и технологии

Клиент для веб-приложений работает на JavaScript (React, Vue.js, Angular), для мобильных — на Swift, Kotlin или Flutter. Серверная часть может быть написана на любом языке: Python (Django, Flask), Java (Spring), Node.js (Express), Go, PHP (Laravel), C# (.NET), Ruby (Rails).

Критерий	Клиентская часть	Серверная часть
Местоположение	Устройство пользователя	Удалённый сервер
Функции	Интерфейс, UX	Бизнес-логика, данные
Производительность	Ограничена устройством	Масштабируется
Безопасность	Недоверенная среда	Контролируемая среда
Хранение	Временные данные	Постоянные данные
Обновления	Требует действий пользователя	Мгновенно для всех
Язык	JS, Swift, Kotlin	Python, Java, Go, Node.js, PHP

Серверное оборудование для развёртывания приложений

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

Для небольших приложений и стартапов

Если вы разрабатываете MVP, внутренний корпоративный сервис или приложение с небольшой аудиторией (до 1000 пользователей), достаточно одного сервера с умеренными характеристиками. На нём можно развернуть приложение, базу данных и Redis в контейнерах Docker.

Рекомендуемая конфигурация:

• Процессор: Intel Xeon E-2300 (4-8 ядер) или AMD EPYC 7002 (8 ядер)
• Память: 16-32 ГБ DDR4 ECC
• Диски: 2×500 ГБ SSD в RAID 1 (для данных) + 240 ГБ SSD (для ОС)
• Сеть: 1 Гбит/с

Для таких задач подойдут начальные серверы форм-фактора tower или rack 1U. Они компактны, тихие, потребляют мало энергии и не требуют серьёзного охлаждения.

Для средних приложений с микросервисной архитектурой

Если приложение разделено на микросервисы (отдельные контейнеры для API, базы данных, очередей, кеша), понадобится несколько серверов или мощная серверная платформа с виртуализацией. Типовая схема: 2-3 сервера для приложений, 1-2 сервера для баз данных, 1 сервер для балансировщика.

Рекомендуемая конфигурация для каждого сервера:

• Процессор: 2× Intel Xeon Silver или AMD EPYC 7003 (по 16 ядер)
• Память: 64-128 ГБ DDR4 ECC
• Диски: 4×1 ТБ NVMe SSD в RAID 10
• Сеть: 10 Гбит/с

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

Для высоконагруженных приложений

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

Типовая архитектура:

• 3-5 серверов для приложений (за балансировщиком)
• 2-3 сервера для баз данных (master-replica или кластер)
• 2 сервера для кеша (Redis Cluster)
• 2 сервера для очередей (RabbitMQ или Kafka)
• 1-2 сервера для мониторинга и логирования

Рекомендуемая конфигурация для серверов приложений:

• Процессор: 2× Intel Xeon Gold или AMD EPYC 7003 (по 24-32 ядра)
• Память: 128-256 ГБ DDR4 ECC
• Диски: 6×2 ТБ NVMe SSD в RAID 10
• Сеть: 25 Гбит/с

Для баз данных критична скорость дисковой подсистемы. Используйте NVMe SSD с высоким IOPS (более 500 000 операций в секунду). Серверная оперативная память с поддержкой ECC обязательна — она предотвращает потерю данных при сбоях.

Процессоры для серверных приложений

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

Серверные процессоры Intel Xeon и AMD EPYC поддерживают технологии виртуализации, ECC-память, расширенные инструкции для шифрования и машинного обучения. Для виртуализации (если на одном сервере несколько виртуальных машин с приложениями) нужны процессоры с поддержкой Intel VT-x или AMD-V.

Хранение данных

Для баз данных используйте быстрые NVMe SSD. Для файлового хранилища (загруженные пользователями файлы, бэкапы) подойдут SATA SSD или HDD большого объёма. Если данных много, разверните отдельную систему хранения (NAS или SAN) и подключите её к серверам приложений.

Виртуализация и контейнеризация

Большинство современных приложений развёртывают в контейнерах Docker с оркестрацией через Kubernetes. Это упрощает масштабирование, обновление и откат версий. Для Kubernetes-кластера понадобится минимум 3 сервера (master + worker-ноды).

Если вы используете виртуализацию (VMware ESXi, Proxmox, Hyper-V), на одном физическом сервере можно развернуть несколько виртуальных машин с разными приложениями. Это снижает затраты на оборудование и упрощает управление.

Сеть

Для приложений с высокой нагрузкой нужна быстрая сеть: 10 Гбит/с и выше. Если серверы находятся в одной стойке, используйте Top-of-Rack коммутаторы. Для связи между стойками — spine-leaf архитектуру.

Резервирование и отказоустойчивость

Для критичных приложений используйте:

• Резервные блоки питания (redundant PSU)
• Горячую замену дисков (hot-swap)
• RAID для дисков (RAID 1, RAID 10 или RAID 6)
• Репликацию баз данных (master-replica или multi-master)
• Балансировщик нагрузки с health-check (автоматическое исключение неисправных серверов)

Рекомендации по производителям

На Server360 представлены серверы от ведущих производителей: Dell, HP/HPE, Supermicro, Lenovo. Все они предлагают гибкие конфигурации, удалённое управление (iLO, iDRAC, IPMI), поддержку горячей замены и гарантию.

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

Частые вопросы