带有阻塞 IO 的 Spring Boot 真的很适合微服务吗？答案

【问题标题】：Does Spring Boot with its Blocking IO really fit well with Microservices?带有阻塞 IO 的 Spring Boot 真的很适合微服务吗？
【发布时间】：2018-02-12 12:11:46
【问题描述】：

有很多教程和文章（包括官网）都在宣传 Spring Boot 作为构建微服务的好工具。

假设我们有一些 rest api 端点（用户配置文件），它聚合来自多个服务（用户服务、统计服务、朋友服务）的数据。

为了实现这一点，用户配置文件端点对这些服务进行了 3 次 http 调用。

但是在 Spring 中，请求是阻塞的，正如我所见，服务器将很快耗尽可用资源（线程）来在此类系统中为请求提供服务。

所以对我来说，构建这样的系统是一种非常低效的方式（与非阻塞框架相比，比如 play!framework 或 node.js）

我错过了什么吗？

P.S.：我不是指 Spring 5 及其新的 webflux 框架。

【问题讨论】：

微服务不是构建非阻塞系统或服务。它是关于构建小型、独立的服务，这些服务可以扩展，并且可以单独部署。解决阻塞 IO 问题超出了微服务架构的范围。
是的，但是微服务之间经常通过http进行通信（至少我看到很多教程，包括spring boot教程）。

标签： spring-boot microservices blocking

【解决方案1】：

没有人阻止您使用 Spring Boot 构建异步微服务架构 :)。

类似的东西：

服务可以将事件放入队列（例如 RabbitMQ），而不是一个服务同步调用另一个服务。这些事件被传递给订阅这些事件的服务。

使用 RabbitMQ 及其“交换”概念，事件生成服务甚至不需要其事件的消费者。

可以在此处找到详细说明 Spring Boot 代码的博文：https://reflectoring.io/event-messaging-with-spring-boot-and-rabbitmq/

【讨论】：

【解决方案2】：

这不是 Spring 的限制，而是更多地与应用程序架构有关。

例如，您遇到的场景通常使用聚合设计模式来解决

虽然这种解决方案非常流行，但它具有同步的限制，因此会阻塞。此类场景中的异步行为应以特定于应用程序的方式实现。

话虽如此，如果您必须调用其他服务才能响应来自客户端（外部）的请求，这通常是架构问题。不管你是使用 HTTP 还是异步消息传递（使用请求-回复模式），外部客户端的整体响应时间都会很糟糕

另外，我见过不少应用程序对外部客户端使用同步 REST 调用，但是当内部微服务之间需要通信时，它应该始终是异步的。你可以在这里阅读一篇关于这个主题的有趣论文MicroServices Messaging Patterns

【讨论】：