HTTP与RPC？

HTTP 与 RPC 是什么？

HTTP是位于YTCP/IP协议栈的应用层协议（超文本传输协议 - HyperText Transfer Protocol）。

RPC是一种抽象机制/模式。

各自适用场景

• 对外服务、跨平台、多端访问、需要标准化 → 用 HTTP

• 服务间内部调用、要求高性能、高吞吐、低延迟 → 用 RPC

什么时候用HTTP（RESTful/JSON）

1. 对外提供 API（公网上跑）

例如：

App 调用你的后端

Web 前端调用你的服务

小程序 / 桌面端

第三方合作方

理由：

HTTP 是所有平台天然支持的

JSON 格式通用易调试

浏览器原生支持

更容易做文档与调试

2. 需要跨语言、多端、公开标准

iOS / Android / Web / Python / Go / C++

第三方厂商接入

RPC 不方便（要 SDK），但 HTTP 人人都能用。

3. 网络环境复杂，链路不稳定

HTTP 自带：

重试

超时

状态码语义

代理 / 网关支持

移动网络场景非常依赖。

4. 你需要网关、负载均衡、CDN

HTTP 在基础设施上是最成熟的。

5. 强调资源模型（CRUD 风格）

比如：

/users

/books/{id}

RESTful 感觉更自然。

什么时候用 RPC（gRPC / Thrift / TCP 自定义协议）

1. 内部微服务之间的通信（最典型）

例如：

用户服务 → 订单服务

支付服务 → 风控服务

推荐服务 → 特征服务

内部服务调用频次极高，延迟要求严格，需要更高性能。

2. 要求高性能、低延迟

相比 HTTP：

协议	特点
HTTP/JSON	文本 + 大量 header，序列化慢
RPC/Protobuf	二进制 + 高效序列化 + 长连接

性能一般差一个数量级。

3. 需要强类型接口（IDL）

RPC 一般使用 protobuf/thrift IDL：

自动生成服务端和客户端代码

参数/返回值强类型

减少手写错误

非常适合集群化、接口多的系统。

4. 内部服务之间 QPS 非常高

例如：

一个请求要链式调用 10 次内部接口

推荐/广告系统每秒几十万请求

HTTP 做不动，RPC 才扛得住。

5. 要长连接、双向流

例如 gRPC 支持：

双向流

服务端推送

客户端流

HTTP/JSON 基本不行。

总结

维度	HTTP	RPC
性能	中等	极高
延迟	高	低
跨平台兼容性	非常好	需要 SDK
调试难度	简单（curl/浏览器）	较复杂
数据格式	JSON 文本	Protobuf 等二进制
连接方式	短连接为主	长连接（HTTP/2/TCP）
类型安全	弱	强
适用对象	外部客户端	内部后端服务
基础设施支持	网关/CDN/缓存完备	需要自定义
文档/可读性	极好	较弱/自动生成

一句话： HTTP 更通用；RPC 更高性能。