HTTP 与 RPC 之间的区别？
- 标签：微服务、Spring Cloud、远程调用、后端
🏛 业务架构师
两者不是对立而是各守一段：
- HTTP：文本协议、跨平台生态无敌（浏览器、CDN、防火墙、调试工具全兼容）——对外开放的标准接口语言；
- RPC（Dubbo/gRPC）：二进制序列化（体积小、编解码快）+ 长连接多路复用 + 服务治理内建（注册发现、负载均衡、超时重试、熔断按方法粒度）——内部高频调用的效率与治理工具。
业务场景映射：
- 对外开放 API、第三方对接 → HTTP/REST（生态互认，文档友好）；
- 内部微服务间每秒数万次调用 → RPC（序列化与连接成本在调用密度下被放大——单次快 1ms × 每秒 5 万次 = 每天省下实实在在的机器）；
- 跨语言 → gRPC（proto 契约）或 JSON over HTTP；
- 高吞吐低延迟链路（交易、风控）→ RPC + 二进制协议。
架构现实：成熟系统是双协议并存——对外 HTTP 网关，对内 RPC 通信；Dubbo 3 与 Spring Cloud 也已互通，边界越来越模糊。选择的影响权重已经从"性能"转向"治理体系与团队栈"：公司已有 Dubbo 治理资产（注册中心、监控、运维工具）就继续，全 Spring Cloud 栈就 Feign/gRPC——切换协议的成本通常大于它带来的性能差。
一句话：对外讲通用（HTTP），对内讲效率与治理（RPC）——按流量方向和调用密度分层选型，而不是二选一站队。
🏗 系统架构师
两者都是远程通信的方式，差异在协议与定位：
- 序列化与协议：HTTP 是文本协议（头部文本 + 语义标准化，2.0 后二进制化），通用但头重、解析开销大；RPC（Dubbo/gRPC/Thrift）用精简二进制协议 + 高效序列化（Protobuf/Hessian），报文小、编解码快，专为服务间高频调用设计；
- 性能：RPC 长连接复用（省握手）+ 二进制，同链路吞吐通常高于 REST/HTTP1.1；但 HTTP/2 + 连接池后差距缩小，gRPC 本身就跑在 HTTP/2 上——边界在模糊化；
- 服务治理：RPC 框架内置注册中心、负载均衡、超时重试、熔断、链路追踪（Dubbo 全家桶）；HTTP 原生没有，靠 Spring Cloud/Gateway/Service Mesh 补齐；
- 通用性与生态：HTTP 是万物标准——浏览器、移动端、第三方、防火墙全兼容，调试简单（curl）；RPC 接口契约（IDL）强类型，跨语言要生成 stub，穿透性差；
- 使用位置：我的标准架构——对外（南北向）暴露 HTTP/RESTful（通用、网关友好），对内（东西向）服务间调用用 RPC（性能 + 治理），网关层做协议转换。
一句话：HTTP 是"通用语言"，RPC 是"内部方言"；选型看调用方是谁、链路性能要求多高、要不要治理能力，成熟架构通常两者共存。
💻 全栈开发专家
定位不同：HTTP 是应用层传输协议，RPC 是"远程调用编程模型 + 一整套服务治理"。
| 维度 | HTTP（REST） | RPC（Dubbo/gRPC） |
|---|---|---|
| 语义 | 资源表达（GET/POST...） | 像调本地方法一样调远程 |
| 报文 | 文本 Header + JSON，体积大 | 二进制（protobuf/thrift），小且解析快 |
| 序列化 | JSON 可读 | 二进制高效 |
| 连接 | 短连接/1.1 keep-alive | TCP 长连接复用 |
| 服务治理 | 要自己搭（网关+注册） | 内置注册发现/负载均衡/超时重试/熔断 |
| 跨语言/防火墙 | 天然友好，通吃 | gRPC/Thrift 跨语言，但需双方都懂协议 |
性能差多少：内网同机房，gRPC/Dubbo 二进制 + 长连接比 HTTP+JSON 快 2~5 倍（序列化和连接复用是大头），但跨机房/公网后网络 RTT 成为主导，差距缩小。
我的实际选型：
- 对外开放 API：HTTP/JSON，通用、易调试、防火墙/CORS/CDN 全兼容；
- 内部微服务高频调用：Dubbo/gRPC（triple），性能 + 服务治理全家桶；
- 两者结合：网关收 HTTP 转内部 RPC。
加分点：边界正在模糊——gRPC 就跑在 HTTP/2 上（说"RPC 和 HTTP 对立"已经过时）；RESTful + JSON 的可调试性在生产排障时是真实的生产力（curl 一发就知道结果，二进制协议要专门工具解码）。