Finagle 和其他 RPC 协议之间的关系？

Z时代
2024-01-10
分类：技术分享

这几天接触了 Finagle 框架，有点疑惑它和其他 RPC 协议之间的关系。

首先，阅读博客深入理解 RPC 之协议篇 | 徐靖峰|个人博客的时候了解到，RPC 框架可以分为 protocol > transport > codec > serialize 的层次。

而 RPC 协议主要用于配置 refer（发现服务）和 exporter（暴露服务）的实现方式。

但是看这张图，RPC 协议似乎又包含更多的东西：

现在我的问题就是：

RPC 协议到底包含了什么？

RPC 协议和框架之间的关系？

Finagle 和其他 RPC 协议之间的关系是啥？它和其他 RPC 协议组合在一起的时候负责干啥？不同的协议一样吗？

回答

refer、exporter 这都是 Dubbo 提出来的概念，你要硬往别的 RPC 框架或协议里套，倒是也能找到类似的玩意儿，但毕竟不是国际标准，用不着非得理解它的意思。

其实 RPC 翻译过来就是“Remote Procedure Call：远程过程调用”，是相对于 LPC（Locale Procedure Call：本地过程调用）而言的，二者都是属于 IPC（Inter-Process Communication：进程间通信）的范畴内。

进程内通信，直接调用相应的函数方法就可以；同一主机下的进程间通信，操作系统本身也提供了一些支持；但跨主机的进程间通信，就得额外想办法了。

于是乎人们想到了利用网络来通信。但徒手写 Socket 程序那多恶心？怎么想办法让 RPC 跟 LPC 似的，既能保持原有的强类型约束，还可以写法简练一些、不用操心数据序列化、网络传输等问题？于是 RPC 协议就出现了。

一般来说 RPC 协议为了稳定性都是基于 TCP 协议实现的，有一些甚至直接用了更上层的 HTTP 协议（比如 gRPC 用了 HTTP/2）。

你截图里底下橙色的部分才是 RPC 协议本身关注的，上面绿色的部分压根跟 RPC 协议无关了，而是 RPC 服务治理问题 —— 本质上和所有集群的服务治理没什么区别，比如你的 Web Server 集群是不是也得考虑负载均衡问题？

回到问题：

1、RPC 的概念最早尤由发明出 Java 的 Sun 公司提出，后来形成了 RFC-1050 规范（最后有链接，感兴趣可以自己阅读）。其实就规定了三部分：

Unique specification of a procedure to be called. 要调用的过程的唯一定义 —— 说白了就是给要调用的方法起个名。

Provisions for matching response messages to request messages. 匹配响应消息和请求消息的规则 —— 说白了就是规定请求和响应的报文长啥样。

Provisions for authenticating the caller to service and vice-versa. 对服务的调用者、被调用者进行身份验证的规则 —— 说白了就是被调用方怎么验证是不是合法请求、调用方怎么验证是不是合法响应。

绝大部分 Java 实现的 RPC 协议都会遵循这个规范。但其他语言的就未必了。所以实际上还是没有一个真正的国际标准告诉你啥是 RPC 协议。但绝对不会是你一开头提到的那四个层级，那四个还是 Dubbo 总结出来的概念，不一定放之四海而皆准。

2、跟 Web 框架（如 SpringBoot）与 Web 协议（如 HTTP）的关系一样。

3、Google 的 Finagle，Facebook 的 Thrift，阿里巴巴的 Dubbo，这三者是同一级别的东西，本身是框架，这些框架也定义了自己的协议。比如 Dubbo，我们提到它的时候，既指的是 Dubbo RPC 框架，也指的是 Dubbo RPC 协议。而 Twitter 的 Finagle 只是框架，它本身没有定义出一个新的 RPC 协议来，而是可以使用上述几种或其他协议来充当它的 RPC 协议。