🧩 Микросервисы: Укрощение хаоса (Spring Cloud)

Когда у вас один сервис, всё просто. Но когда их становится 10, 20 или 50, возникают вопросы:

1. Как сервису А узнать IP-адрес сервиса Б? (А если он меняется динамически?)
2. Как не писать тонны кода для HTTP-запросов?
3. Как клиенту (фронтенду) обращаться ко всей этой куче сервисов?

Для этого есть три главных инструмента.

1️⃣ Eureka: Телефонная книга (Service Discovery)

В облаке сервисы постоянно перезапускаются, меняют IP-адреса и порты. Хардкодить https://localhost:8081 в коде - самоубийство.

Eureka Server - это реестр.

🔴Когда сервис (например, OrderService) запускается, он звонит в Eureka: "Привет, я OrderService, мой IP такой-то".

🔴Когда UserService хочет найти заказы, он спрашивает Eureka: "Где сейчас живет OrderService?".

В коде:
Вам нужно просто добавить аннотацию @EnableDiscoveryClient, и магия произойдет сама. Сервисы будут находить друг друга по имени, а не по IP.

2️⃣ OpenFeign: Магия общения

Окей, адрес мы нашли. Теперь нужно отправить запрос.
Раньше мы использовали RestTemplate - это было громоздко и некрасиво.
Feign позволяет вызывать удаленный REST-сервис так, будто это обычный метод интерфейса в вашем коде.

Было (RestTemplate):

String url = "https://order-service/orders/" + userId;
List<Order> orders = restTemplate.getForObject(url, List.class); // Фу, нетипизированно

Стало (FeignClient):
Вы просто пишете интерфейс, а реализацию Spring сгенерирует сам!

@FeignClient(name = "order-service") // Имя сервиса в Eureka
public interface OrderClient {
    
    @GetMapping("/orders/{userId}")
    List<Order> getUserOrders(@PathVariable Long userId);
}

// Использование в сервисе:
// List<Order> orders = orderClient.getUserOrders(123L);

Это называется Декларативный REST-клиент. Чисто, красиво, типизировано.

3️⃣ API Gateway: Единая точка входа

Представьте, что у вас 50 микросервисов. Фронтенд не должен знать адреса каждого из них (api.com:8081, api.com:8082...). Это небезопасно и сложно (CORS error, привет 👋).

Spring Cloud Gateway - это вахтер на входе.
Весь внешний мир стучится только в него (например, на порт 8080), а он уже сам разруливает, куда отправить запрос.

Что он делает:

1. Маршрутизация: /users/** -> лети в UserService, /orders/** -> лети в OrderService.

2. Безопасность: Проверяет JWT токен один раз на входе.

3. Rate Limiting: "Не больше 10 запросов в секунду от этого юзера".

Пример конфига (application.yaml):

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://USER-SERVICE # lb = Load Balancer (через Eureka)
          predicates:
            - Path=/users/**

⚡ Итог: Как это работает вместе?

1. Сервисы просыпаются и регистрируются в Eureka.

2. Фронтенд шлет запрос на Gateway.

3. Gateway спрашивает у Eureka адрес нужного сервиса и пересылает запрос.

4. Если сервисам нужно пообщаться между собой, они используют Feign.

#Java #Microservices #SpringCloud #Eureka #Feign

📲 Мы в MAX

👉@BookJava

📨 Apache Kafka: Нервная система микросервисов

Представьте, что вы заказали пиццу.

🔴REST подход: Вы стоите у прилавка и смотрите на повара, пока он не закончит. Вы не можете отойти. Если повар уснул - вы застряли.
🔴Kafka подход: Вы бросаете чек в коробку "Заказы" и уходите по своим делам. Повар возьмет заказ, когда освободится. Когда пицца будет готова, он положит её на стол выдачи, и вы получите уведомление.

Kafka - это распределенный лог событий. Это не просто очередь, это история всего, что произошло в системе.

🧩 Основные понятия

1. Topic (Топик) - Это "папка" или канал, куда падают сообщения. Например: orders-topic, email-topic.

2. Producer (Продюсер) - Тот, кто пишет сообщения в топик (например, сервис Заказов).

3. Consumer (Консьюмер) - Тот, кто читает сообщения (например, сервис Уведомлений или Склад).

4. Broker (Брокер) - Сервер Kafka, который хранит эти данные.

🚀 Главная фишка: Fire and Forget

Когда OrderService создает заказ, ему плевать, работает ли сейчас сервис отправки SMS или сервис начисления бонусов.
Он просто кидает событие OrderCreated в Kafka и мгновенно возвращает ответ пользователю "Заказ принят".

Сервисы-подписчики (Consumers) разгребут эти сообщения в своем темпе. Если сервис SMS упал, он поднимется через час, прочитает топик с того места, где остановился, и дошлет все смски. Данные не пропадут.

💻 Spring Kafka: Как писать код?

В Spring Boot работа с Kafka максимально упрощена.

1. Настройка (application.yaml)

spring:
  kafka:
    bootstrap-servers: localhost:9092 # Адрес брокера
    consumer:
      group-id: my-group # Важно для масштабирования

2. Продюсер (Отправляем сообщение)
Нам нужен бин KafkaTemplate.

@Service
@RequiredArgsConstructor
public class OrderProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public void sendOrderEvent(String orderId) {
        // Отправляем в топик "orders"
        kafkaTemplate.send("orders", orderId); 
        System.out.println("Сообщение отправлено: " + orderId);
    }
}

3. Консьюмер (Слушаем эфир)
Просто вешаем аннотацию @KafkaListener.

@Service
public class NotificationConsumer {

    @KafkaListener(topics = "orders", groupId = "notification_group")
    public void listen(String orderId) {
        System.out.println("Получено событие для заказа: " + orderId);
        // Тут логика отправки email/sms
        sendEmail(orderId);
    }
}

⚡ Kafka vs RabbitMQ (Коротко)

Частый холивар.

🔴RabbitMQ - это классическая Очередь. Сообщение прочитали -> оно удалилось. Это "умный брокер, глупые потребители".
🔴Kafka - это Лог. Сообщения хранятся на диске днями (или вечно). Их можно перечитывать заново (Replay). Это идеально для аналитики и восстановления данных.

🔥 Итог

Kafka позволяет микросервисам быть слабосвязанными (decoupled).

🔴Сервис А не знает о существовании Сервиса Б.
🔴Система выдерживает пиковые нагрузки (Kafka просто буферизирует сообщения, пока консьюмеры не разгребут их).

#Java #Kafka #Microservices #SpringCloud #Architecture

📲 Мы в MAX

👉@BookJava