Как используются принципы микросервисного подхода для масштабируемости высоконагруженного проекта?

Микросервисы для масштабируемости высоконагруженных проектов

Микросервисная архитектура позволяет независимо масштабировать компоненты системы. Я расскажу, как это работает на практике.

Основные принципы микросервисов

1. Декомпозиция по доменам (Domain-Driven Design)

Вместо монолита разбиваем систему на независимые сервисы:

Монолит (плохо для масштабирования):
Апликация (users, auth, products, orders)

Микросервисы (хорошо для масштабирования):
Auth Service :8001
Users Service :8002
Products Service :8003
Orders Service :8004

Каждый сервис может масштабироваться независимо:

# Если Auth Service получает 10000 RPS — масштабируем только его
docker run -p 8001:8001 auth-service &
docker run -p 8001:8001 auth-service &  # Ещё инстанс

2. API Gateway (точка входа)

Единая входная точка распределяет запросы по сервисам:

from fastapi import FastAPI
import httpx

app = FastAPI()

SERVICES = {
    "auth": "http://auth-service:8001",
    "users": "http://users-service:8002",
    "products": "http://products-service:8003",
}

@app.post("/api/v1/auth/login")
async def login(username: str, password: str):
    async with httpx.AsyncClient() as client:
        response = await client.post(
            f"{SERVICES['auth']}/login",
            json={"username": username, "password": password}
        )
        return response.json()

3. Горизонтальное масштабирование (Load Balancer)

Распределяем нагрузку на несколько инстансов через Nginx:

upstream auth_backend {
    least_conn;
    server auth-service-1:8001;
    server auth-service-2:8001;
    server auth-service-3:8001;
}

server {
    listen 80;
    location / {
        proxy_pass http://auth_backend;
    }
}

4. Асинхронная коммуникация (Message Queue)

Сервисы взаимодействуют через очереди для слабой связанности:

import aio_pika
import json

@app.post("/orders")
async def create_order(order_data: dict):
    order = db.create_order(order_data)
    
    # Отправляем событие (не ждём ответа)
    connection = await aio_pika.connect_robust("amqp://guest:guest@rabbitmq:5672/")
    channel = await connection.channel()
    exchange = await channel.get_exchange("orders")
    
    message = aio_pika.Message(
        body=json.dumps({"order_id": order.id}).encode()
    )
    await exchange.publish(message, routing_key="order.created")
    await connection.close()
    
    return {"order_id": order.id}

5. Кеширование между сервисами

Redis ускоряет доступ к часто запрашиваемым данным:

import redis
import json

redis_client = redis.Redis(host="redis", port=6379, decode_responses=True)

@app.get("/products/{product_id}")
async def get_product(product_id: str):
    cached = redis_client.get(f"product:{product_id}")
    if cached:
        return json.loads(cached)
    
    product = db.get_product(product_id)
    redis_client.setex(f"product:{product_id}", 3600, json.dumps(product.__dict__))
    return product

6. Database per Service

Каждый сервис имеет свою БД для независимости:

Auth Service → auth_db (PostgreSQL)
Users Service → users_db (PostgreSQL)
Products Service → products_db (MongoDB)

Мониторинг и Автомасштабирование

import prometheus_client

request_count = prometheus_client.Counter(
    "requests_total",
    "Total requests",
    ["service", "endpoint"]
)

request_duration = prometheus_client.Histogram(
    "request_duration_seconds",
    "Request duration",
    ["service"]
)

@app.middleware("http")
async def track_metrics(request, call_next):
    start = time.time()
    response = await call_next(request)
    duration = time.time() - start
    
    request_count.labels(
        service="auth-service",
        endpoint=request.url.path
    ).inc()
    
    request_duration.labels(service="auth-service").observe(duration)
    return response

Кубернетес автоматически масштабирует сервисы по CPU:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: auth-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: auth-service
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Когда CPU >70% — Kubernetes добавляет инстансы (до 10).

Проблемы микросервисов

Distributed Tracing — сложно отследить запрос через несколько сервисов Решение: Jaeger, Zipkin

Network latency — каждый запрос медленнее Решение: кеширование, batch запросы, gRPC

Data consistency — сложные транзакции Решение: Saga pattern, event sourcing

Deployment complexity — нужно деплоить много сервисов Решение: Docker + Kubernetes

Когда микросервисы имеют смысл

✓ Проект получает 10000+ RPS ✓ Разные части имеют разные требования ✓ Команда больше 20 человек ✓ Нужна независимая разработка

✗ Стартап с 2-5 разработчиками ✗ Низкая нагрузка (100 RPS) ✗ Простой MVP

Итог

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