Как обновить микросервис, чтобы не нарушить работу других?

Обновление микросервиса без нарушения других сервисов

Деплой в микросервисной архитектуре требует особой осторожности. Один падающий сервис может каскадом повалить остальные. Вот проверенные подходы.

1. Принцип обратной совместимости (Backward Compatibility)

Правило: никогда не удаляйте API поля сразу.

# ПЛОХО: старая версия
class UserResponse(BaseModel):
    id: int
    name: str
    email: str

# Если удалить 'email', клиенты сломаются!

# ХОРОШО: новая версия
class UserResponse(BaseModel):
    id: int
    name: str
    email: str
    # Добавляем новое поле
    phone: str = None  # Опциональное, старые клиенты игнорируют

# Стратегия удаления (3 версии):
# v1: email обязательно
# v2: email опционально, документируем deprecation
# v3: можно удалить email

2. Вверсионирование API

Используйте версии в URL:

from fastapi import FastAPI, APIRouter

app = FastAPI()

# v1 с поддержкой старого формата
v1_router = APIRouter(prefix="/api/v1", tags=["v1"])

@v1_router.get("/users/{user_id}")
async def get_user_v1(user_id: int):
    user = db.users.get(user_id)
    return {
        "id": user.id,
        "name": user.name,
        "email": user.email
    }

# v2 с новым форматом
v2_router = APIRouter(prefix="/api/v2", tags=["v2"])

@v2_router.get("/users/{user_id}")
async def get_user_v2(user_id: int):
    user = db.users.get(user_id)
    return {
        "id": user.id,
        "name": user.name,
        "email": user.email,
        "phone": user.phone,
        "created_at": user.created_at.isoformat()
    }

app.include_router(v1_router)
app.include_router(v2_router)

# Клиенты могут использовать v1 или v2, оба работают параллельно

3. Blue-Green Deployment

Стратегия: две идентичные среды, переключение мгновенное.

#!/bin/bash
# Структура:
# Blue (текущая версия) — user-service-blue
# Green (новая версия) — user-service-green
# Load Balancer управляет трафиком

# Шаг 1: Развернуть новую версию на Green
docker pull user-service:v2.0.0
docker run -d --name user-service-green user-service:v2.0.0

# Шаг 2: Проверить здоровье Green
health_check=$(curl -s http://user-service-green:8000/health)
if [ $health_check != '"ok"' ]; then
    echo "Green failed health check"
    docker stop user-service-green
    exit 1
fi

# Шаг 3: Переключить трафик (Load Balancer)
# nginx/HAProxy/K8S перенаправляет весь трафик на Green
nginx_config_update user-service-green

# Шаг 4: Оставить Blue как fallback на час
sleep 3600
docker stop user-service-blue

echo "Deployment successful"

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

• Мгновенный rollback (просто переключите обратно на Blue)
• Полное тестирование перед переключением
• Нулевой downtime

4. Canary Deployment

Стратегия: постепенное увеличение трафика на новую версию.

# Kubernetes Canary пример
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-canary
spec:
  replicas: 1  # Только 10% трафика
  selector:
    matchLabels:
      app: user-service
      version: v2
  template:
    metadata:
      labels:
        app: user-service
        version: v2
    spec:
      containers:
      - name: user-service
        image: user-service:v2.0.0
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8000

График рулевого развертывания:

Время    Новая версия
10:00    10% трафика
10:15    25% трафика
10:30    50% трафика
10:45    100% трафика
11:00    Удалить старую версию

Мониторинг во время Canary:

# Отслеживать метрики ошибок
from prometheus_client import Counter

requests_total = Counter(
    'requests_total',
    'Total requests',
    ['version', 'endpoint', 'status']
)

errors_by_version = Counter(
    'errors_total',
    'Total errors',
    ['version', 'error_type']
)

@app.get("/users/{user_id}")
async def get_user(user_id: int):
    try:
        user = db.users.get(user_id)
        requests_total.labels(
            version=os.getenv('VERSION'),
            endpoint='get_user',
            status='success'
        ).inc()
        return user
    except Exception as e:
        errors_by_version.labels(
            version=os.getenv('VERSION'),
            error_type=type(e).__name__
        ).inc()
        requests_total.labels(
            version=os.getenv('VERSION'),
            endpoint='get_user',
            status='error'
        ).inc()
        raise

5. Rolling Deployment

Постепенно заменяйте инстансы старой версии на новую.

# Kubernetes Rolling Update
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1  # Максимум 1 новый pod одновременно
      maxUnavailable: 0  # Никогда не больше 1 недоступного
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: user-service
        image: user-service:v2.0.0
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8000
          initialDelaySeconds: 5
          periodSeconds: 5

6. Feature Flags для безопасного развертывания

Развертывайте код, но отключайте новую функцию по умолчанию.

from fastapi import FastAPI, Request
import os

app = FastAPI()

class FeatureFlags:
    NEW_EMAIL_VALIDATION = os.getenv('FEATURE_NEW_EMAIL_VALIDATION', 'false').lower() == 'true'
    NEW_PRICING_ENGINE = os.getenv('FEATURE_NEW_PRICING', 'false').lower() == 'true'

@app.post("/users")
async def create_user(request: Request):
    user_data = await request.json()
    
    if FeatureFlags.NEW_EMAIL_VALIDATION:
        # Новая валидация
        validate_email_strict(user_data['email'])
    else:
        # Старая валидация
        validate_email_simple(user_data['email'])
    
    return {"status": "created"}

@app.get("/calculate-price")
async def calculate_price(product_id: int):
    if FeatureFlags.NEW_PRICING_ENGINE:
        return {"price": calculate_with_new_engine(product_id)}
    else:
        return {"price": calculate_with_old_engine(product_id)}

Развертывание:

# 1. Развернуть код с новой функцией (выключена)
kubectl set image deployment/user-service user-service=user-service:v2.0.0

# 2. Убедиться, что всё работает
kubectl rollout status deployment/user-service

# 3. Включить для 10% пользователей
kubectl set env deployment/user-service FEATURE_NEW_EMAIL_VALIDATION=true -l version=canary

# 4. Мониторить ошибки
sleep 300
error_rate=$(prometheus_query 'errors[5m]')
if [ $error_rate -gt 1 ]; then
    kubectl set env deployment/user-service FEATURE_NEW_EMAIL_VALIDATION=false
    exit 1
fi

# 5. Увеличить до 100%
kubectl set env deployment/user-service FEATURE_NEW_EMAIL_VALIDATION=true

7. API Gateway для управления версиями

Задача версионирования делегируйте Gateway:

# Kong / API Gateway конфиг
routes:
  - path: /users/*
    version: v1
    upstream_url: http://user-service-v1:8000
    weight: 90  # 90% трафика
  - path: /users/*
    version: v2
    upstream_url: http://user-service-v2:8000
    weight: 10  # 10% трафика
    # Постепенно увеличивайте weight

8. Чеклист перед развертыванием

• Обратная совместимость: старые клиенты должны работать
• Миграция данных: если БД изменилась, миграция выполнена
• Health checks: endpoint /health отвечает корректно
• Метрики: всё логируется и метрики доступны
• Rollback план: способны быстро откатиться
• Безопасность: нет утечек credentials в логах
• Производительность: нет утечек памяти, CPU в норме
• Зависимости: версии совместимы с другими сервисами

Итог

Совет: комбинируйте подходы: развертывайте с Rolling/Blue-Green, но используйте Feature Flags для критичных функций.