Как устроена архитектура веб-приложения?

Архитектура современного веб-приложения: от монолита до микросервисов

Архитектура веб-приложения — это структурированный набор компонентов, протоколов и паттернов, определяющих, как приложение обрабатывает запросы, хранит данные и масштабируется. За 10+ лет в DevOps я наблюдал эволюцию от простых монолитов до сложных распределённых систем.

Базовые компоненты (уровни архитектуры)

Традиционная трехуровневая архитектура (3-tier architecture) включает:

1. Презентационный уровень (Frontend/Client Tier)

   • Отвечает за взаимодействие с пользователем
   • HTML/CSS/JavaScript для статических приложений
   • React, Vue.js, Angular для SPA (Single Page Applications)
   • Мобильные клиенты (iOS/Android) для нативных приложений

2. Бизнес-логика (Application/Logic Tier)

   • Серверная обработка запросов
   • Node.js, Python (Django/Flask), Java (Spring), Go, Ruby on Rails
   • Содержит контроллеры, сервисы, модели
   • Пример обработки запроса на Node.js:

   // Express.js маршрут
   app.post('/api/users', async (req, res) => {
     try {
       const user = await UserService.create(req.body);
       res.status(201).json(user);
     } catch (error) {
       res.status(500).json({ error: 'Internal server error' });
     }
   });
   

3. Уровень данных (Data Tier)

   • Базы данных: PostgreSQL, MySQL, MongoDB, Redis
   • Кеширование: Redis, Memcached
   • Файловые хранилища: AWS S3, MinIO
   • Очереди сообщений: Kafka, RabbitMQ

Современные архитектурные подходы

Монолитная архитектура

Все компоненты развертываются как единое целое:

Плюсы:
• Простота разработки и деплоя
• Единая кодовая база
• Простая отладка

Минусы:
• Сложность масштабирования
• Единая точка отказа
• Зависимость от стека технологий

Микросервисная архитектура

Приложение разбивается на независимые сервисы:

# Пример docker-compose для микросервисов
version: '3.8'
services:
  auth-service:
    image: auth:latest
    ports: ["3001:3000"]
    environment:
      - DB_HOST=postgres-auth
  order-service:
    image: orders:latest
    ports: ["3002:3000"]
    depends_on:
      - auth-service
      - redis
  postgres-auth:
    image: postgres:14

Ключевые характеристики микросервисов:

• Каждый сервис отвечает за одну бизнес-функцию
• Независимое развертывание и масштабирование
• Общение через API (REST/gRPC)
• Собственные базы данных (Database per service)

Серверless архитектура (FaaS)

• AWS Lambda, Azure Functions, Google Cloud Functions
• Оплата по использованию (execution time)
• Автоматическое масштабирование
• Пример AWS Lambda:

import json
import boto3

def lambda_handler(event, context):
    # Обработка события из API Gateway
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('UsersTable')
    
    response = table.put_item(
        Item=event['body']
    )
    
    return {
        'statusCode': 200,
        'body': json.dumps('User created successfully')
    }

Критические инфраструктурные компоненты

Балансировка нагрузки и прокси

• Nginx/Apache как reverse proxy
• HAProxy для TCP/HTTP балансировки
• Cloud Load Balancers (AWS ALB/NLB, GCP Load Balancer)

Контейнеризация и оркестрация

# Dockerfile пример
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

• Docker для контейнеризации
• Kubernetes для оркестрации
• Service mesh (Istio, Linkerd) для управления трафиком

Мониторинг и логирование

• Метрики: Prometheus + Grafana
• Логи: ELK Stack (Elasticsearch, Logstash, Kibana)
• Трейсинг: Jaeger, Zipkin
• APM: New Relic, Datadog

Паттерны обработки данных

1. Кеширование (Redis, Memcached)
2. Асинхронная обработка через очереди (RabbitMQ, Kafka)
3. Репликация и шардинг баз данных
4. CDN для статического контента (Cloudflare, AWS CloudFront)

Типовая схема запроса в микросервисной архитектуре

Пользователь → CDN → Load Balancer → API Gateway → 
→ Микросервис А → (База данных А, Кеш, Очередь) →
→ Микросервис Б → Ответ → Пользователь

Выбор архитектуры: ключевые факторы

• Трафик и нагрузка: Пиковые значения, географическое распределение
• Команда: Размер, экспертиза, процессы разработки
• Бизнес-требования: Time-to-market, SLA, compliance
• Бюджет: CapEx vs OpEx, облачная vs on-premise инфраструктура

Золотое правило DevOps: архитектура должна позволять частые, предсказуемые и безопасные развертывания. Современные практики включают Infrastructure as Code (Terraform, CloudFormation), CI/CD pipelines (GitLab CI, GitHub Actions, Jenkins) и конфигурацию через окружение.

Архитектура постоянно эволюционирует с появлением edge computing, WebAssembly и гибридных облачных решений. Ключевой навык DevOps-инженера — понимать компромиссы каждого подхода и выбирать оптимальный стек для конкретных бизнес-задач.