RPC

一、RPC 的第一性原理

1.1 从本地方法调用谈起

在单机程序中，一次方法调用本质上是：

关键抽象：本地方法调用是一种 可靠、低延迟、强一致的控制转移。

RPC 的根本目标，是在 进程边界、机器边界甚至网络边界之外，尽可能复现这种“方法调用语义”。

1.2 从内存到网络：为什么 RPC 不可避免地复杂

当调用跨越进程或主机边界时：

必须引入新的数据传递机制：

本质变化：调用从“内存级协作”退化为“不可靠介质上的消息交换”。

RPC 并没有消除复杂性，而是 对复杂性的工程化封装。

1.3 分布式系统的不可违背前提

RPC 设计必须直面分布式系统的基本现实：

工程结论：RPC 的失败不是异常，而是常态。

因此：

二、RPC 的通用架构模型（核心）

任何 RPC 框架，无论名称与实现如何，其能力都可以抽象为以下几个稳定模块。

2.1 数据表示层：如何描述与演化数据

核心问题

抽象原则

常见实现思想

数据协议的本质不是“序列化速度”，而是 系统演进能力。

2.2 通信抽象层：如何跨不可靠介质传递消息

核心问题

稳定设计要素

通信层关注的是 吞吐、延迟与资源利用率，而非业务语义。

2.3 调用语义层：如何“像调用方法一样”使用远程服务

核心抽象

本质目标

调用语义层是 RPC 对开发者体验的核心贡献。

2.4 服务发现与路由：如何找到正确的服务实例

核心问题

抽象能力

服务发现解决的是 拓扑不稳定性问题。

2.5 负载均衡：如何在多个实例之间分配请求

稳定策略模型

负载均衡的本质是 风险与压力的分散。

2.6 容错与失败处理：如何面对必然失败

必须显式设计的能力

不设计失败路径的 RPC 系统，在规模化后一定崩溃。

2.7 可观测性与治理：系统如何被理解与控制

稳定治理能力

治理能力决定了 RPC 系统的 长期可运维性。

三、框架如何映射这些抽象能力

3.1 Dubbo：以性能与治理为核心的 RPC 实现

能力映射

Dubbo 的核心价值不在“快”，而在 治理能力完备。

3.2 Spring Cloud / HTTP：以生态整合为优先的取舍

本质差异不是技术，而是 设计目标不同。

3.3 框架不是答案，取舍才是

维度DubboSpring Cloud
性能高中
治理强依赖组件
生态聚焦 RPC全栈微服务

四、RPC 的代价、边界与演进哲学

4.1 RPC 带来的系统性成本

4.2 RPC 的适用边界

不适合：

4.3 演进方向

五、总结：RPC 的工程哲学

关联内容（自动生成）