Finagle 和其他 RPC 协议之间的关系?
这几天接触了 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 协议。
https://tools.ietf.org/html/r...
以上是 Finagle 和其他 RPC 协议之间的关系? 的全部内容, 来源链接: utcz.com/p/177568.html