Всегда ли микросервисы не зависимы друг от друга?

Всегда ли микросервисы независимы друг от друга?

Нет, микросервисы не всегда полностью независимы. Это одна из самых распространённых ошибок понимания микросервисной архитектуры. На практике существует множество сценариев, где микросервисы взаимодействуют и имеют зависимости.

Теория vs Реальность

Идеальный сценарий независимости:

В теории каждый микросервис должен быть полностью независим: иметь свою БД, свою бизнес логику, развиваться и деплоиться отдельно. Но на практике это редко когда достижимо.

Типичные зависимости между микросервисами

1. Синхронная коммуникация через API

Один сервис часто вызывает другой напрямую через HTTP/REST или gRPC:

User Service → Order Service → Payment Service

Когда пользователь создаёт заказ, Order Service вызывает Payment Service для обработки платежа. Если Payment Service недоступен, заказ не будет создан. Это прямая зависимость.

2. Данные, распределённые между сервисами

Хотя каждый микросервис должен иметь свою БД, данные часто связаны:

// User Service
class User {
    Long userId;
    String email;
}

// Order Service
class Order {
    Long orderId;
    Long userId;  // Ссылка на User Service
    BigDecimal amount;
}

Order Service зависит от существования пользователя в User Service. Если удалить пользователя, заказы становятся сиротами.

3. Асинхронная коммуникация через события

Хотя асинхронность уменьшает сильную связанность, сервисы всё равно зависят друг от друга через события:

Order Service → Publish "OrderCreated" → Event Bus
                                         ↓
        ← Email Service слушает события
        ← Inventory Service слушает события
        ← Analytics Service слушает события

Email Service зависит от того, что Order Service опубликует корректные события.

4. Общие библиотеки и зависимости

<!-- Все сервисы используют одну версиюDTO -->
<dependency>
    <groupId>com.company</groupId>
    <artifactId>common-models</artifactId>
    <version>1.0.0</version>
</dependency>

Если поменять формат DTO в common-models, нужно обновить все сервисы.

5. Операционные зависимости

Все сервисы часто полагаются на:

• Одну БД (вопреки лучшим практикам, но часто бывает)
• Один message broker (RabbitMQ, Kafka)
• Один service registry (Consul, Eureka)
• Одну систему логирования и мониторинга

Реальный пример: E-Commerce система

// User Service
@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) { ... }
}

// Order Service
@Service
public class OrderService {
    @Autowired
    private RestTemplate restTemplate;
    
    public Order createOrder(Long userId, OrderRequest req) {
        // Зависимость от User Service
        User user = restTemplate.getForObject(
            "http://user-service/users/" + userId, 
            User.class
        );
        
        if (user == null) {
            throw new UserNotFoundException();
        }
        
        // Опубликовать событие
        eventPublisher.publishEvent(new OrderCreated(orderId, userId));
        return order;
    }
}

// Email Service
@Service
public class EmailService {
    @EventListener
    public void onOrderCreated(OrderCreated event) {
        // Зависит от того, что Order Service опубликует событие
        emailSender.send(event.getUserId(), "Order confirmed");
    }
}

В этом примере:

• Order Service синхронно зависит от User Service
• Email Service асинхронно зависит от Order Service
• Если User Service упал, новые заказы не будут создаваться
• Если Message Broker упал, уведомления не будут отправлены

Как минимизировать зависимости

1. Асинхронная коммуникация

Вместо синхронных вызовов используйте события и очереди:

// Вместо этого:
User user = userService.getUser(userId);

// Сделайте так:
paymentService.processPayment(orderId);
// Payment Service сам запросит данные при необходимости

2. API versioning

Если изменяете API, поддерживайте старую версию:

@GetMapping("/api/v1/users/{id}")
public UserV1 getUserV1(@PathVariable Long id) { ... }

@GetMapping("/api/v2/users/{id}")
public UserV2 getUserV2(@PathVariable Long id) { ... }

3. Circuit Breaker паттерн

Обработайте случаи, когда зависимый сервис недоступен:

@Service
public class OrderService {
    @CircuitBreaker(name = "userService")
    public User getUser(Long userId) {
        return restTemplate.getForObject(..., User.class);
    }
}

4. Кэширование

Кэшируйте данные от других сервисов, чтобы снизить количество вызовов:

@Cacheable("users")
public User getUser(Long userId) { ... }

Вывод

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

• Автономией сервисов — они могут развиваться и деплоиться отдельно
• Управляемыми зависимостями — явная коммуникация через API и события
• Отказоустойчивостью — сервисы должны работать, даже если их зависимости временно недоступны

Хороший микросервис дизайн — это не отсутствие зависимостей, а управление ними таким образом, чтобы система оставалась масштабируемой, тестируемой и отказоустойчивой.