Почему микросервисную архитектуру сложно поддерживать?

Микросервисная архитектура: сложность поддержки

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

1. Сетевое взаимодействие и задержки

Вместо функционального вызова за микросекунды, микросервисы общаются через HTTP/gRPC — это медленно:

# Монолит: быстро
result = user_service.get_user(user_id)

# Микросервисы: медленно (latency 50-500ms)
response = requests.get('http://user-service:8001/users/{user_id}')
result = response.json()

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

2. Распределённые транзакции и консистентность

Невозможно использовать ACID транзакции. Вместо этого нужно использовать паттерн Saga с ручной откаткой:

# Микросервисы: сложная логика
async def create_order(user_id, items):
    # Шаг 1: создать заказ
    order = await order_service.create(user_id, items)
    
    # Шаг 2: зарезервировать товар
    try:
        await inventory_service.reserve(items)
    except Exception:
        # Откатить заказ
        await order_service.cancel(order.id)
        raise
    
    # Шаг 3: обработать платёж
    try:
        payment = await payment_service.process(order)
    except Exception:
        # Откатить всё
        await inventory_service.release(items)
        await order_service.cancel(order.id)
        raise
    
    return order

Любая ошибка в цепи требует ручной координации.

3. Отладка и трассировка ошибок

Когда что-то ломается, непонятно где именно:

User Client
  → API Gateway (5ms)
    → Auth Service (50ms) ❌ ERROR 500
      → Database

Нужна распределённая трассировка (Jaeger, Zipkin):

from jaeger_client import Config

config = Config(
    config={
        'sampler': {'type': 'const', 'param': 1},
        'local_agent': {'reporting_host': 'localhost', 'reporting_port': 6831},
    },
    service_name='my-service',
)
tracer = config.initialize_tracer()

with tracer.start_span('process_order') as span:
    try:
        result = await order_service.create(order)
    except Exception as e:
        span.set_tag('error', True)
        span.log_kv({'event': 'error', 'message': str(e)})
        raise

4. Развёртывание и управление версиями

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

• Версию
• Зависимости
• Docker-образ
• Configuration
• Database schema

Развёртывание становится очень сложным:

# Нужно откатить несовместимую версию
docker pull user-service:2.1.0
docker pull order-service:1.5.0
docker pull payment-service:3.2.0

# Если 2.1.0 несовместима с 1.5.0 — всё падает
# Нужно снова откатывать: 2.0.9, 1.5.0, 3.1.9

5. Data duplication и синхронизация

Каждый сервис часто имеет свою БД. Возникает необходимость синхронизации:

# User Service Database
users = [
    {'id': 1, 'name': 'Alice', 'email': 'alice@example.com'}
]

# Order Service Database (копия для производительности)
user_cache = [
    {'id': 1, 'name': 'Alice', 'email': 'alice@example.com'}
]

# Когда User Service обновляет email, Order Service не знает об этом!
# Возникает несогласованность данных

# Решение: Event-driven архитектура (Kafka)
# User Service публикует событие:
kafka.publish('user.updated', {'user_id': 1, 'email': 'newemail@example.com'})

# Order Service подписывается:
@kafka.topic('user.updated')
def on_user_updated(event):
    user_cache[event['user_id']]['email'] = event['email']

6. Monitoring и логирование

Логи разбросаны по разным контейнерам, нужна централизация:

# Without logging infrastructure
app.logger.error('User not found')  # Где найти этот лог?

# With ELK Stack
from pythonjsonlogger import jsonlogger

logHandler = logging.StreamHandler()
formatter = jsonlogger.JsonFormatter()
logHandler.setFormatter(formatter)
logger = logging.getLogger()
logger.addHandler(logHandler)

logger.error('User not found', extra={'user_id': 123, 'service': 'user-service'})
# Отправляется в Elasticsearch → видно в Kibana

7. Балансировка нагрузки и масштабирование

Нужно правильно разместить 50+ сервисов на сотнях машин:

# Kubernetes Service
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 5
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: user-service
        image: user-service:2.1.0
        resources:
          requests:
            memory: '256Mi'
            cpu: '250m'

8. API версионирование и обратная совместимость

Старый клиент должен работать с новым API:

# v1 endpoint (устарел, но работает)
@app.get('/api/v1/users/{user_id}')
def get_user_v1(user_id: int):
    return {
        'id': user_id,
        'name': 'Alice',
        'email': 'alice@example.com'
    }

# v2 endpoint (новый формат)
@app.get('/api/v2/users/{user_id}')
def get_user_v2(user_id: int):
    return {
        'id': user_id,
        'first_name': 'Alice',
        'last_name': 'Smith',
        'contact': {
            'email': 'alice@example.com',
            'phone': '+1234567890'
        }
    }

# Нужно поддерживать обе версии до истечения срока устаревания

9. Сетевые разделения (Network Partitions)

Сеть ненадёжна. Один сервис может стать недоступным:

# Попытка подключиться к Payment Service
import tenacity

@tenacity.retry(
    stop=tenacity.stop_after_attempt(3),
    wait=tenacity.wait_exponential(multiplier=1, min=2, max=10),
    retry=tenacity.retry_if_exception_type(requests.RequestException)
)
def process_payment(order_id, amount):
    response = requests.post(
        'http://payment-service/process',
        json={'order_id': order_id, 'amount': amount},
        timeout=5
    )
    return response.json()

# Если Payment Service недоступна, нужно:
# 1. Переход в режим degraded
# 2. Кэширование платежей
# 3. Асинхронная обработка через очередь

10. Сложность интеграционного тестирования

Невозможно запустить всё локально:

# Нужно поднимать весь стек
docker-compose -f docker-compose.test.yml up

# Или использовать контрактное тестирование
def test_order_service_calls_user_service():
    # Мокировать User Service
    with responses.RequestsMock() as rsps:
        rsps.add(
            responses.GET,
            'http://user-service/users/1',
            json={'id': 1, 'name': 'Alice'},
            status=200
        )
        
        result = order_service.create_order(user_id=1, items=[...])
        assert result['user_name'] == 'Alice'

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

• ✅ Команд много (>50) и они работают независимо
• ✅ Разные сервисы имеют разные требования к масштабируемости
• ✅ Независимое развёртывание критично
• ✅ Готовы к Kubernetes, DevOps infrastructure

Когда монолит лучше?

• ✅ Команда маленькая (<15 человек)
• ✅ Требования к отказоустойчивости низкие
• ✅ Нет больших нагрузок
• ✅ Быстрое развитие приоритета

Вывод

Микросервисная архитектура — это решение организационных проблем, а не технических. Она добавляет:

• Сетевые задержки
• Сложность отладки
• Проблемы с консистентностью
• Необходимость в сложной инфраструктуре (K8s, monitoring, tracing)
• Дополнительный операционный оверхед

Используй микросервисы только если боль от монолита больше, чем боль от распределённых систем.