这个引起争执的主题引出了几个问题。说一下我的理解
# 1 到底什么是 RPC
根据 wiki 上[Remote procedure call](
https://en.wikipedia.org/wiki/Remote_procedure_call)的定义,RPC 就是像调用本地方法一样调用共享网络上的方法( procedure 理论上应该被翻译成过程,但这里个人更倾向于翻译成方法,也符合 OOP 中 RMI 中的 M 的本意)。
可以看到这个定义里没有规定协议,所以 HTTP 方式的 spring cloud feign,我认为也可以被认定为 RPC。虽然 feign
# 2 RPC 的实现
RPC 的实现有语言限定的,诸如 Java RMI ;也有通用的,例如楼上提到过的 SOAP,Google 的 protobuf (用于 gRPC ),Apache 的 Thrift 和 Avro 等。这里的实现我理解和协议还是有差别的。
Hessian 在有些网站上也被认为是 RPC 实现,但 wiki 上的定义是二进制 web service 协议。
# 3 RPC 框架
RPC 框架我理解是对 RPC 实现的封装。
我理解 gRPC 和 thrift 本身就对 rpc 实现封装得不错了,所以没有一个专门的框架再包装一层。
根据 github 上的[RPC 框架 topic](
https://github.com/topics/rpc-framework),RPC 框架还包括腾讯的 Tars ( C++),蚂蚁的 sofa-rpc ( Java ),微博的 motan (有 go 实现)。
hprose 是跨语言的,在 Github 上有各种语言下的实现。
Dubbo 这种全家桶中也有 rpc 的部分,但称为 rpc 框架总觉得有点别扭。
Github 星数比较高的 Java 语言 RPC 框架还有 NettyRpc,Jupiter,xxl-rpc 等。
# 4 服务发现注册
主题里提到的 zk,etcd,eureka ( LZ 拼错了),从分类上术语服务发现注册,我认为不能混在 RPC 里讨论。
服务发现是辅助与 rpc client 找到 rpc server,但并不是 rpc 里必不可少的部分(如果不考虑高可用的话)