Какие плюсы и минусы использования микросервисной архитектуры?

Микросервисная архитектура: плюсы и минусы

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

Плюсы микросервисной архитектуры

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

• Можешь масштабировать только нужные сервисы
• Не нужно масштабировать всё приложение целиком

// Монолит: все компоненты масштабируются вместе
// Микросервисы: масштабируем только нужные сервисы

// В Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 10 # Масштабируем только user-service

Независимые развёртывания

• Каждый сервис развёртывается отдельно
• Не нужно ждать развёртывания других сервисов
• Минимизируешь время простоя при обновлениях

Технологическая гибкость

• Разные сервисы могут использовать разные технологии
• User-service на Node.js, Payment-service на Go, Notification-service на Python
• Свобода выбора БД для каждого сервиса (PostgreSQL, MongoDB, Redis)

// API Gateway маршрутизирует запросы
router.post('/api/users', (req, res) => {
  // Node.js User Service
});

router.post('/api/payments', async (req, res) => {
  // Запрос в Go Payment Service
  const response = await fetch('http://payment-service:3001/pay', {
    method: 'POST',
    body: JSON.stringify(req.body)
  });
});

Отказоустойчивость

• Если один сервис упал, остальные продолжают работать
• Можешь внедрить Circuit Breaker паттерн

// Circuit Breaker паттерн
class CircuitBreaker {
  private failures = 0;
  private state = 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
  private threshold = 5;

  async call(fn: () => Promise<any>) {
    if (this.state === 'OPEN') {
      throw new Error('Service unavailable');
    }
    
    try {
      const result = await fn();
      this.failures = 0;
      this.state = 'CLOSED';
      return result;
    } catch (err) {
      this.failures++;
      if (this.failures >= this.threshold) {
        this.state = 'OPEN';
      }
      throw err;
    }
  }
}

Упрощённое развитие для больших команд

• Разные команды работают над разными сервисами
• Меньше конфликтов в коде
• Каждая команда может выбрать свой stack

Минусы микросервисной архитектуры

Сложность сетевого взаимодействия

• Сервисы общаются по сети (HTTP, gRPC, Message Queue)
• Добавляется задержка (latency)
• Возникают проблемы с надёжностью сети

// Проблема: распределённая система сложнее
const user = await userService.getUser(id); // 50ms
const orders = await orderService.getOrders(user.id); // 100ms
const payments = await paymentService.getPayments(orders); // 75ms
// Всего: 225ms (вместо 5ms в монолите)

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

• Сложно обеспечить ACID при работе с несколькими БД
• Нужна сага паттерн или событийная архитектура

// Сага паттерн: оркестрирование компенсирующих транзакций
class CreateOrderSaga {
  async execute(order) {
    try {
      await orderService.create(order); // Step 1
      await paymentService.charge(order); // Step 2
      await inventoryService.reserve(order); // Step 3
    } catch (err) {
      // Откатываем в обратном порядке
      await orderService.cancel(order);
      throw err;
    }
  }
}

Мониторинг и debugging

• Сложнее отследить ошибку через несколько сервисов
• Нужна distributed tracing (Jaeger, Zipkin)

// Distributed tracing
import { trace } from '@opentelemetry/api';

const tracer = trace.getTracer('user-service');
const span = tracer.startSpan('getUser');

try {
  const user = await db.users.findOne(id);
  span.setStatus({ code: SpanStatusCode.OK });
} finally {
  span.end();
}

Операционная сложность

• Нужно управлять множеством сервисов
• Требуется контейнеризация (Docker), оркестрация (Kubernetes)
• CI/CD pipeline сложнее
• Больше работы для DevOps

Дублирование кода

• Shared libraries нужно синхронизировать между сервисами
• Может быть дублирование бизнес-логики

Проблемы консистентности данных

• Eventual consistency вместо сильной консистентности
• Сложнее обновлять данные синхронно

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

✅ Используй микросервисы если:

• Большой проект с множеством команд
• Разные части приложения имеют разные требования масштабирования
• Нужна независимость развёртывания и развития
• Готов к операционной сложности

❌ Избегай микросервисов если:

• Проект маленький или в ранней стадии
• Команда маленькая (< 10 человек)
• Нет опыта с распределёнными системами
• Не готов к дополнительной инфраструктуре