微服务内部调用全走 HTTP，一个请求一个连接来回建，量大之后开销明显。RSocket 就是为这种场景设计的：一个二进制协议，专门面向响应式应用，连接建立一次，多路复用跑到底。

四种交互模式，这是核心卖点

  • Request/Response：一问一答，最像普通 HTTP 调用
  • Request/Stream：客户端发一个请求，服务端持续回多条数据，比如行情推送
  • Fire-and-Forget：只发不等回应，适合打点上报这类不关心结果的场景
  • Channel：双向流，两边都能持续发消息，聊天和实时同步用得上

普通 HTTP 想做流式得换 SSE 或 WebSocket，它把四种模式统一在一个协议里，语义清楚，框架层直接支持。

背压是内建的

消费方处理不过来时，可以通过 REQUEST_N 帧向上游要固定条数，处理完再要，这就是背压控制，能防止上游把下游打爆，也是它标榜「响应式」的底气。HTTP/1.1 一个连接同时只能处理一个请求，高并发靠连接池硬堆；RSocket 一条连接上同时跑大量并发流，这是底层差异。

跑在什么之上

传输层不绑定 TCP，WebSocket、Aeron 之上都能跑，既适合内网服务间通信，也能通过 WebSocket 穿到浏览器。实现上 Java 是主力，rsocket-java 最成熟，Spring Boot 有对应的 starter，依赖加上 spring-boot-starter-rsocket 就能在消息模型里用；JavaScript、Go 等语言也有社区实现。

什么时候选它

对外 API 老老实实用 HTTP，生态、监控、网关都成熟。RSocket 的甜点区在内部系统：服务间高频调用、需要流式推送、对连接开销敏感的场景。它也有代价：工具链和排障资料比 HTTP 少，服务发现、负载均衡这些要靠框架自己搭，团队没接触过响应式编程的话，先评估学习曲线再上。

实际判断：内部微服务改造、实时推送这类需求，rsocket 值得试；纯 CRUD 项目，HTTP 加现成框架反而省心。