周志明的软件架构课
周志明
博士,远光软件研究院院长,《深入理解 Java 虚拟机》《凤凰架构》等书作者
54203 人已学习
免费领取
课程目录
已完结/共 74 讲
架构师的视角 (24讲)
周志明的软件架构课
15
15
1.0x
00:00/00:00
登录|注册

08 | 远程服务调用(下):如何选择适合自己的RPC框架?

你好,我是周志明。
上一讲,我们主要是从学术的角度出发,一起学习了 RPC 概念的形成过程。今天这一讲,我会带你从技术的角度出发,去看看工业界在 RPC 这个领域曾经出现过的各种协议,以及时至今日还在层出不穷的各种框架。你会从中了解到 RPC 要解决什么问题,以及如何选择适合自己的 RPC 框架。

RPC 框架要解决的三个基本问题

在第 1 讲“原始分布式时代”中,我曾提到过,在 80 年代中后期,惠普和 Apollo 提出了网络运算架构(Network Computing Architecture,NCA)的设想,并随后在DCE 项目中,发展成了在 Unix 系统下的远程服务调用框架DCE/RPC
这是历史上第一次对分布式有组织的探索尝试。因为 DCE 本身是基于 Unix 操作系统的,所以 DCE/RPC 也仅面向于 Unix 系统程序之间的通用。
补充:这句话其实不全对,微软 COM/DCOM 的前身MS RPC,就是 DCE 的一种变体版本,而它就可以在 Windows 系统中使用。
在 1988 年,Sun Microsystems 起草并向互联网工程任务组(Internet Engineering Task Force,IETF)提交了RFC 1050规范,此规范中设计了一套面向广域网或混合网络环境的、基于 TCP/IP 网络的、支持 C 语言的 RPC 协议,后来也被称为是ONC RPC(Open Network Computing RPC/Sun RPC)。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

RPC框架的选择对于远程服务调用至关重要。本文从技术角度出发,探讨了RPC框架的发展历程和解决的基本问题。首先,RPC框架需要解决数据表示、数据传递和方法表示三个基本问题。针对数据表示,各种RPC协议都采用序列化协议,如XDR、CDR、Java RMI等。在数据传递方面,不同的Wire Protocol被用于表示两个服务Endpoint之间的交换数据行为,如IIOP、RTPS、SOAP等。而在方法表示方面,需要统一的标准来表示方法,如DCE/RPC的方法编号。现代的RPC框架提供了多种解决方案,因此出现了众多并行发展的RPC框架。这些框架在解决RPC的基本问题上各有特点,因此选择适合自己的RPC框架需要综合考虑各方面因素。 文章介绍了RPC框架的发展历程和技术特点。从早期的DCE/RPC和ONC RPC到CORBA和Web Service,每个阶段的RPC协议都有其特点和局限性。CORBA虽然支持多种编程语言,但设计繁琐且规范晦涩难懂,导致各家语言的实现互不兼容。而Web Service采用XML作为序列化协议,虽然具有自描述能力,但数据密度低导致性能问题,并且协议繁多,学习负担重。文章指出,RPC协议在简单、普适和高性能之间难以达到平衡。这些观点为读者提供了对RPC框架发展历程和技术特点的深入了解,有助于读者在选择适合自己的RPC框架时进行综合考量。 文章还介绍了RPC框架的发展方向,包括面向对象、性能和简化等不同的发展路径。随着RPC框架的不断发展,越来越多的框架朝着更高层次和插件化方向发展,将核心能力设计为可配置的扩展点,辅以外围功能的支持。这种发展趋势为读者提供了对未来RPC框架发展方向的展望。 总的来说,本文通过介绍RPC框架的发展历程、技术特点和发展方向,为读者提供了对RPC框架选择的参考依据,帮助他们更好地理解RPC框架的发展脉络和技术特点。

