近些年，分布式和微服务架构非常流行，RPC在开发任务中的应用越来越频繁，其重要性也日益凸显。

今天我们探讨RPC的含义是什么，探究为何要了解RPC，以及学习RPC能够收获哪些知识。

什么是「RPC」

RPC 全称 Call, 的部分说明：

远程过程调用是一种技术，它由调用方发起，调用方向目标方发送请求，目标方执行请求并返回结果，调用方接收结果。

此处核心在于「」部分,其次要关注 RPC中的R -「」。因此,该RPC的含义即为一种调用远程执行方法的约定。我们通常对方法调用会遵循以下方式

= child.say("Hello World");

这种通常是指调用本地的方法，例如 Java 应调用同一 JVM 内的方法。

如果要将前面的代码改为通过远程过程调用方式使用，具体写法会有什么不同呢？

其实是没有的。

操作时依然遵循这种方式，配置中只需标明该方法关联的远程位置即可。

再举个生活化的例子。

假如你是个招揽旅人的人，每当收集到足够多的客人，你就会卖力地吆喝，在各种奇特的平台上搜索，寻找各个景点的向导。后来有一天，你和路边的许多复印店达成了合作。符合条件能够引导相应景点的都可以在复印店「注册」，你下次来的时候依据记录，直接「联系」相关的人就行，这样会轻松很多呢。

这里我们看到两种RPC的用形式：

直接在配置中固定写好远程方法的地址，请求是一步到位

配置里指定的注册处地址，方法请求时会先去注册处查询方法地址，然后才进行执行

由此看来，你一定会感叹prc是什么意思，为何不采用一个远距离手段呢，这并不复杂，有什么值得探讨的。

那我们继续这个生活化的例子。

当你搜集了游客联络频繁合作的向导后，这个人却生病了。你该找谁呢？ 你说有「替补」啊，登记簿里记满了呢。

那好，这好多个导游里，你「选哪一个」？

你讲，看，我何必管得那么细，随便选一个打电话就行。行，这时候你就已经应用了RPC里的「负载均衡」，只是你的方法是采用「随机」。

如果导游报名时都提交了个人影像资料和信誉等级评估，那么你不会随便选一个，会对比照片，判断哪个看起来更可信，哪个评级更优。这些信息都作为联系他的参考依据。在众多导游中，这个依据决定了他们被联系的概率。这时候你的选择不再是纯粹碰运气，而是依据这些参考依据来筛选。

比如说你们合作很多回，那几个常去的地点总是分配给同几位向导，彼此都很熟，每次带团都指定找他们。这种情况下你的应对方法就转变为「一致性Hash」。

后来，有向导告知，近来类似他们这样的兼职向导，被发现主动揽活，可能会遭到处罚，下次联系他时，少说些话。于是你们达成一项简易约定：先报“是或否”，表明是否有空，再报“一至百”，说明你们带领游客参观的地点。接着再报“是或否”，表示是否能够安排购物环节。

你会意识到，当前你们的协议中包含着编码，也有压缩，每个人在接收对方信息时，都必须经过你的解码，才能还原成真实的内容。在 RPC 中也是这样，在调用方法之前，需要将相应的参数序列化，按照规定的「格式」发送，到达后进行相应的还原，然后执行方法。

后来，你的业务规模持续扩大，某个旅游景点的导游们自发形成团队。当你需要导游服务时，这个团队的成员会依据既定规则自动选出最合适的人选prc是什么意思，这些导游共同构成的，就是一个「」

公司规模持续扩大之际，你组建了专门团队，这些成员会定期与各导游团队沟通，评估该景点是否具备合作条件，在此期间，该团队承担着监督职责。

(一口老血，编不下去了……)

接下来要说的是，我们为什么要学习 RPC。

为什么要学习 RPC

为何要研习 RPC 技术？ 早先我们曾提及，微服务架构与分布式系统已成为普遍的开发模式，而 RPC 在这些模式中扮演着关键角色。掌握 RPC 知识，有助于深入理解并胜任复杂应用的设计与构建工作。

此外，RPC 包含的各种技术，能让学习者见识更加开阔，每个领域，都值得钻研。而钻研技术，尤其是源代码，又会反过来加深对 RPC 的理解，从而写出更高质量的代码。

学习 RPC 我们能掌握什么

我们上面的生活化例子中，提到了这些技术