你怎么理解 RPC 框架
什么是 RPC？
RPC 是指远程过程调用，也就是说两台服务器 A，B 一个应用部署在 A 服务器上，想要调用 B 服务器上应用提供的函数或方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
RPC 是如何通讯的？
- 要解决通讯的问题，主要是通过在客户端和服务器之间建立 TCP 连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
- 要解决寻址的问题，也就是说，A 服务器上的应用怎么告诉底层的 RPC 框架，如何连接到 B 服务器（如主机或 IP 地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于 Web 服务协议栈的 RPC，就要提供一个 endpoint URI，或者是从 UDDI 服务上查找。如果是 RMI 调用的话，还需要一个 RMI Registry 来注册服务的地址。
- 当 A 服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如 TCP 传递到 B 服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给 B 服务器。
- B 服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。
- 返回值还要发送回服务器 A 上的应用，也要经过序列化的方式发送，服务器 A 接到后，再反序列化，恢复为内存中的表达方式，交给 A 服务器上的应用。
为什么要用 RPC？
就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用。
通讯五步与动机都已讲清，但”理解 RPC 框架”还要再上两层：框架在五步之上额外解决了什么（治理面），以及RPC 与 HTTP API 的架构位差。本文补全这两层，形成完整理解。
五步之上的框架职责：治理面
裸 Socket 能跑通五步，但生产 RPC 框架 80% 的代码在治理面：
- 服务发现：注册中心（ZK/Nacos）维护”接口→实例列表”，客户端订阅变更——解决”寻址”的动态版（实例上下线、扩缩容）
- 负载均衡：客户端侧策略（轮询/加权/一致性哈希/P2C），配合健康检查剔除坏实例
- 容错：失败重试（幂等前提）、failover 换实例、failfast 快速失败、熔断降级（连续失败开路）
- 超时与预算：调用超时、重试预算、deadline 传播（防止重试风暴放大故障）
- 可观测：每次调用生成 trace span、指标（QPS/延迟/错误率）、访问日志
- 安全：mTLS/令牌鉴权、服务间授权
一句话：**五步让调用”能通”，治理面让调用”可靠、可控、可观测”**。评价一个 RPC 框架的成熟度，看治理面而非协议本身。
协议设计的权衡
| 维度 | 二进制 RPC（Dubbo/gRPC） | HTTP/JSON（REST） |
|---|---|---|
| 性能 | 长连接+紧凑编码，高吞吐低延迟 | 文本冗余、短连接开销（HTTP2 缓解） |
| 契约 | IDL/接口强约束，编译期检查 | 文档约束，运行期才发现不一致 |
| 调试 | 需工具解码 | curl 即调 |
| 跨语言 | IDL 生成多语言 stub | 天然跨语言 |
| 生态 | 内网服务间 | 对外开放、浏览器可达 |
选型经验：内网服务间高频调用走 RPC，边界对外开放走 HTTP API；gRPC 用 Protobuf+HTTP2 在两者间取了平衡（强契约+跨语言+多路复用）。
与本地调用的语义差（理解 RPC 的哲学核心）
RPC 的目标是”像本地调用”，但分布式八谬误提醒差异不可消除：
- 本地调用要么成功要么抛异常；RPC 还有”结果未知的超时“——可能服务端已执行成功，重试即重复执行 → 幂等性是 RPC 接口的设计义务
- 本地调用毫秒内完成且参数引用传递；RPC 有序列化成本与深拷贝语义 → 大对象参数要警惕
- 本地调用无部分失败；RPC 链路任一环节可失败 → 调用方必须有降级预案
优秀的 RPC 使用方式不是假装网络不存在，而是让框架隐藏通讯细节、让开发者正视失败语义——接口设计幂等、超时显式、降级内置。
一次 Dubbo/gRPC 调用的对象旅程（串联全部概念）
代理对象拦截 → 请求对象（接口/方法/参数/attachments）→ 序列化（Hessian/Protobuf）→ 长连接发送（带 requestId）→ 服务端反序列化 → 反射/生成代码分发到实现 → 执行 → 响应序列化回传 → 客户端按 requestId 唤醒 Future → 返回/抛远程异常。治理面（发现/负载/熔断/追踪）包裹在这条旅程的每一步之外。
理解 RPC 框架 = 理解三层：通讯五步（能通）→ 治理面（可靠可控可观测）→ 分布式语义差（幂等/超时/降级）。三层都答到，”怎么理解 RPC”才是完整答案。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 非鱼小站！
相关推荐
2022-06-21
怎么考虑数据一致性问题
单体应用的数据一致性想象一下如果我们经营着一家大型企业，下属有航空公司、租车公司、和连锁酒店。我们为客户提供一站式的旅游行程规划服务，这样客户只需要提供出行目的地，我们帮助客户预订机票、租车、以及预订酒店。从业务的角度，我们必须保证上述三个服务的预订都完成才能满足一个成功的旅游行程，否则不能成行。 我们的单体应用要满足这个需求非常简单，只需将这个三个服务请求放到同一个数据库事务中，数据库会帮我们保证全部成功或者全部回滚。 当这个功能上线以后，公司非常满意，客户也非常高兴。 微服务场景下的数据一致性这几年中，我们的行程规划服务非常成功，企业蒸蒸日上，用户量也翻了数十倍。企业的下属航空公司、租车公司、和连锁酒店也相继推出了更多服务以满足客户需求，我们的应用和开发团队也因此日渐庞大。如今我们的单体应用已变得如此复杂，以至于没人了解整个应用是怎么运作的。更糟的是新功能的上线现在需要所有研发团队合作，日夜奋战数周才能完成。看着市场占有率每况愈下，公司高层对研发部门越来越不满意。 经过数轮讨论，我们最终决定将庞大的单体应用一分为四：机票预订服务、租车服务、酒店预订服务、和支付服务。服务各自...
2022-06-11
前后端分离是如何做的
在前后端分离架构中，后端只需要负责按照约定的数据格式向前端提供可调用的 API 服务即可。前后端之间通过 HTTP 请求进行交互，前端获取到数据后，进行页面的组装和渲染，最终返回给浏览器。 一句话定义之外，”如何做”要落到五个工程面：契约怎么定、跨域怎么通、认证怎么带、部署怎么分、协作怎么管。本文按这五面给出可执行的分离方案。 契约先行：API 是前后端唯一的交界 接口文档即合同：OpenAPI/Swagger 或 YApi/Apifox 维护接口定义（路径、方法、入参、出参、错误码），变更走评审流程，杜绝”口头改接口” 统一响应 envelope：{ code, message, data, traceId }，业务错误用 code 表达而非 HTTP 状态码混用（或明确约定：HTTP 表传输层、code 表业务层） 版本化：URL 前缀 /v1/ 或 Header 版本；破坏性变更升版本、旧版本限期下线 Mock 先行：契约定稿后前端用 Mock 平台并行开发，不被后端进度阻塞——这是分离带来的最大效率收益 跨域：...
2022-06-17
说说如何设计一个良好的 API
版本号在 RESTful API 中，API 接口应该尽量兼容之前的版本。但是，在实际业务开发场景中，可能随着业务需求的不断迭代，现有的 API 接口无法支持旧版本的适配，此时如果强制升级服务端的 API 接口将导致客户端旧有功能出现故障。实际上，Web 端是部署在服务器，因此它可以很容易为了适配服务端的新的 API 接口进行版本升级，然而像 Android 端、IOS 端、PC 端等其他客户端是运行在用户的机器上，因此当前产品很难做到适配新的服务端的 API 接口，从而出现功能故障，这种情况下，用户必须升级产品到最新的版本才能正常使用。 为了解决这个版本不兼容问题，在设计 RESTful API 的一种实用的做法是使用版本号。一般情况下，我们会在 url 中保留版本号，并同时兼容多个版本。 【GET】 /v1/users/{user_id} // 版本 v1 的查询用户列表的 API 接口【GET】 /v2/users/{user_id} // 版本 v2 的查询用户列表的 API 接口 现在，我们可以不改变版本 v1 的查询用...
2022-06-20
说说 CAP 定理、 BASE 理论
CAP 定理2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理。 CAP 理论为：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 一致性（Consistency）一致性指 “all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。 可用性（Availability）可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。 分区容错性（Partition tolerance）分区容错性指“the system continues to operate despite arbitrary ...
2022-06-27
微服务的安全
OAuth 是一个关于授权的开放网络标准，它允许第三方网站在用户授权的前提下访问用户在服务商那里存储的各种信息。实际上，OAuth 2.0 允许用户提供一个令牌给第三方网站，一个令牌对应一个特定的第三方网站，同时该令牌只能在特定的时间内访问特定的资源。用户在客户端使用用户名和密码在用户中心获得授权，然后客户端在访问应用是附上 Token 令牌。此时，应用接收到客户端的 Token 令牌到用户中心进行认证。 一般情况下，access token 会添加到 HTTP Header 的 Authorization 参数中使用，其中经常使用到的是 Bearer Token 与 Mac Token。其中，Bearer Token 适用于安全的网络下 API 授权。MAC Token 适用于不安全的网络下 API 授权。 OAuth2 令牌机制是微服务安全的认证基座，但微服务的安全面远不止认证：边界（网关）、服务间信任、数据与密钥、纵深防御四层都要设防。本文按”边界 → 认证授权 → 服务间 → 数据”四层给出完整安全模型。 第一层：边界安全（网关是唯一入口） 所有外部流量只经 API 网关...
2022-06-15
说说 Dubbo 的实现原理
Dubbo 作为 RPC 框架，实现的效果就是调用远程的方法就像在本地调用一样。如何做到呢？ 本地有对远程方法的描述，包括方法名、参数、返回值，在 Dubbo 中是远程和本地使用同样的接口 要有对网络通信的封装，要对调用方来说通信细节是完全不可见的，网络通信要做的就是将调用方法的属性通过一定的协议（简单来说就是消息格式）传递到服务端 服务端按照协议解析出调用的信息；执行相应的方法；在将方法的返回值通过协议传递给客户端；客户端再解析；在调用方式上又可以分为同步调用和异步调用； 三条是 RPC 的通用骨架，Dubbo 的独特之处在于它的微内核+SPI 扩展架构与全链路治理设计。本文按”架构形态 → 调用链对象流 → 注册中心交互 → SPI 机制”四层展开。 架构形态：微内核 + SPIDubbo 内核只做流程编排（Protocol/Cluster/Registry 等接口），全部能力以 SPI 扩展点插入： 协议：dubbo / triple / rest / grpc 注册中心：zookeeper / nacos ...
评论
WalineDisqus
