🔗 RPC vs HTTP：为什么微服务首选 RPC？

通过交互式动画，直观感受 RPC 在性能、传输效率、调用体验上相比 HTTP 的核心优势

💡 点击下方按钮切换模式，观察差异

⚔️ 一句话对比

先建立整体认知，再深入每个细节

R
RPC (远程过程调用)
像调用本地函数一样调用远程服务
  • 语义明确：调用方法名 + 参数 → 返回结果，就像本地函数调用
  • 二进制传输：Protobuf/MessagePack 编码，体积小、解析快
  • 长连接复用：TCP 连接保持，省去反复握手开销
  • IDL 强类型：接口定义即契约，编译时检查类型安全
  • 高性能：同等业务数据下，延迟可降低 50%~80%
H
HTTP/REST (超文本传输协议)
面向资源的通用请求-响应模式
  • 语义宽泛：URL + Method + Headers + Body，需要约定规范
  • 文本传输：JSON/XML 可读性好，但冗余多、解析慢
  • 无状态短连：每次请求都可能新建连接（即使有 Keep-Alive）
  • 弱类型：JSON 字段靠文档约束，运行时才能发现错误
  • 通用性强：跨语言、跨平台、浏览器原生支持

🎬 交互式通信动画

观察同一业务请求在两种协议下的完整生命周期差异

1x
🖥️ Client
调用方
🖧 Server
服务方
REQUEST
RESPONSE
0 ms
--
请求体大小
--
端到端延迟
--
协议头开销
--
往返次数(RTT)
消息详情

      

    

  








  
📊 数据大小对比

  
同样的业务数据，编码后体积差多少？


  

    

      

        
0 B

      

      
RPC (Protobuf)

      
-- Bytes

    

    

      

        
0 B

      

      
HTTP/1.1 + JSON

      
-- Bytes

    

  








  
🏗️ 协议栈层次对比

  
每一层都在增加额外开销——HTTP 的层次更臃肿


  

    

      
gRPC 协议栈

      
App Data (Protobuf)

      
↓

      
gRPC Frame (5 bytes head)

      
↓

      
HTTP/2 or TCP

      
↓

      
TCP / IP

    

    
    

      
HTTP/1.1 + JSON 协议栈

      
App Data (JSON)

      
↓

      

        HTTP Headers
        ~400-800B overhead!
      

      
↓

      

        HTTP/1.1 (文本协议)
        Method URL Version...
      

      
↓

      
TCP / IP

    

  








  
🏆 RPC 的六大核心优势

  
逐一拆解，每一条都是微服务场景下的关键考量


  

    

      
1

      
🚀 极致低延迟

      

        二进制 Protobuf 编码 + 长连接复用 + HTTP/2 多路复用。一次调用的序列化/反序列化耗时仅为 JSON 的 1/10 ~ 1/20。
      

      
❌ HTTP/1.1: 每次 JSON 解析需词法分析+语法树构建，CPU 密集

    


    

      
2

      
📦 高压缩率

      

        Protobuf 使用 Varint 编码 + 字段编号，不传输字段名。相同数据体积通常只有 JSON 的 10% ~ 30%。
      

      
❌ HTTP/JSON: 每条消息重复字段名 "user_name"、"age" 等，大量冗余

    


    

      
3

      
🔌 长连接 & 连接池

      

        RPC 框架内置连接池管理，TCP 连接建立后持续复用。避免每次请求的 TCP 三次握手 + TLS 握手（节省 ~2 RTT）。
      

      
❌ HTTP/1.1: Keep-Alive 超时后仍需重建连接，高并发下连接数爆炸

    


    

      
4

      
🛡️ 类型安全 IDL

      

        通过 .proto 文件定义接口契约，编译时生成强类型代码。字段类型错误、缺失必填字段等在编译期即可发现，而不是线上报错。
      

      
❌ HTTP/REST: 靠 Swagger/OpenAPI 文档约束，改了接口文档不同步 = 炸雷

    


    

      
5

      
🔄 流式传输

      

        基于 HTTP/2 的流特性，gRPC 原生支持 Unary / Server Streaming / Client Streaming / Bidirectional Streaming 四种模式。
      

      
❌ HTTP/1.1: 只能一问一答，要实现推送得靠 WebSocket 或轮询

    


    

      
6

      
🎯 调用语义清晰

      

        userService.GetUser(request) —— 方法即意图，参数即合约。IDE 自动补全、跳转定义、重构重命名全部可用。
      

      
❌ HTTP/REST: POST /api/v1/users/get — URL 设计争议永无止境

    

  








  

    
🎯 如何选？一句话总结

    

      内部微服务之间 → 用 RPC（gRPC）：
      性能敏感、接口稳定、需要强类型保障、高频调用


      对外 API / 前端对接 → 用 HTTP/REST：
      需要浏览器直接访问、第三方接入、调试友好、人类可读
    

    

    

      实际生产中常见做法：内部 gRPC 打通微服务，API Gateway 做 gRPC→HTTP 转换 对外暴露 RESTful API，两者兼得 🎉