关于RPC、RESTful一些思考

1. 缘起

之前在知识星球看到有一个同学聊到了RPC和RESTful的一些问题。正好这两个我都用过,另外我还用过基于TCP消息的一个架构,我就说说自己的体会吧。

2. RPC

RPC是Remote Procedure Call Protocol的缩写,主要是用来完成跨主机的调用。更具体的解释可以看知乎的这个答案谁能用通俗的语言解释一下什么是 RPC 框架。 重点有三个部分:

1. Call ID映射。
2. 序列化和反序列化。
3. 网络传输。

3. RESTful

REST(REpresentational State Transfer 直接翻译：表现层状态转移) 关于REST是什么,如何用通俗的语言来解释的问题请看知乎的这个答案

重点有三部分:

1. 看Url就知道要什么
2. 看http method就知道干什么
3. 看http status code就知道结果如何

4. 基于消息的框架

在工作的时候，我用到过一个公司自研的基于消息的框架，整体的交互流程如下。

)

重点有三部分:

1. 看消息类型，就知道需要进行的操作。
2. 通过反序列化就拿到了具体的数据。
3. 通过网络进行消息回复。

5. 函数调用

我们在平时中用到最多的就是函数调用了,不过函数调用一般发生在同一种编程语言之中,多在本机进行。

重点有三部分:

1. 通过函数签名,知道了调用哪个函数。
2. 通过参数列表,获取请求的数据。
3. 调用栈返回的时候,得到返回的结果。

6. 区别和联系以及应用场景

从上面的表格中我们可以看出以下几点:

1. 因为函数调用不跨语言和不跨框架特征,在实际的使用中,一般以SDK方式或者源码的方式提供。

2. 消息框架可以采用二进制或者文本协议,但需要调用者和被调用者提前确定好消息的格式和类型。但是采用异步调用的方式,

3. RESTful由于采用了标准的基于HTTP的文本协议,更适合作为外部的接口提供给使用者,减少联合调试的成本。

4. RPC因为是同步接口和二进制协议,在调用成本上比较低,但是因为很难跨框架的问题,所以更适合在内部使用。如果提供给外部作为接口,其耦合性过高,导致调用者必须使用被调用者的框架。

可以聊聊文学，
可以聊聊摄影，
可以聊聊程序，
可以聊聊感悟，
你想听我聊什么，请告诉我。