该试读文章来自《周志明的软件架构课》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(32)

  • 最新
  • 精选
  • zhanyd
    周老师讲的太好了,从为什么需要这个技术,这个技术解决了什么问题,到这个技术的过去,现在,以及未来的发展方向,有理有据,娓娓道来,让我们有了系统的认识,有了大局观,不会迷失在细枝末节里,超喜欢这样的讲课方式。

    作者回复: 感谢认可

    2020-12-04
    3
    41
  • Mr.Chen
    RPC只是服务(进程)之间简化调用的一种方式,使得开发者聚焦于业务本身,而对于服务间通信的各种细节交给框架处理,撇开这一层面来讲,分布式系统的服务调用可以采用任何一种通信方式,比如http、socket等等。

    作者回复: 对的

    2020-12-08
    32
  • 明翼
    老师讲的很好,连续看了好几篇. 分布式系统必然要产生交互,不然就不是一个系统了, 那么我们只要可以通信就可以了,不一定要RPC,比如我们可以通过kafka队列交互,可以通过通用的DB来交互,我觉得都是可以的,利用这种第三方交互,还减少了依赖性,系统间的耦合性更低。 当然现在分布式中的RPC调用更复杂,通过服务发现,容灾等,也减少了部分依赖。

    作者回复: 感谢认可。

    2020-12-13
    2
  • 有铭
    原来微软的COM的前身居然是RPC。 原来UUID是因为RPC而诞生的。 这两点我是头一次知道

    作者回复: 准确地说,DCOM的前身是MSRPC

    2020-12-04
    2
  • Helios
    虽然感觉老师最后的问题回答不需要才是正解。 但是个人觉得还是需要的,如果自己基于socket去搞的话,肯定也避免不了数据如何表示,如何表示方法问题。 使用rest http的话还要付出性能问题。在微服务领域已经大行其道的grpc在性能,容错,可扩展都的很好了。 最后没听理解老师说跳出本地调用会海阔天空是什么意思,能否指点一下

    作者回复: 这些题目不太可能有标准的正解。 “海阔天空”其实就是后面2节关于REST的内容。

    2021-01-31
    1
  • linker
    老师好,linux系统的dbus是不是也可以理解为一种面向对象的rpc.只是他它只能在本机进程之间通讯

    作者回复: 这是一种典型的IPC方式,有很多东西RPC不能做/不提倡做的(譬如distribute objects)在IPC中未必不能做。

    2021-01-09
  • Wacky小恺
    个人理解的是分布式系统可以不使用RPC,只要能保证远程调用通信即可。最原始的类似于TCP/UDP提供的socket,它也可以进行端到端的传输,而且使用统一的协议保证在各种语言中都可以使用。但是程序编写带来了复杂性,需要自己考虑各种各样的问题,如丢包、重试等。RPC框架相当于屏蔽了底层的复杂实现,提供更高层次的调用方式以解决此类问题。
    2020-12-04
    23
  • neohope
    CORBA看起来比较烦,用好了比较难,写起来比较烦,但好在起步早啊,而且贵在不断缓慢进步; DCOM一心要兼容COM,有些反人类,看起来就烦,用好了很难,写起来很烦; Java RMI、JAVA EJB,都是犯了相同的错,标准太烦了,对开发人员太不友好了。 WebService是看起来容易,用好了很难,写起来很烦;但同时代其他协议都是看起来就很难,所以胜出了,在一段时间内大行其道; 后来REST出现了,看起来容易,学起来容易,用起来也很容易。轻松将WebService挑落马下。 再看现在的Dubbo、Thrift、gRPC等,使用都相对简单,容易上手,开发者友好。 WCF有些小奇葩,很多想法很好,就是重了些,管得有些多,配置有些烦,如果要更多的占领市场,就应该让其变得更容易使用才对,而且应该跨平台才行。反而倒是WebAPI感觉更有前途,至少使用复杂程度和Flask、SpringBoot在一个水平线。 说到底吧,RPC协议和框架,其最终用户就是开发。 一开始能解决用户需求就行,没有其他替代方案,能解决问题,开发前辈们就很开心。 但用着用着,开发感觉体验太差了,就会有新一代产品出来,替代掉之前的产品。 而且越是新的协议,就不能有大的学习成本,容易上手,功能强大。 不信的话,你看下新的手机,比30年前功能多了不知道多少,但哪里还要一本厚厚的说明书才能上手呢?
    2021-03-29
    1
    8
  • 小高
    继续打卡,日常追剧。
    2020-12-05
    7
  • 芋头
    这一节对RPC框架有比较全面的了解,之前接触过的Dubbo和Webservice 及听说过的gRPC、Thrift.这几年微服务确实发展快,17年那会掌握Dubbo框架已经算比较时髦。当时用的websevice服务的使用下来的缺点很明显,服务之间依赖严重,serviceA依赖serviceB实现部分功能。 ,如果serviceB服务挂了,serviceA都启动不了,弊端很大。现在来来看这部分技术正在被SpringCloud 为代表的微服务组件所取代。这里有个疑问是Dubbo这种RPC框架未来的使用场景会在哪些方面呢?是否都可以被微服务取代。
    2021-03-20
    1
收起评论
显示
设置
留言
32
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部