Ответ
Ответ зависит от контекста и типа запроса.
| Критерий | Монолит | Микросервисы |
|---|---|---|
| Простой запрос | Обычно быстрее. Все вызовы происходят в рамках одного процесса (JVM), нет сетевых издержек. | Медленнее из-за накладных расходов на сетевые вызовы (HTTP/gRPC), сериализацию/десериализацию, возможную аутентификацию между сервисами. |
| Сложный/составной запрос | Может быть медленнее, если операции нельзя распараллелить. | Может быть быстрее, если сервисы могут обрабатывать части запроса параллельно и независимо масштабироваться. |
| Масштабирование | Масштабируется целиком, даже если нагрузка только на одну функцию. | Точечное масштабирование только «узких» сервисов. |
Пример (Оформление заказа):
// Монолит: быстрые локальные вызовы методов
public Order processOrder(Order order) {
// Все в одном процессе
validationService.validate(order); // Локальный вызов
pricingService.calculate(order); // Локальный вызов
inventoryService.reserveItems(order); // Локальный вызов
return orderRepository.save(order); // Локальный вызов
}// Микросервисы: потенциально параллельное выполнение, но сетевые задержки
// OrderService (HTTP-клиент)
public Order processOrder(Order order) {
// Каждый вызов — сетевой запрос к другому сервису
CompletableFuture<Void> validation = validationClient.validateAsync(order);
CompletableFuture<Price> pricing = pricingClient.calculateAsync(order);
CompletableFuture<Void> inventory = inventoryClient.reserveAsync(order);
CompletableFuture.allOf(validation, pricing, inventory).join(); // Ожидание параллельных задач
return orderService.save(order);
}Вывод: Для систем с критически низкой latency и простой логикой монолит может быть оптимальнее. Для сложных, высоконагруженных систем, где можно выиграть за счет параллелизма и независимого масштабирования, микросервисы могут обеспечить лучшую общую производительность.