Что такое микросервисы и какие преимущества/недостатки у микросервисной архитектуры?

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

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

Определение

Микросервис - это отдельный, самостоятельный сервис, который:

• Решает одну бизнес-задачу
• Имеет свою БД
• Общается с другими сервисами через API (REST, gRPC, message queue)
• Деплоится независимо
• Может быть написан на разных языках/технологиях

Пример архитектуры

Monolith (плохо):
┌─────────────────────────────────┐
│    Монолитное приложение        │
├─────────────────────────────────┤
│  Users Module                   │
│  Orders Module                  │
│  Payments Module                │
│  Notifications Module           │
│  Reports Module                 │
│  (Одна БД, один рант, один jar) │
└─────────────────────────────────┘

Микросервисы (хорошо):
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│  User        │  │  Order       │  │  Payment     │
│  Service     │  │  Service     │  │  Service     │
│              │  │              │  │              │
│  PostgreSQL  │  │  PostgreSQL  │  │  MongoDB     │
└──────────────┘  └──────────────┘  └──────────────┘
        ↑                ↑                  ↑
        └────────────────┼──────────────────┘
           API Gateway / Service Mesh

Примеры микросервисов в реальности

// Монолитное приложение (старый подход)
@RestController
@RequestMapping("/api")
public class MonolithController {
    @Autowired private UserService userService;
    @Autowired private OrderService orderService;
    @Autowired private PaymentService paymentService;
    @Autowired private NotificationService notificationService;
    
    @PostMapping("/users")
    public User createUser(@RequestBody UserDTO dto) {
        // User service работает
        return userService.create(dto);
    }
    
    @PostMapping("/orders")
    public Order createOrder(@RequestBody OrderDTO dto) {
        // Order service работает
        return orderService.create(dto);
    }
}

// Микросервисный подход - User Service
@SpringBootApplication
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }
}

@RestController
@RequestMapping("/api/v1/users")
public class UserController {
    @Autowired private UserService userService;
    
    @PostMapping
    public User createUser(@RequestBody UserDTO dto) {
        User user = userService.create(dto);
        // Отправляет event в message queue
        eventPublisher.publish(new UserCreatedEvent(user));
        return user;
    }
    
    @GetMapping("/{id}")
    public User getUser(@PathVariable Long id) {
        return userService.findById(id);
    }
}

// Микросервисный подход - Order Service
@SpringBootApplication
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

@RestController
@RequestMapping("/api/v1/orders")
public class OrderController {
    @Autowired private OrderService orderService;
    @Autowired private UserServiceClient userClient;  // вызывает User Service
    
    @PostMapping
    public Order createOrder(@RequestBody OrderDTO dto) {
        // Проверяем пользователя в User Service
        User user = userClient.getUser(dto.getUserId());
        
        Order order = orderService.create(dto, user);
        
        // Отправляем событие в очередь
        eventPublisher.publish(new OrderCreatedEvent(order));
        
        return order;
    }
}

// Клиент для вызова другого сервиса
@Service
public class UserServiceClient {
    @Autowired private RestTemplate restTemplate;
    
    public User getUser(Long userId) {
        String url = "http://user-service:8080/api/v1/users/" + userId;
        return restTemplate.getForObject(url, User.class);
    }
}

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

1. Масштабируемость

Если много заказов, можно масштабировать только Order Service:

┌──────────────┐
│ User Service │  (1 инстанс)
└──────────────┘

┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ Order Srv #1 │  │ Order Srv #2 │  │ Order Srv #3 │  (3 инстанса)
└──────────────┘  └──────────────┘  └──────────────┘

┌──────────────┐
│ Payment Srv  │  (1 инстанс)
└──────────────┘

2. Независимая разработка

• Team A разрабатывает User Service на Java
• Team B разрабатывает Order Service на Go
• Team C разрабатывает Payment Service на Python
• Все используют REST API для общения

3. Независимый деплой

# Деплой только User Service
docker pull user-service:v2.0
docker run -d user-service:v2.0

# Order Service продолжает работать!

4. Изоляция ошибок

// Если Payment Service упал
try {
    Payment payment = paymentServiceClient.charge(order);
} catch (ServiceUnavailableException e) {
    // User Service продолжает работать
    // Можно использовать circuit breaker pattern
    logger.error("Payment service down, retrying...");
}

5. Гибкость технологий

User Service → Java + PostgreSQL
Order Service → Go + MongoDB
Notification Service → Node.js + Redis
Reports Service → Python + ClickHouse

Выбираешь оптимальный стек для каждой задачи!

6. Быстрый старт и deployment

• Новая версия User Service может быть развёрнута за 1 минуту
• Остальные сервисы не влияют

Недостатки микросервисов

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

// Медленнее чем локальный вызов:
User user = userService.findById(123);  // локальный вызов - микросекунды

// vs
User user = userServiceClient.getUser(123);  // HTTP запрос - миллисекунды

// Если нужно вызвать много сервисов:
User user = userClient.getUser(id);          // 50ms
Orders orders = orderClient.getOrders(id);   // 50ms
Payments payments = paymentClient.getPayments(id);  // 50ms
Total: 150ms! (вместо 1ms в монолите)

2. Сложность отладки

Ошибка проходит через несколько сервисов:
Client → API Gateway → User Service → Order Service → Payment Service → DB

Нужны: распределённое логирование (ELK), трейсинг (Jaeger), мониторинг

3. Каскадные сбои

Если User Service упал:
→ Order Service не может создать заказ
→ Payment Service не может обработать платёж
→ Весь сервис падает (нужны circuit breakers, retry logic)

4. Управление данными сложнее

// В монолите - одна БД:
Transaction tx = session.beginTransaction();
User user = createUser(...);
Order order = createOrder(...);
tx.commit();  // Всё атомарно

// В микросервисах - разные БД:
User user = userService.createUser(...);  // Успех
Order order = orderService.createOrder(...);  // Ошибка!
// Откатывать нужно вручную (saga pattern, compensation)

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

# Нужно управлять 10+ сервисами:
docker compose logs user-service      # логи
kubectl get pods -l app=order-service # статус
kubectl scale deployment/order-service --replicas=3  # масштабирование
prometheus, grafana, jaeger, elk...  # мониторинг

6. Дороже разработки

• Нужны опытные инженеры
• Инфраструктура сложнее (Kubernetes, Service Mesh)
• Больше операционных затрат

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

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

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

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

• ❌ Маленький проект или стартап
• ❌ Одна маленькая команда
• ❌ Высокая консистентность данных критична
• ❌ Нет опыта DevOps/Kubernetes
• ❌ Нужна простота разработки

Правило: начни с монолита!

Время развития:

Монолит:        Day 1 → Day 30 → Day 365 (легко)
                (быстро развиваешься, потом замедлишься)

Микросервисы:  Day 1 (тяжело) → Day 30 → Day 365 (быстро)
                (сложная инфра в начале, но масштабируется)

Большинство успешных компаний начали с монолита, а потом разбили на микросервисы:

• Netflix: монолит → микросервисы (2008)
• Amazon: монолит → микросервисы (2002)
• Uber: монолит → микросервисы (2015)

Заключение

Микросервисы - это не silver bullet. Это торговля сложностью разработки на сложность операций. Выбирай в зависимости от того, какая сложность дешевле для твоего проекта.