4. 接口设计优化：RESTful vs gRPC，序列化协议选择
聊到接口性能优化，有一个躲不开的话题：到底用 RESTful 还是 gRPC？序列化用 JSON、Protobuf 还是 Avro？
我早年做数据平台的时候，全公司清一色 RESTful + JSON。接口写得快，调起来也方便。但等数据量上了千万级，问题就来了——带宽吃紧，解析耗时，GC 频繁。后来切换到 gRPC + Protobuf，吞吐直接翻了一倍多。
这次咱们就掰开揉碎，把技术选型背后的权衡讲清楚。
4.1 RESTful vs gRPC：两套设计哲学
RESTful 基于 HTTP/1.1，资源导向，通常用 JSON 做数据交换。优点是生态成熟、调试直观、防火墙友好。缺点也很明显：文本协议冗余大，无强制 Schema，长连接复用能力弱。
gRPC 基于 HTTP/2，服务导向，默认用 Protobuf 序列化。它支持双向流、头部压缩、多路复用。我自己的项目中，gRPC 在微服务间调用场景下，延迟比 REST 低 30%-50%。
| 对比维度 | RESTful (JSON) | gRPC (Protobuf) |
|---|---|---|
| 传输协议 | HTTP/1.1（可升级至 HTTP/2） | HTTP/2（强制） |
| 消息格式 | JSON（文本，人类可读） | Protobuf（二进制，不可读） |
| API 风格 | 资源 CRUD + 状态码 | 服务方法 + 状态码 |
| 流式支持 | Server-Sent Events 或 WebSocket | 原生双向流 |
| 性能（吞吐） | 较低（文本冗余 + 无压缩） | 高（二进制 + 头部压缩） |
| 生态工具 | 浏览器、curl、Postman 可直接调试 | 需 grpcurl 或专用 UI |
4.2 序列化协议：Protobuf vs Avro
序列化协议决定了数据怎么编解码。选对了，带宽省一半；选错了，CPU 烧不停。
Protobuf 是 gRPC 的默认序列化协议。它有强类型 IDL，支持向前/向后兼容。我习惯把它用在跨语言、高性能、强 schema 校验的场景。
Avro 是 Hadoop 生态的“亲儿子”。它的 schema 在文件头或注册中心里存着，数据本身自带 schema。动态类型、行式结构，跟 Kafka、Spark 配合得很好。我记得有一次做实时数仓接入，用 Avro 直接省掉了反序列化后的数据转换步骤。
| 对比维度 | Protobuf | Avro |
|---|---|---|
| IDL 风格 | .proto 文件定义 | JSON Schema 或 .avsc 文件 |
| Schema 与数据关系 | 数据+Schema 分离，需在编译期或注册中心绑定 | Schema 通常内嵌于数据头部 |
| 模式演进 | 强规则：字段编号不变，不允许删除必填字段 | 默认向前兼容：读取器 Schema 与写入器 Schema 自助匹配 |
| 序列化方式 | 编号映射 + 长度前缀 | 类型+长度+数据（行式） |
| 适用场景 | RPC 调用、微服务、高性能网关 | 数据管道、Kafka 消息、Hadoop 生态 |
那到底选哪个？我个人习惯看场景：如果服务间交互频繁、链路多，选 Protobuf 更可控；如果是日志流、批处理场景，Avro 的自动 schema 兼容机制会让你省很多心。
4.3 核心逻辑框架图
4.4 实践选型建议
说了这么多理论，来点实际的。我按场景给几条建议：
- 对外 RESTful API：保留 JSON。不要为了“性能”强行换成二进制协议，前端真的调不了。可以在网关层做 JSON 压缩（gzip/brotli），性价比很高。
- 内部微服务 RPC：直接上 gRPC + Protobuf。如果团队对 HTTP/2 不熟悉，先从单服务接入试点，走通后再全量切换。
- 流式数据管道（Kafka、Flink）：首选 Avro。结合 Schema Registry 做兼容管理，可以避免上下游 Schema 不一致导致的数据丢失。
- 跨语言调用多：Protobuf 的 IDL 生成能力更强，Go、Java、Python、C++ 都支持得很好。Avro 在 Python/Java 之外的语言生态稍弱。
一句话总结：接口优化不是“非黑即白”。RESTful 适合开放生态，gRPC 适合可控拓扑。序列化协议选型要看数据生命周期——传输频繁用 Protobuf，存储流转用 Avro。
4.5 避坑指南
- 我曾经在 gRPC 的双向流里忘了做背压控制，结果服务端内存直接被打满。后来加了流控和限流中间件才稳住。
- Protobuf 的字段编号不要乱动。编号是序列化协议的“身份证”，一旦发布就尽量终身不变。我见过不少项目因为图省事复用编号，导致线上数据错乱。
- Avro 的 Schema 兼容检查不是万能的。它只保证“能反序列化”，不保证语义正确。比如字段名改了但类型没变，Avro 不会报错，但业务逻辑就乱了。
- 别为了“性能”牺牲可观测性。gRPC 默认的二进制日志几乎不可读，一定要搭配好链路追踪（如 OpenTelemetry）和详细度量指标，不然线上出了问题，你连问题在哪都找不到。