[RPC]什么是rpc框架(介绍)

import_random
119 阅读5分钟

RPC,及远程过程调用(Remote Procedure Call), 它的本质，就是“像调用本地方法一样调用远程服务”，让你写代码时完全感觉不到网络的存在。

为了帮你透彻理解，我从这四个层面拆解：

1. 什么是RPC？—— 分布式系统的“隐身衣”

一句话定义：RPC是一个计算机通信协议，允许一台计算机上的程序像调用本地函数一样，调用另一台计算机上的子程序，开发者无需手动编写网络通信代码。

通俗类比（电话点外卖）：

  • 你（客户端）拿起电话告诉餐厅你要“一份番茄炒蛋”（参数）
  • 电话网络（RPC框架）帮你传输
  • 餐厅（服务器）接到订单后，后厨开始炒菜（方法执行）
  • 外卖员（网络）把菜送回来
  • 你收到外卖（返回值）后直接吃饭 整个过程你不需要关心电话信号怎么传、外卖员走哪条路，你只关心“点餐”这个动作本身。

2. RPC的作用 —— 为什么必须用它？

核心价值不是“能通信”，而是“把通信藏起来”。

维度没有RPC（手写Socket）有RPC框架改善幅度
代码复杂度写NIO、处理粘包拆包、手动序列化只写interface，加个注解90%样板代码消失
心智负担时刻想着这是远程调用、可能失败像写本地Service一样专注业务逻辑
跨语言成本两套团队对报文，联调靠人肉Protobuf/Thrift自动生成桩代码效率提升数倍
系统演进单体应用，改一行全量编译5分钟微服务独立部署CI/CD分钟级

更宏观的价值：RPC是微服务架构的“经络”。没有它，大型系统只能堆砌成“大泥球”；有了它，物流、支付、库存等不同团队的服务才能像拼乐高一样灵活组合。

3. 工作原理 —— 10步拆解+核心四要素

一个完整的RPC调用，无论框架多花哨，底层都是这10步标准化流程（记不住没关系，看图）：

flowchart LR
    subgraph 客户端
    A[1. 业务代码<br>调用本地方法] --> B[2. 客户端存根<br>（动态代理）]
    B -- 3. 序列化 --> C[二进制流]
    C -- 4. 网络发送 --> D[网卡]
    end

    subgraph 网络
    D -- TCP/HTTP2 --> E[网卡]
    end

    subgraph 服务端
    E --> F[5. 网络接收]
    F -- 6. 反序列化 --> G[7. 服务端存根]
    G --> H[8. 调用真实服务]
    H -- 9. 结果序列化 --> F
    end
    
    F -- 10. 返回响应 --> A

四个必须吃透的底层机制：

① 动态代理（灵魂）
客户端调的那个“看上去是本地”的接口，其实是框架生成的代理对象。它拦截方法调用，把方法名、参数值打包，这就是“远程调用变成本地调用”的魔术。

② 序列化（翻译官）
内存里的Java对象/Go结构体，网络不认识，必须变成0和1。选型直接影响性能：JSON可读但慢，Protobuf二进制难读但极快（比JSON快3-5倍）。

③ 协议（交通规则）
二进制流到了对面，怎么知道从哪里切分？请求和响应如何对应？HTTP/2（gRPC使用）支持多路复用，一个连接并发发多个请求，比HTTP/1.1傻等效率高得多。

④ 注册中心（通讯录）
服务成百上千个，IP老变，不能写死。Nacos/ZooKeeper负责：服务启动时上报地址、消费端启动时拉取并缓存。注意：注册中心宕机不影响已建立连接的调用，但会导致新节点无法发现、重启后全挂。

4. 优秀的RPC框架 —— 按场景选型（2026年视角）

没有“最好”，只有“最适合”。当前主流生态已高度分化，我按技术栈/场景给你画一张选型决策地图：

框架语言生态通信协议/序列化核心优势典型场景避坑指南
gRPC跨语言HTTP/2 + Protobuf标准化之王。多语言互通、流式通信、xDS服务网格原生支持云原生、微服务（Istio）、多语言团队、移动端-服务端Protobuf学习曲线；反射调试较麻烦
DubboJavaTCP + Hessian2/自定义性能极致。长连接复用、集群容错极强、国内生态完善高并发业务中台、大规模Java集群、阿里系技术栈跨语言支持弱（需转义）
Spring Cloud OpenFeignJavaHTTP + JSONSpring生态亲儿子。注解复用Spring MVC，开发效率极高Spring Boot应用、对性能不极致敏感的业务短连接+HTTP，吞吐量低于Dubbo；依赖Ribbon已进入维护
KitexGoThrift/Protobuf字节跳动出品，云原生友好。高性能、支持服务网格大流量Go服务、需要Thrift存量兼容社区相比gRPC小
KratosGoHTTP/gRPCB站开源，一站式微服务。内置服务发现、配置、链路需要快速搭建完整Go微服务体系的团队框架约束性强
Thrift跨语言二进制 + Thrift强类型IDL，历史验证。比Protobuf诞生更早，某些大厂遗留已有Thrift存量体系、Facebook系生态活力弱于gRPC
JSON-RPC轻量级HTTP + JSON极简，调试友好。无需IDL，浏览器都能测内部工具、跨语言简单调用、Postman直接测无强类型校验，不适合复杂业务

核心选型建议：

  • 2026年新项目，无历史包袱：首选gRPC。协议红利最大，服务网格事实标准，多语言通吃。
  • Java技术栈，已有Dubbo经验：Dubbo。吞吐量确实能打，3.x版本已适配云原生。
  • Spring Boot全家桶，懒得折腾：OpenFeign。开发太爽了，性能瓶颈一般到不了RPC这层。
  • Go技术栈，从头搭架子：Kratos。B站开箱即用，少掉坑；Kitex适合流量极大的场景。

总结

RPC不是“一个技术”，而是一套将网络通信隐藏到极致的设计哲学。学RPC不能止步于会用框架，理解动态代理、序列化、协议、连接复用这四个关键词，分布式系统对你来说就没有黑盒了。

avatar
文章
阅读
粉丝