Какие знаешь микросервисы?

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

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

Что такое микросервисы

Микросервис — это небольшое, независимо развертываемое приложение, которое:

• Отвечает за одну бизнес-функцию (Bounded Context из Domain-Driven Design)
• Имеет собственную базу данных
• Взаимодействует с другими сервисами через API (REST, gRPC, message queues)
• Может быть разработано и развернуто независимо
• Написано на любом языке/фреймворке

Монолит:                    Микросервисы:
┌──────────────────┐        ┌─────────┐  ┌──────────┐  ┌───────────┐
│   Приложение     │        │ Users   │  │ Products │  │ Orders    │
│  ├─ Users        │   →    │ Service │  │ Service  │  │ Service   │
│  ├─ Products     │        │  + DB   │  │  + DB    │  │  + DB     │
│  └─ Orders       │        └─────────┘  └──────────┘  └───────────┘
│      + БД        │
└──────────────────┘

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

• Независимое масштабирование — если Orders сервис получает больше нагрузки, масштабирую только его
• Технологическая гибкость — один сервис на Java/Spring, другой на Go, третий на Node.js
• Faster deployment — не нужно развертывать всё приложение для изменения в одном сервисе
• Isolation failures — если Users сервис упал, Orders может продолжать работать
• Лучше для больших команд — разные команды работают независимо на разных сервисах
• Проще на раннем этапе разработки — не нужно больших координаций между компонентами

Вызовы микросервисов

• Сложность распределенной системы — теперь нужно думать о сетевых ошибках, timeouts, circuit breakers
• Data consistency — нельзя просто использовать транзакции через сервисы, нужны saga patterns
• Операционная сложность — нужно мониторить много сервисов, логировать, трассировать
• Задержки сети — микросервисы медленнее монолита из-за HTTP/gRPC calls
• Debugging — сложнее найти проблему, когда она между несколькими сервисами

Spring Boot для микросервисов

В моей практике я использовал Spring Boot как основу для микросервисов. Это отличный выбор благодаря:

@SpringBootApplication
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

@RestController
@RequestMapping("/api/orders")
public class OrderController {
    @GetMapping("/{id}")
    public ResponseEntity<Order> getOrder(@PathVariable String id) {
        // бизнес-логика
        return ResponseEntity.ok(order);
    }
}

Spring Cloud для оркестрации

Spring Cloud предоставляет инструменты для работы с микросервисами:

1. Service Discovery (Eureka)
   • Автоматическое регистрирование сервисов
   • Динамическое обнаружение благодаря Eureka Server
   • Клиент-сервис может найти другие сервисы без hardcoded URLs

@SpringBootApplication
@EnableEurekaClient
public class OrderServiceApplication { }

// Другой сервис
@RestController
public class OrderController {
    @Autowired
    private RestTemplate restTemplate; // Load balanced
    
    public void createOrder(Order order) {
        // Call user service by name
        User user = restTemplate.getForObject(
            "http://user-service/api/users/" + order.getUserId(), 
            User.class
        );
    }
}

1. API Gateway (Zuul, Spring Cloud Gateway)
   • Единая точка входа для клиентов
   • Маршрутизация к нужному микросервису
   • Centralized authentication и rate limiting

@Configuration
public class GatewayConfiguration {
    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("order-service", r -> r.path("/orders/**")
                .uri("lb://order-service"))
            .route("user-service", r -> r.path("/users/**")
                .uri("lb://user-service"))
            .build();
    }
}

1. Load Balancing (Ribbon)

   • Распределение нагрузки между несколькими инстансами
   • Встроена в Spring Cloud

2. Circuit Breaker (Hystrix, Resilience4j)

   • Защита от cascade failures
   • Если сервис недоступен, быстро возвращаем ошибку без ожидания timeout

@Service
public class OrderService {
    
    @CircuitBreaker(name = "userServiceCall")
    public User getUser(String userId) {
        return restTemplate.getForObject(
            "http://user-service/api/users/" + userId,
            User.class
        );
    }
}

Inter-service Communication

Synchronous (REST/gRPC)

• Request-response паттерн
• Простой для понимания
• Но может быть медленным и создавать зависимости

Asynchronous (Message Queues)

• Один сервис отправляет событие в message broker (RabbitMQ, Kafka)
• Другой сервис слушает и обрабатывает
• Loose coupling, но сложнее debuggить

// Отправка события в Kafka
@Service
public class OrderService {
    @Autowired
    private KafkaTemplate<String, Order> kafkaTemplate;
    
    public void createOrder(Order order) {
        // сохранить заказ
        kafkaTemplate.send("orders-topic", order);
    }
}

// Слушание события в другом сервисе
@Service
public class NotificationService {
    @KafkaListener(topics = "orders-topic")
    public void handleOrderCreated(Order order) {
        // отправить email пользователю
    }
}

Saga Pattern для распределённых транзакций

Когда нужна atomicity между микросервисами без global transactions:

// Choreography: сервисы отправляют события друг другу
// 1. OrderService создает заказ и отправляет OrderCreated
// 2. PaymentService слушает OrderCreated, берёт платёж, отправляет PaymentCompleted
// 3. InventoryService слушает PaymentCompleted, резервирует товар

// Orchestration: центральный сервис координирует
@Service
public class OrderSagaOrchestrator {
    public void executeOrderSaga(Order order) {
        // 1. Create payment
        Payment payment = paymentService.createPayment(order.getAmount());
        
        // 2. Reserve inventory
        try {
            inventoryService.reserve(order.getItems());
        } catch (InsufficientInventoryException e) {
            // Компенсирующая транзакция
            paymentService.refund(payment.getId());
            throw e;
        }
    }
}

Мониторинг и логирование

В микросервисной архитектуре важно иметь centralized logging и distributed tracing:

• ELK Stack (Elasticsearch, Logstash, Kibana) для логов
• Jaeger или Zipkin для distributed tracing — отслеживание запроса через все сервисы
• Prometheus + Grafana для метрик
• Spring Cloud Sleuth для автоматического добавления trace IDs

@Configuration
public class TracingConfiguration {
    // Spring Cloud Sleuth автоматически добавляет traceId в логи
    // Все логи имеют формат: [serviceName,traceId,spanId,exportable]
}

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

Микросервисы не серебряная пуля. Я использую их когда:

• Большой проект с несколькими командами
• Разные требования к масштабированию разных компонентов
• Разные технологические стеки имеют смысл
• Независимое развертывание критично для быстрой доставки

Для маленьких проектов обычно лучше начать с монолита, а потом migratить к микросервисам, если появится необходимость.

Заключение

Микросервисы — мощный инструмент, но требуют опыта в распределенных системах. В моей практике успешные миграции к микросервисам были основаны на глубоком понимании бизнеса (DDD), хорошем мониторинге и опытной команде DevOps.