1 服务之间的相互调用
2 用加法函数描述 RPC 的功能
3 基本上是基于传输层写的另一种应用层协议
4 所以需要会 socket 编程
5 RPC 主要解决的 5 个问题
6 语法,如果我使用 HTTP 解决的话就是双方约定好
7 传递参数 , 也是约定好
8 数据表示 , 我用字符串 , 但毕竟我的场景毕竟简单
9 还可以传递结构体和类
10 传递 byte 还可能有大端小端问题 , 这不是 TCP UDP IP 统一了吗?
11 服务发现问题 , 客户端如何找到服务端口
12 发送错误,丢包,重传的问题
13 本地的时候是编译器帮做了语法分析 , RPC 则需要自己操心
14 一个双方约定好语法 格式的案例
15 RPC 结构图
16 一种叫做XDR的 External Data Representation的数据压缩格式 , 外部数据表示法 , 可以表示基本数据类型和结构体
17XDR的设计: XID唯一标识一对请求和回复 , 有RPC协议版本号 , 有程序编号和版本号(比如Calculator , version1 ?) 程序的方法编号比如add 1 , 调用的认证和鉴权过程 , 参数列表 , 上面的每一步有错都有对应的错误码
18双方需要约定上面一部分东西 , 有个约定文件 , 根据这个文件自动生成Stub程序
19 一张Stub程序的图 , 尝试解读一下 :
image.png
20客户端先clnt_create创建连接, 然后调用stub函数add_1 , 这个函数是发起RPC调用的地方 , 调用clnt_call
21服务端也有Stub程序监听,调用服务端逻辑 , 以上部分解决了协议约定问题 , 前三个
22还有传输问题 , 大牛做的事,我就不深入了 , 粗略看的话有队列机制,拥塞窗口等等 , 和TCP很像
23一张有限状态机的图,要怎么阅读 , 状态之间的转换
24 socket的异步模型有哪些
25 实现一个RPC框架主要难度在解决传输问题吧
26 如何找到RPC服务端的那个随机端口? -> 服务发现问题
27 one rpc的解决方法: 启动一个portmapper程序,分配固定的端口, RPC程序是用户写的所以是一个随机的端口 , RPC程序启动的时候会发送自己的信息给portmapper , 相当于一个注册中心吧 , 然后要调用的时候先来这里查 , 查到再去调用
28 ONE RPC和现在的框架对比有什么不足 ? 两边各有 3 个主体, RPCRuntime , Stub , 服务器
16 发起调用->调用 Stub->根据约定进行封装->通过 RPC Runtime 发送
17 Stub 处理类似语法的问题 , Runtime 处理传输问题
18 又是一个分层降低问题复杂度的案例
19 NFS network file system
20 nfs 运行要启动 mountd 和 nfsd , 一个挂载路径一个读写文件,相当于上面说的服务器
21 然后通过 RPC 和客户端通信 , 是最早的 RPC 应用
22
网友评论