Что такое микросервисная архитектура?

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

Микросервисная архитектура — это подход к разработке приложений, при котором крупное приложение разбивается на маленькие, независимые сервисы, каждый из которых отвечает за конкретный бизнес-функцию. Эти сервисы работают независимо, взаимодействуют через API и развёртываются отдельно.

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

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

Слабая связанность — сервисы общаются через хорошо определённые API (HTTP/REST, gRPC, Message Queue), а не через внутренние модули.

Высокая когезия — каждый сервис содержит только логику, относящуюся к его домену (Domain-Driven Design).

Отказоустойчивость — падение одного сервиса не ломает всю систему. Другие сервисы продолжают работать.

Архитектура типичного приложения

API Gateway
    |
    |--- User Service (управление пользователями)
    |--- Order Service (обработка заказов)
    |--- Payment Service (платежи)
    |--- Notification Service (уведомления)
    |--- Analytics Service (аналитика)

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

• Свой код и логику
• Собственную БД (отсутствие монолитной БД)
• Независимый деплой
• Свои API endpoints

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

1. Масштабируемость — можно масштабировать отдельный сервис, не трогая остальные

Если Payment Service перегружен — увеличиваем количество его инстансов
User Service остаётся без изменений

1. Гибкость в технологиях — User Service на Python, Payment на Go, Notification на Node.js

2. Быстрое развитие — разные команды работают параллельно над разными сервисами

3. Независимый деплой — обновляем User Service без остановки всего приложения

4. Резилентность — откат одного сервиса не влияет на остальные

Недостатки

1. Сложность операций — нужна хорошая инфраструктура (Kubernetes, Docker, мониторинг)

2. Сетевые задержки — сервисы общаются по сети (медленнее, чем прямой вызов функции)

3. Консистентность данных — сложнее обеспечить транзакции между несколькими БД

4. Мониторинг и отладка — сложнее отследить проблемы через несколько сервисов

Пример на Python

# User Service
from fastapi import FastAPI

app = FastAPI()

@app.get("/api/v1/users/{user_id}")
def get_user(user_id: int):
    return {"id": user_id, "name": "John Doe"}

@app.post("/api/v1/users")
def create_user(name: str, email: str):
    return {"id": 1, "name": name, "email": email}

# Order Service
import httpx
from fastapi import FastAPI

app = FastAPI()
USER_SERVICE_URL = "http://user-service:8000"

@app.post("/api/v1/orders")
async def create_order(user_id: int, product_id: int):
    # Запрашиваем данные пользователя у User Service
    async with httpx.AsyncClient() as client:
        user = await client.get(f"{USER_SERVICE_URL}/api/v1/users/{user_id}")
    
    return {
        "order_id": 1,
        "user_id": user_id,
        "product_id": product_id,
        "status": "created"
    }

Связь сервисов

Синхронная — REST API, gRPC (обслуживающий сервис ждёт ответа)

Асинхронная — Message Queue (RabbitMQ, Kafka), Event-driven (сервис отправляет событие и не ждёт)

Когда использовать

• Крупные приложения (100+ разработчиков)
• Нужна независимая масштабируемость
• Разные команды работают над разными функциями
• Нужна гибкость в выборе технологий

Когда НЕ использовать

• Маленький стартап (3-5 разработчиков) — усложнение без пользы
• Простое CRUD приложение
• Нет опыта с DevOps и Kubernetes

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