Почему микросервисы лучше подходят под высокую нагрузку?

Микросервисы и высокая нагрузка

Микросервисы не всегда лучше подходят под высокую нагрузку — это распространённое заблуждение. Правильнее сказать: микросервисы лучше управляют нагрузкой при определённых условиях. Давайте разберёмся в деталях.

Основное преимущество микросервисов при нагрузке

Независимая масштабируемость. В монолитном приложении вы масштабируете ВСЁ целиком. В микросервисной архитектуре масштабируете только то, что нужно.

Монолит:
Одно приложение (100% нагрузки) → Масштабируете всё → Неэффективно

Микросервисы:
Сервис1 (30% нагрузки) → масштабируете на 2 инстанса
Сервис2 (60% нагрузки) → масштабируете на 5 инстансов
Сервис3 (10% нагрузки) → 1 инстанс

Преимущества микросервисов при высокой нагрузке

1. Независимое масштабирование

# Монолит: масштабируешь всё приложение
app = Flask(__name__)

@app.route("/api/users")  # 10% трафика
def users(): ...

@app.route("/api/notifications")  # 80% трафика
def notifications(): ...

@app.route("/api/admin")  # 10% трафика
def admin(): ...

# Если нагрузка растёт на notifications, масштабируешь всё приложение

# Микросервисы: масштабируешь только нужное
# User Service (K8s Deployment)
replicas: 2

# Notification Service (K8s Deployment)
replicas: 10  # Только это масштабируем

# Admin Service (K8s Deployment)
replicas: 2

2. Изоляция отказов (Fault Isolation)

# Монолит: одна падающая функция падает всё
import time

@app.route("/api/users")
def get_users():
    # Медленная операция
    time.sleep(10)  # БД зависла
    return {"users": []}

# Вес приложение падает из-за одной операции

# Микросервисы: падает только один сервис
# user-service → зависла БД
# notification-service → работает нормально
# analytics-service → работает нормально

3. Независимые технологические стеки

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

User Service (Python FastAPI):
- ОптимальнаGO для работы с многопоточностью

Notification Service (Go):
- Хорошее для высокой параллельности

Analytics Service (Java Kafka Streams):
- Оптимально для обработки потоков

При монолите пришлось бы выбрать один язык

4. Кэширование на уровне сервиса

# Микросервис может кэшировать данные эффективнее
from functools import lru_cache
import asyncio

class NotificationService:
    def __init__(self):
        self.cache = {}  # Local cache
        self.ttl = 300
    
    @lru_cache(maxsize=10000)
    async def get_user_preferences(self, user_id: int):
        """Кэширует 10000 пользователей в памяти сервиса"""
        return await self.db.fetch_user_prefs(user_id)
    
    async def send_notification(self, user_id: int, message: str):
        prefs = await self.get_user_preferences(user_id)
        if prefs["notifications_enabled"]:
            await self.queue.push({"user_id": user_id, "message": message})

# Может содержать распределённый кэш
from redis import Redis

class UserService:
    def __init__(self):
        self.redis = Redis()
    
    async def get_user(self, user_id: int):
        # Проверяем local cache
        cached = self.local_cache.get(user_id)
        if cached:
            return cached
        
        # Проверяем Redis
        cached_redis = await self.redis.get(f"user:{user_id}")
        if cached_redis:
            self.local_cache[user_id] = cached_redis
            return cached_redis
        
        # Идём в БД
        user = await self.db.fetch_user(user_id)
        self.redis.set(f"user:{user_id}", user, ex=3600)
        return user

Недостатки микросервисов при нагрузке

1. Сетевая латентность

Каждый запрос между сервисами = сетевой запрос:

# Монолит: всё в памяти
def process_order(order_id):
    order = db.get_order(order_id)  # 1ms
    user = db.get_user(order.user_id)  # 1ms
    inventory = db.check_inventory(order.items)  # 1ms
    return {"order": order, "user": user, "inventory": inventory}
    # Всего: 3ms

# Микросервисы: сетевые запросы
def process_order(order_id):
    order = order_service.get(order_id)  # 1ms + 5ms сеть = 6ms
    user = user_service.get(order.user_id)  # 1ms + 5ms сеть = 6ms
    inventory = inventory_service.check(order.items)  # 1ms + 5ms сеть = 6ms
    return {"order": order, "user": user, "inventory": inventory}
    # Всего: 18ms (в 6 раз медленнее)

Решение: batch запросы и асинхронность

import asyncio
from httpx import AsyncClient

class OrderService:
    async def process_order(self, order_id: int):
        async with AsyncClient() as client:
            # Параллельные запросы
            order_task = client.get(f"/orders/{order_id}")
            user_task = client.get(f"/users/{order_id}")
            inventory_task = client.get(f"/inventory/check")
            
            order, user, inventory = await asyncio.gather(
                order_task, user_task, inventory_task
            )
            return {"order": order, "user": user, "inventory": inventory}
            # Всего: 6ms вместо 18ms

2. Сложность операционной логики

# Монолит: простая транзакция
def transfer_money(from_id, to_id, amount):
    db.update(f"user {from_id} -= {amount}")
    db.update(f"user {to_id} += {amount}")
    db.commit()  # Атомарно

# Микросервисы: сложнее (распределённые транзакции)
# User Service 1: выписываем деньги
# User Service 2: получаем деньги
# Что если Service 2 упадёт после успеха Service 1?
# Нужна Saga pattern или компенсирующие транзакции

from saga import Saga

saga = Saga()
saga.add_step(
    forward=lambda: user_service_1.withdraw(user_id, amount),
    compensate=lambda: user_service_1.deposit(user_id, amount)
)
saga.add_step(
    forward=lambda: user_service_2.deposit(user_id_2, amount),
    compensate=lambda: user_service_2.withdraw(user_id_2, amount)
)
await saga.execute()

Когда микросервисы лучше для нагрузки

1. Разные части имеют разную нагрузку

• Notifications: 1000 req/s
• Users: 100 req/s
• Orders: 50 req/s

2. Разные части требуют разного масштабирования

• Compute-intensive
• I/O-intensive
• Memory-intensive

3. Есть независимые критические пути

Критичный путь: Order Processing (99.99% uptime)
Некритичный путь: Analytics (95% uptime)

4. Большая команда с разными компетенциями

• Team A: Python (User Service)
• Team B: Go (Notification Service)
• Team C: Java (Analytics)

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

1. Стартап, малые нагрузки

from fastapi import FastAPI

app = FastAPI()

@app.get("/users")
async def get_users(): ...

@app.post("/orders")
async def create_order(): ...

# Просто, быстро масштабируется с нагрузкой

2. Высокая связность данных

Микросервисы медленнее из-за сетевых запросов
Монолит быстрее для тесно связанных операций

3. Малая команда Дополнительная сложность не стоит того

Гибридный подход (правильный)

# Монолит сначала
app = FastAPI()

@app.get("/users")
async def get_users(): ...

@app.get("/orders")
async def get_orders(): ...

# Когда Users начинают падать под нагрузкой
# Выделяешь User Service как отдельный микросервис

# Остальное остаётся в монолите, пока не понадобится масштабировать

Итоговые рекомендации

1. Начни с монолита — проще в разработке и отладке
2. Переходи на микросервисы только при наличии:
   • Реальной нагрузки на разные части приложения
   • Разных требований к масштабируемости
   • Команды готовой к сложности
3. Используй асинхронность и batch операции для сокращения сетевых запросов
4. Кэширование критично при микросервисах
5. Мониторинг и трейсинг обязательны (Jaeger, Prometheus)
6. Saga pattern для распределённых транзакций