周志明架构课–07.远程服务调用

架构师视角

0. 介绍了下架构师的职责
1. RPC在众眼里是什么样的呢什么一直这么火呢
2. 借用本地调用过程的例子来引入，同时做出假设调用者和被调用者不在同一个进程之内
3. 解决上面步骤2问题的方法，有六种。尤其是最后一种本地套接字接口，它的设计理念简直直RPC最初的目的不谋而合
4. 但在那个时候对于透明的分布式系统而言，别说存在着大量的问题需要解决的，就连认识上都存在大量误解。
5. 最终，施乐公司的Palo Alto研究中心，发布了第一个基于RPC的应用，并正式提出了RPC的概念。

? 在这篇文章中有几个提法比较有意思：比如RPC作为分布式前置的基础条件，再比如RPC应该是一种高层次的，或者说语言层次的特征，而不是像IPC那样，是低层次的，或者说系统层次的特征；还有RPC以模拟进程间方法调用为起点，许多思想和概念都借鉴的是IPC，都能给人耳目一新的感觉。

好了下面咱们开始正式的内容：

0. 架构师的职责

1.大众眼中的RPC（远程服务调用）/h4>

关于RPC三个小问题：

RPC为什么这么火热的原因：

• 可能是微服务风潮带来的热度
• 作为开发者，我们很多人对RPC本身可以解决什么问题、如何解决这些问题、为什么要这样解决，都或多或少存在些认知模糊的情况

2. 本地方法调用

? 本地方法调用几个概念

做一个假设：如果在调用println()的时候，发现它并不在当前内存地址空间中，又会出现什么问题呢/p>

1. 前面的传递参数、传回结果都依赖于栈内存的帮助，如果Caller与Callee分属不同的进程，就不会拥有相同的栈内存，那么在Caller进程的内存中将参数压栈，对于Callee进程的执行毫无意义。
2. println()方法版本选择依赖于语言规则的定义，而如果Caller与Callee不是同一种语言实现的程序，方法版本选择就将是一项模糊的不可知行为。

如何解决两个进程间通讯的问题问题：

3.竟然不谋而合

? RPC可以作为IPC的一种特例来看待。

? IPC Socket是操作系统提供的标准接口，所以它完全有可能把远程方法调用的通讯细节，隐藏在操作系统底层，从应用层面上来看，可以做到远程调用与本地方法调用几乎完全一致。

? 还记得远程服务调用最初的目的吗strong>与调用本地方法一致。

4.透明RPC调用存在的问题

• 两个进程通讯，谁作为服务端，谁作为客户端/li>
• 怎样进行异常处理常该如何让调用者获知/li>
• 服务端出现多线程竞争之后怎么办/li>
• 如何提高 络利用的效率，比如连接是否可被多个请求复用以减少开销否支持多播/li>
• 参数、返回值如何表示该有怎样的字节序/li>
• 如何保证 络的可靠性，比如调用期间某个链接忽然断开了怎么办/li>
• 服务端发送请求后，收不到回复该怎么办/li>

? 分布式运算的八宗罪：

1. 络是可靠的（The network is reliable）
2. 延迟是不存在的（Latency is zero ）
3. 带宽是无限的（Bandwidth is infinite）
4. 络是安全的（The network is secure）
5. 拓扑结构是一成不变的（Topology doesn’t change）
6. 总会有一个管理员（There is one administrator）
7. 不考虑传输成本（Transport cost is zero）
8. 络是同质化的（The network is homogeneous）

5.RPC的概念

? 传奇的施乐Palo Alto研究中心，发布了基于Cedar语言的RPC框架Lupine，并实现了世界上第一个基于RPC的商业应用Courier。并提出了RPC的概念，也就我们今天看到：

思考题