Для чего использовал Spring Cloud в проекте

# Использование Spring Cloud в проектах

Spring Cloud - это набор инструментов для разработки распределённых систем и микросервисной архитектуры. Рассмотрим основные компоненты и их практическое применение.

1. Service Discovery (Обнаружение сервисов)

Spring Cloud Netflix Eureka

// Сервис регистрации (Eureka Server)
@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

// Микросервис с Eureka Client
@SpringBootApplication
@EnableEurekaClient
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }
}

// application.yml
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
  instance:
    appname: user-service
    prefer-ip-address: true

Проблема: Как микросервисы могут найти друг друга в распределённой системе, если IP адреса динамически меняются?

Решение: Eureka - реестр сервисов, где каждый микросервис регистрируется с именем. Другие сервисы могут найти его по имени, не зная IP.

2. Client-Side Load Balancing (Балансировка нагрузки)

Spring Cloud LoadBalancer + Feign

// Перед тем как отправить запрос к другому сервису
// нужно выбрать один из нескольких инстансов

// Eureka знает, что product-service имеет 3 инстанса:
// - product-service:8081 (CPU 30%)
// - product-service:8082 (CPU 10%)
// - product-service:8083 (CPU 50%)

// Spring Cloud LoadBalancer выбирает инстанс с наименьшей нагрузкой

@FeignClient(name = "product-service")
public interface ProductServiceClient {
    @GetMapping("/api/products/{id}")
    ProductDTO getProduct(@PathVariable Long id);
}

@Service
public class OrderService {
    @Autowired
    private ProductServiceClient productServiceClient;
    
    public OrderDTO createOrder(Long productId) {
        // LoadBalancer выбирает один инстанс product-service
        ProductDTO product = productServiceClient.getProduct(productId);
        // ...
    }
}

3. API Gateway (Шлюз для API)

Spring Cloud Gateway

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

Проблема: Клиент не должен знать адреса каждого микросервиса, их может быть много.

Решение: API Gateway - единая точка входа, перенаправляет запросы на нужные микросервисы.

4. Distributed Configuration (Распределённая конфигурация)

Spring Cloud Config

// Config Server
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

// Config Client (user-service)
@SpringBootApplication
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }
}

// bootstrap.yml
spring:
  application:
    name: user-service
  cloud:
    config:
      uri: http://config-server:8888

// application.yml на Config Server
spring:
  application:
    name: user-service

db:
  host: localhost
  port: 5432
  username: postgres

Проблема: Конфигурация разбросана по разным сервисам, сложно управлять при масштабировании.

Решение: Централизованный конфиг сервер для всех микросервисов.

5. Circuit Breaker (Предохранитель)

Spring Cloud Resilience4j

@Service
public class PaymentService {
    
    @CircuitBreaker(name = "payment-service",
                   fallbackMethod = "fallbackPayment")
    public PaymentResponse processPayment(Long orderId) {
        // Если внешний сервис платежей упадёт 50 раз подряд,
        // Circuit Breaker откроется и сразу вернёт fallback
        return externalPaymentService.pay(orderId);
    }
    
    public PaymentResponse fallbackPayment(Long orderId, Exception e) {
        // Резервное поведение: сохраняем заказ в очередь
        paymentQueue.add(orderId);
        return PaymentResponse.builder()
            .status("PENDING")
            .message("Payment service is unavailable")
            .build();
    }
}

Проблема: Если внешний API упадёт, наш сервис будет слать ему запросы вечно, зависнув.

Решение: Circuit Breaker автоматически перестанет слать запросы при обнаружении проблем и вернёт fallback.

6. Distributed Tracing (Распределённый трейсинг)

Spring Cloud Sleuth + Zipkin

// Автоматически добавляет trace ID в логи
// Полезно отследить запрос через цепь микросервисов

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

// application.yml
spring:
  sleuth:
    sampler:
      probability: 1.0  # Трейсировать все запросы
  zipkin:
    base-url: http://zipkin:9411/

@RestController
public class UserController {
    
    private static final Logger logger = LoggerFactory.getLogger(UserController.class);
    
    @GetMapping("/users/{id}")
    public UserDTO getUser(@PathVariable Long id) {
        // В логе автоматически появится:
        // [user-service,abc123def456,xyz789] User request started
        logger.info("User request started");
        
        UserDTO user = userService.getUser(id);
        
        logger.info("User request completed");
        return user;
    }
}

В Zipkin UI видно:

GET /orders/123
├── user-service [50ms]
│   ├── GET /users/456 [30ms]
│   └── internal processing [20ms]
├── product-service [100ms]
│   ├── GET /products/789 [60ms]
│   └── inventory check [40ms]
└── payment-service [150ms]
    └── POST /payments [150ms]

7. Message Broker Integration (Интеграция с очередями)

Spring Cloud Stream

// Producer
@Service
public class OrderService {
    
    @Autowired
    private StreamBridge streamBridge;
    
    public void createOrder(OrderDTO order) {
        // Сохраняем в БД
        Order saved = orderRepository.save(order);
        
        // Отправляем событие в очередь
        streamBridge.send("order-events-out-0", 
            OrderCreatedEvent.builder()
                .orderId(saved.getId())
                .amount(saved.getAmount())
                .build());
    }
}

// Consumer
@Service
public class PaymentService {
    
    @Bean
    public Function<OrderCreatedEvent, Void> processOrderCreated() {
        return event -> {
            // Автоматически срабатывает при получении события
            processPayment(event.getOrderId(), event.getAmount());
            return null;
        };
    }
}

// application.yml
spring:
  cloud:
    stream:
      bindings:
        processOrderCreated-in-0:
          destination: order-events
          group: payment-service-group

8. Практический пример: E-commerce система

Клиент
  ↓
[API Gateway] ← Service Discovery (Eureka)
  ↓
┌─────────────────────────────────────────┐
│ User-Service  │ Product-Service  │ ...  │ ← Load Balanced
└─────────────────────────────────────────┘
  ↓
[Config Server] - централизованная конфигурация
  ↓
[Message Broker] (RabbitMQ/Kafka) - async events
  ↓
[Zipkin] - распределённый трейсинг

Основные преимущества Spring Cloud

1. Масштабируемость - легко добавлять новые инстансы сервисов
2. Отказоустойчивость - circuit breakers предохраняют от каскадного отказа
3. Динамическое обнаружение - сервисы находят друг друга автоматически
4. Параллельная разработка - команды разрабатывают разные сервисы независимо
5. Операционная прозрачность - логирование, трейсинг, метрики в одном месте
6. Гибкость - легко менять реализацию (Eureka, Consul, Nacos)

Когда НЕ нужен Spring Cloud

• Монолитное приложение
• Маленькая команда (< 3 человек)
• Простая система с несколькими сервисами
• Low-latency требования (дополнительная сложность добавляет оверхед)

Spring Cloud - это мощный инструмент для масштабируемых распределённых систем, но добавляет операционную сложность.