既然有 HTTP 协议，为什么还要有 RPC？

HTTP 和 RPC 都能解决网络通信问题但它们的设计初衷和适用场景截然不同。简单来说HTTP 是为了通用性和跨平台设计的像万能的集装箱而 RPC 是为了极致的性能和开发效率设计的像工厂内部的高速流水线。1. 性能与效率的极致追求“首先在微服务内部服务间的调用链路非常长一个请求可能涉及几十次内部调用这时候性能损耗会被成倍放大。序列化协议HTTP 通常使用 JSON 或 XML这是基于文本的协议冗余字段多解析慢。而 RPC如 gRPC、Dubbo通常使用 Protobuf 或 Hessian 等二进制协议。二进制协议不仅体积更小节省带宽而且序列化和反序列化的速度比 JSON 快 5-10 倍CPU 占用更低。连接管理传统的 HTTP/1.1 往往是短连接频繁建立 TCP 三次握手开销很大。而 RPC 框架通常基于长连接和连接池技术或者基于 HTTP/2 的多路复用极大地减少了连接建立和断开的开销提升了高并发下的吞吐量。”2. 开发体验与类型安全“其次RPC 能显著提升开发效率和代码质量。强类型与代码生成RPC 通常基于接口定义语言IDL如.proto文件。通过 IDL我们可以自动生成各个语言的客户端和服务端代码。这意味着开发者调用远程服务就像调用本地函数一样例如userService.getUser(1)不仅代码可读性强还能在编译期就发现类型错误。对比 HTTP使用 HTTP 时我们往往需要手动拼接 URL、处理 Header、解析 JSON这属于‘弱类型’交互参数传错或者字段类型不对往往要到运行时才能发现容易出错且维护成本高。”3. 服务治理能力“最后也是企业级开发最看重的一点RPC 框架通常内置了完善的服务治理功能。开箱即用的治理像 Dubbo 或 gRPC 这样的成熟框架内置了负载均衡轮询、随机等、熔断降级、故障重试、服务注册与发现等功能。HTTP 的短板虽然 HTTP 也能做这些但通常需要依赖额外的组件如 Nginx 做负载均衡或者在代码中手动实现集成成本高且难以标准化。RPC 让服务间的通信变得‘可观测、可管理’。”4.RPC 的主要缺点1. 紧耦合与灵活性缺失接口强依赖RPC 通常依赖接口定义语言IDL如.proto文件生成代码。这意味着客户端和服务端必须同步升级。如果服务端修改了接口比如改了字段名或类型客户端必须重新生成代码并重新部署否则就会报错。版本管理噩梦在微服务架构中如果服务 A 调用服务 B服务 B 升级了接口服务 A 如果不及时更新系统就会崩溃。这导致服务之间很难做到真正的“独立演进”。相比之下RESTful API 对参数更宽容兼容性更好。语言绑定虽然很多 RPC 框架号称跨语言但在实际工程中不同语言对 IDL 的支持程度不同。有时候为了使用某个 RPC 框架团队可能被迫统一技术栈例如都用 Java 或 Go限制了技术选型的灵活性。2. 调试与运维困难RPC 屏蔽了底层的网络细节这在开发时是优点但在排查问题时就是缺点。难以抓包调试HTTP 请求可以用浏览器、Postman 或 Curl 轻松模拟和查看明文数据。而 RPC 传输的是二进制数据人眼无法直接阅读。如果线上出现调用失败你很难像分析 HTTP 日志那样直观地看到“发了什么参数回了什么结果”必须依赖专门的工具或复杂的日志配置。依赖专用工具你不能用浏览器直接访问 RPC 接口测试人员必须编写专门的测试代码或使用特定的客户端工具这增加了测试和联调的门槛。异常模糊在本地调用函数报错通常很明确。但在 RPC 中网络抖动、超时、序列化失败都可能抛出异常。特别是超时客户端往往无法判断对方是“没收到请求”还是“处理完了但响应丢了”这导致重试机制的设计非常复杂容易导致重复消费。3. 架构复杂性与侵入性引入 RPC 不仅仅是引入一个 jar 包那么简单它会改变系统的架构形态。防火墙与网络限制HTTP 通常走 80/443 端口能轻松穿透防火墙。而 RPC 框架如 Dubbo通常使用自定义端口和协议在企业内网严格的安全策略下可能需要额外配置防火墙规则或者被安全部门拦截。上下文传递困难在单体应用中线程变量ThreadLocal可以方便地传递用户信息。但在 RPC 调用链中这些上下文信息如 UserID、TraceId需要手动序列化并透传到下一个服务处理起来比较繁琐。分布式事务问题RPC 让服务拆分得更细但也让数据一致性变得极难处理。一个业务操作跨越多个 RPC 调用一旦中间某步失败如何进行回滚补偿是一个巨大的挑战如需要引入 Saga、TCC 等复杂模式。4. 性能陷阱虽然 RPC 理论上比 HTTP 快但在某些场景下反而会成为瓶颈。序列化开销虽然二进制协议比 JSON 快但序列化把对象转成字节流和反序列化本身是非常消耗 CPU 的操作。如果对象非常大或者并发极高CPU 可能会大量消耗在编解码上。“传引用”的假象RPC 看起来像本地调用但本质是网络传输。开发者容易忽略网络延迟写出“循环调用 RPC”的代码例如在循环里调用 100 次获取用户信息这会导致严重的性能问题N1 问题。缺点总结“RPC 最大的代价在于耦合度和可观测性。第一它通过 IDL 强绑定了客户端和服务端导致服务很难独立演进版本管理比较痛苦第二二进制协议虽然快但牺牲了可读性导致线上排查问题和调试比 HTTP 困难得多第三它容易给开发者造成‘本地调用’的错觉从而忽略网络延迟和分布式事务的复杂性。5.什么时候 HTTP 就足够了RPC 并非万能在以下场景中HTTP 通常是更简单、更合适的选择对外提供 API需要被浏览器、移动端或第三方系统调用时HTTP 的通用性和易用性是首选。服务调用频率低对于日活或 QPS 不高的服务HTTP 的性能完全够用。团队规模小或技术栈异构追求快速开发和调试便利使用 Spring Boot REST 是最简单的方案。总结所以这不是一个二选一的问题而是分层使用的问题。在对外网关层为了兼容浏览器和第三方系统我们首选HTTP/RESTful因为它通用、可读、易调试。在内部微服务层为了追求高性能、低延迟和强类型的开发体验RPC是更优的选择。这就是为什么在有了 HTTP 之后我们依然需要 RPC 的原因。”