{"name":"rpc","id":"计算机网络-rpc","content":"# RPC\n\n## 一、RPC 的第一性原理\n\n### 1.1 从本地方法调用谈起\n\n在单机程序中，一次方法调用本质上是：\n\n* 参数在调用方与被调用方之间通过 **内存** 传递\n* 调用目标由 **编译期或运行期指令** 唯一确定\n* 执行过程在 **同一地址空间** 内完成\n* 调用结果通过 **调用栈** 返回\n\n> **关键抽象**：\n> 本地方法调用是一种 **可靠、低延迟、强一致的控制转移**。\n\nRPC 的根本目标，是在 **进程边界、机器边界甚至网络边界之外**，\n**尽可能复现这种“方法调用语义”**。\n\n---\n\n### 1.2 从内存到网络：为什么 RPC 不可避免地复杂\n\n当调用跨越进程或主机边界时：\n\n* 内存不再共享\n* 调用栈无法贯通\n* 执行环境不再一致\n\n必须引入新的数据传递机制：\n\n* 进程内通信（Pipe、Signal、Shared Memory）\n* 网络通信（Socket）\n\n> **本质变化**：\n> 调用从“内存级协作”退化为“不可靠介质上的消息交换”。\n\nRPC 并没有消除复杂性，而是 **对复杂性的工程化封装**。\n\n---\n\n### 1.3 分布式系统的不可违背前提\n\nRPC 设计必须直面分布式系统的基本现实：\n\n* 网络不可靠\n* 延迟不可忽略\n* 节点会失败\n* 拓扑会变化\n\n> **工程结论**：\n> RPC 的失败不是异常，而是常态。\n\n因此：\n\n* RPC ≠ 远程方法调用\n* RPC = **在失败常态下模拟调用语义的系统工程**\n\n---\n\n## 二、RPC 的通用架构模型（核心）\n\n任何 RPC 框架，无论名称与实现如何，其能力都可以抽象为以下几个稳定模块。\n\n---\n\n### 2.1 数据表示层：如何描述与演化数据\n\n#### 核心问题\n\n* 如何让不同语言、不同版本的系统理解同一份数据？\n\n#### 抽象原则\n\n* **结构化优于文本化**\n* **显式 schema 优于隐式约定**\n* **向前 / 向后兼容是第一设计目标**\n\n#### 常见实现思想\n\n* IDL（Interface Definition Language）\n* 字段编号而非字段名\n* 类型显式编码\n\n> 数据协议的本质不是“序列化速度”，而是 **系统演进能力**。\n\n---\n\n### 2.2 通信抽象层：如何跨不可靠介质传递消息\n\n#### 核心问题\n\n* 如何在网络上传递请求与响应？\n\n#### 稳定设计要素\n\n* 连接管理（短连接 / 长连接）\n* IO 模型（阻塞 / 非阻塞 / 多路复用）\n* 数据传输语义（请求-响应 / 单向 / 流式）\n\n> 通信层关注的是 **吞吐、延迟与资源利用率**，而非业务语义。\n\n---\n\n### 2.3 调用语义层：如何“像调用方法一样”使用远程服务\n\n#### 核心抽象\n\n* Stub / Proxy\n* 同步 / 异步\n* Future / Callback / Reactive\n\n#### 本质目标\n\n* 将“消息发送”包装为“函数调用体验”\n\n> 调用语义层是 RPC 对开发者体验的核心贡献。\n\n---\n\n### 2.4 服务发现与路由：如何找到正确的服务实例\n\n#### 核心问题\n\n* 服务实例是动态变化的\n\n#### 抽象能力\n\n* 注册（Register）\n* 订阅（Subscribe）\n* 通知（Notify）\n\n> 服务发现解决的是 **拓扑不稳定性问题**。\n\n---\n\n### 2.5 负载均衡：如何在多个实例之间分配请求\n\n#### 稳定策略模型\n\n* 随机 / 轮询\n* 权重感知\n* 最小负载 / 最少活跃\n* 一致性哈希\n\n> 负载均衡的本质是 **风险与压力的分散**。\n\n---\n\n### 2.6 容错与失败处理：如何面对必然失败\n\n#### 必须显式设计的能力\n\n* 超时控制\n* 重试策略\n* 快速失败\n* 幂等保障\n\n> 不设计失败路径的 RPC 系统，在规模化后一定崩溃。\n\n---\n\n### 2.7 可观测性与治理：系统如何被理解与控制\n\n#### 稳定治理能力\n\n* 调用链路追踪\n* 指标统计（QPS / Latency / Error）\n* 依赖关系可视化\n\n> 治理能力决定了 RPC 系统的 **长期可运维性**。\n\n---\n\n## 三、框架如何映射这些抽象能力\n\n### 3.1 Dubbo：以性能与治理为核心的 RPC 实现\n\n#### 能力映射\n\n* IDL / 接口 → 服务契约\n* Registry → 动态服务发现\n* Cluster → 容错策略组合\n* LoadBalance → 客户端路由决策\n* SPI → 插件化扩展点\n\n> Dubbo 的核心价值不在“快”，而在 **治理能力完备**。\n\n---\n\n### 3.2 Spring Cloud / HTTP：以生态整合为优先的取舍\n\n* 通信协议选择 HTTP\n* 更强调标准化与跨语言\n* RPC 语义弱于 Dubbo\n\n> 本质差异不是技术，而是 **设计目标不同**。\n\n---\n\n### 3.3 框架不是答案，取舍才是\n\n| 维度 | Dubbo  | Spring Cloud |\n| -- | ------ | ------------ |\n| 性能 | 高      | 中            |\n| 治理 | 强      | 依赖组件         |\n| 生态 | 聚焦 RPC | 全栈微服务        |\n\n---\n\n## 四、RPC 的代价、边界与演进哲学\n\n### 4.1 RPC 带来的系统性成本\n\n* 强同步依赖\n* 服务耦合加深\n* 故障传播放大\n\n### 4.2 RPC 的适用边界\n\n* 内部服务调用\n* 强一致交互\n\n不适合：\n\n* 高不确定网络\n* 大规模异步处理\n\n---\n\n### 4.3 演进方向\n\n* 同步 RPC → 异步 / 事件驱动\n* 点对点调用 → 服务网格治理\n* 框架能力 → 平台能力\n\n---\n\n## 五、总结：RPC 的工程哲学\n\n* RPC 不是“远程方法调用”\n* RPC 是 **对不可靠世界的工程妥协**\n* 框架会变化，能力模型不会\n\n## 关联内容（自动生成）\n\n- [/软件工程/微服务/微服务.md](/软件工程/微服务/微服务.md) 微服务架构是RPC技术应用的重要场景，RPC作为微服务间通信的核心机制，两者在分布式系统中紧密关联\n- [/软件工程/微服务/服务治理/服务发现.md](/软件工程/微服务/服务治理/服务发现.md) 服务发现是RPC框架的重要组成部分，解决了服务实例动态变化时的寻址问题，是实现RPC调用的基础设施\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) RPC是分布式系统中实现节点间通信的核心技术，分布式环境中的网络不可靠性、延迟等问题直接影响RPC的设计与实现\n- [/软件工程/微服务/服务治理/服务治理.md](/软件工程/微服务/服务治理/服务治理.md) 服务治理涵盖了RPC调用的全生命周期管理，包括服务注册、发现、路由、负载均衡、容错等，是RPC系统稳定运行的保障\n- [/软件工程/架构/系统设计/网关.md](/软件工程/架构/系统设计/网关.md) API网关通常承担着服务聚合和流量路由功能，与RPC框架配合实现服务间通信和客户端访问控制\n- [/软件工程/架构/系统设计/分布式/分布式事务.md](/软件工程/架构/系统设计/分布式/分布式事务.md) RPC是分布式系统中实现跨服务操作的基础，而分布式事务则解决了RPC调用链路中数据一致性问题\n- [/软件工程/架构/系统设计/可观测性.md](/软件工程/架构/系统设计/可观测性.md) RPC调用的链路追踪、监控指标和日志是分布式系统可观测性的重要组成部分，帮助理解和优化系统性能\n- [/软件工程/微服务/服务治理/服务容错.md](/软件工程/微服务/服务治理/服务容错.md) RPC框架通常集成了服务容错能力，如超时控制、重试策略、熔断机制等，以应对分布式系统中的各种故障\n- [/计算机网络/应用层.md](/计算机网络/应用层.md) RPC作为应用层协议，依赖网络层提供的传输服务，理解应用层协议设计原理对实现高效的RPC系统至关重要\n","metadata":"tags: ['网络', '分布式系统', '架构设计']","hasMoreCommit":false,"totalCommits":10,"commitList":[{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2025-12-18T18:22:27+08:00","author":"MY","message":"docs(rpc): 更新RPC文档中的服务治理相关链接","hash":"dadfa31552be0d3d7b23a4d6e12ab34620900ac3"},{"date":"2025-12-18T18:18:46+08:00","author":"MY","message":"docs(rpc): 重构 RPC 文档内容与结构","hash":"6da4db40d5d6d7c7dd2fcdf282e5b6a0cf597394"},{"date":"2024-11-08T16:23:39+08:00","author":"MY","message":"📦计算机网络应用层","hash":"db36530812209177b6a87243dfa274d323a73e82"},{"date":"2023-03-27T20:50:05+08:00","author":"MY","message":"✏️RPC","hash":"8ccbe34d6af47e730da56bb03951ce426eb39252"},{"date":"2022-06-15T17:47:32+08:00","author":"cjiping","message":"📦整理 服务容错","hash":"72f94da3b44306fd7768d1716420231dcda7b6b1"},{"date":"2022-06-14T16:05:20+08:00","author":"cjiping","message":"📦整理 零拷贝","hash":"e17e9f8a29c5a0dc08e77530a959a27b32e45e39"},{"date":"2022-06-10T18:12:28+08:00","author":"cjiping","message":"✏️更新 RPC","hash":"cd06070000ed3017cc34d1dbde2a97383e88384f"},{"date":"2020-11-09T15:23:51+08:00","author":"MY","message":"✏更新 RPC","hash":"a553c2e8a2272b52bda5cf3b7aba1d87514466c2"},{"date":"2020-05-08T21:02:18+08:00","author":"MY","message":"增加 rpc","hash":"0acda65520cd2e94a98139c49fc2b72b6a84c42f"}],"createTime":"2020-05-08T21:02:18+08:00"}