Какие знаешь виды клиент-серверной архитектуры?

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

Клиент-серверная архитектура — это распределённая архитектура, где клиент отправляет запросы, а сервер их обрабатывает. Существует множество вариаций, каждая со своими характеристиками и применением.

1. Two-Tier (Двухуровневая архитектура)

Прямое взаимодействие клиента и сервера базы данных.

Клиент (UI) ↔ Сервер БД

Характеристики:

• Клиент напрямую подключается к БД
• Вся логика на клиенте или на БД
• Простая архитектура

Примеры:

• Настольные приложения (Desktop app → SQL Server)
• Ранние веб-приложения

Преимущества:

• Простота реализации
• Быстрое развитие
• Прямой доступ к данным

Недостатки:

• Пароли БД видны в приложении
• Сложно масштабировать
• Плохая безопасность
• Клиент зависит от логики БД
• Трудно менять структуру БД

Когда использовать:

• Маленькие внутренние приложения
• Прототипирование
• Не для production

2. Three-Tier (Трёхуровневая архитектура)

Классическая архитектура с тремя слоями.

Презентационный слой (UI)
         ↓ HTTP/HTTPS
Апликационный слой (Business Logic)
         ↓ SQL/Queries
Уровень данных (Database)

Слои:

1. Presentation Layer — UI, веб-браузер, мобильное приложение
2. Application Layer — Web Server, Business Logic, API
3. Data Layer — Database Server

Пример архитектуры:

Клиент (браузер) 
    ↓ (HTTP запрос)
Нginx/Apache (веб-сервер)
    ↓ (WSGI, FastAPI)
Python Application (бизнес-логика)
    ↓ (SQL)
PostgreSQL (БД)

Преимущества:

• Разделение ответственности
• Хорошая безопасность (пароли БД на сервере)
• Масштабируемость
• Легко обновлять каждый слой отдельно
• Industry standard

Недостатки:

• Больше сложности
• Больше компонентов
• Требует администрирования

Когда использовать:

• Большинство веб-приложений
• Enterprise системы
• Когда нужна масштабируемость

3. N-Tier (Многоуровневая архитектура)

Расширение трёхуровневой с дополнительными слоями.

Presentation Tier
    ↓
Business Logic Tier
    ↓
Service Tier (APIs, Business Rules)
    ↓
Data Access Tier (ORM, Queries)
    ↓
Database Tier

Дополнительные слои:

• Service Layer — реюзируемые сервисы
• Data Access Layer (DAL) — работа с БД через ORM
• Caching Layer — кеширование (Redis)
• Logging & Monitoring — логирование и мониторинг

Примеры:

• Domain-Driven Design (DDD)
• Layered Architecture
• Clean Architecture

Преимущества:

• Максимальное разделение ответственности
• Легко тестировать
• Легко масштабировать
• Гибкость

Недостатки:

• Сложность
• Много слоёв = медленнее
• Требует дизайна

4. Микросервисная архитектура (Microservices)

Вместо одного приложения — множество маленьких независимых сервисов.

API Gateway
    ├─→ User Service
    ├─→ Order Service
    ├─→ Payment Service
    ├─→ Notification Service
    └─→ Inventory Service

Каждый сервис:

• Независимая разработка
• Собственная БД
• Собственный деплой
• Коммуникация через API (HTTP, gRPC)

Пример коммуникации:

User Service → Order Service (HTTP POST /orders)
           → Payment Service (HTTP POST /payments)
           → Notification Service (HTTP POST /notify)

Преимущества:

• Независимое масштабирование
• Технологическая гибкость
• Быстрое развитие
• Отказоустойчивость (если User Service упал, остальные работают)
• Быстрый деплой

Недостатки:

• Сложность операций (DevOps, мониторинг)
• Network latency
• Трудная отладка (распределённые трассировки)
• Сложная консистентность данных
• Требует опытную команду

Когда использовать:

• Большие системы (100+ разработчиков)
• Разные команды работают на разные сервисы
• Требуется независимое масштабирование
• Netflix, Amazon, Google

5. Serverless (Бессерверная архитектура)

Функции выполняются на demand без управления серверами.

Клиент → API Gateway → Lambda Functions → DynamoDB
                    ↓ (event-driven)
              Queue (SQS) → Lambda

Как работает:

1. Событие (HTTP запрос, сообщение в queue)
2. Облачный провайдер запускает функцию
3. Функция выполняется и завершается
4. Оплата только за время выполнения

Примеры:

• AWS Lambda
• Google Cloud Functions
• Azure Functions

Преимущества:

• Нет управления серверами
• Auto-scaling
• Платишь за использование
• Быстрый старт
• Идеально для микросервисов

Недостатки:

• Cold start (задержка первого запроса)
• Limited execution time (15 минут в Lambda)
• Vendor lock-in
• Сложнее отлаживать
• Сложнее с состоянием

Когда использовать:

• API endpoints
• Background jobs
• Event processing
• Стартапы с ограниченным бюджетом

6. Edge Computing

Вычисления на границе сети, близко к пользователю.

Пользователь → Edge Node (близко к пользователю) → Origin Server

Примеры:

• Cloudflare Workers
• AWS CloudFront Lambda@Edge
• Netlify Edge Functions

Использование:

• CDN
• Кеширование
• Обработка близко к пользователю
• Снижение latency

Преимущества:

• Низкая latency
• Масштабируемость
• Кеширование

Недостатки:

• Ограниченное хранилище
• Сложность синхронизации

7. Peer-to-Peer (P2P)

Каждый узел может быть и клиентом и сервером.

Узел A ↔ Узел B
Узел A ↔ Узел C
Узел B ↔ Узел D

Примеры:

• BitTorrent
• Blockchain
• IPFS

Преимущества:

• Отказоустойчивость
• Масштабируемость
• Нет единой точки отказа

Недостатки:

• Сложность
• Трудность поиска данных
• Трудность синхронизации

Сравнение архитектур

Гибридный подход

В современных системах часто комбинируют:

Client → API Gateway (Edge)
      → Microservices (Lambda/Containers)
      → Databases (Managed)
      → Cache (Redis)
      → Message Queue (RabbitMQ, Kafka)

Значение для System Analyst

System Analyst должен:

• Выбирать архитектуру в зависимости от требований
• Понимать trade-offs каждой архитектуры
• Проектировать масштабируемые системы
• Определять требования к infrastruсture
• Планировать growth path (как перейти от 2-Tier к Microservices)
• Обучать команду паттернам архитектуры