08 | 远程服务调用(下):如何选择适合自己的RPC框架?
RPC 框架要解决的三个基本问题
- 深入了解
- 翻译
- 解释
- 总结
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-04341 - Mr.ChenRPC只是服务(进程)之间简化调用的一种方式,使得开发者聚焦于业务本身,而对于服务间通信的各种细节交给框架处理,撇开这一层面来讲,分布式系统的服务调用可以采用任何一种通信方式,比如http、socket等等。
作者回复: 对的
2020-12-0832 - 明翼老师讲的很好,连续看了好几篇. 分布式系统必然要产生交互,不然就不是一个系统了, 那么我们只要可以通信就可以了,不一定要RPC,比如我们可以通过kafka队列交互,可以通过通用的DB来交互,我觉得都是可以的,利用这种第三方交互,还减少了依赖性,系统间的耦合性更低。 当然现在分布式中的RPC调用更复杂,通过服务发现,容灾等,也减少了部分依赖。
作者回复: 感谢认可。
2020-12-132 - 有铭原来微软的COM的前身居然是RPC。 原来UUID是因为RPC而诞生的。 这两点我是头一次知道
作者回复: 准确地说,DCOM的前身是MSRPC
2020-12-042 - Helios虽然感觉老师最后的问题回答不需要才是正解。 但是个人觉得还是需要的,如果自己基于socket去搞的话,肯定也避免不了数据如何表示,如何表示方法问题。 使用rest http的话还要付出性能问题。在微服务领域已经大行其道的grpc在性能,容错,可扩展都的很好了。 最后没听理解老师说跳出本地调用会海阔天空是什么意思,能否指点一下
作者回复: 这些题目不太可能有标准的正解。 “海阔天空”其实就是后面2节关于REST的内容。
2021-01-311 - linker老师好,linux系统的dbus是不是也可以理解为一种面向对象的rpc.只是他它只能在本机进程之间通讯
作者回复: 这是一种典型的IPC方式,有很多东西RPC不能做/不提倡做的(譬如distribute objects)在IPC中未必不能做。
2021-01-09 - Wacky小恺个人理解的是分布式系统可以不使用RPC,只要能保证远程调用通信即可。最原始的类似于TCP/UDP提供的socket,它也可以进行端到端的传输,而且使用统一的协议保证在各种语言中都可以使用。但是程序编写带来了复杂性,需要自己考虑各种各样的问题,如丢包、重试等。RPC框架相当于屏蔽了底层的复杂实现,提供更高层次的调用方式以解决此类问题。2020-12-0423
- neohopeCORBA看起来比较烦,用好了比较难,写起来比较烦,但好在起步早啊,而且贵在不断缓慢进步; DCOM一心要兼容COM,有些反人类,看起来就烦,用好了很难,写起来很烦; Java RMI、JAVA EJB,都是犯了相同的错,标准太烦了,对开发人员太不友好了。 WebService是看起来容易,用好了很难,写起来很烦;但同时代其他协议都是看起来就很难,所以胜出了,在一段时间内大行其道; 后来REST出现了,看起来容易,学起来容易,用起来也很容易。轻松将WebService挑落马下。 再看现在的Dubbo、Thrift、gRPC等,使用都相对简单,容易上手,开发者友好。 WCF有些小奇葩,很多想法很好,就是重了些,管得有些多,配置有些烦,如果要更多的占领市场,就应该让其变得更容易使用才对,而且应该跨平台才行。反而倒是WebAPI感觉更有前途,至少使用复杂程度和Flask、SpringBoot在一个水平线。 说到底吧,RPC协议和框架,其最终用户就是开发。 一开始能解决用户需求就行,没有其他替代方案,能解决问题,开发前辈们就很开心。 但用着用着,开发感觉体验太差了,就会有新一代产品出来,替代掉之前的产品。 而且越是新的协议,就不能有大的学习成本,容易上手,功能强大。 不信的话,你看下新的手机,比30年前功能多了不知道多少,但哪里还要一本厚厚的说明书才能上手呢?2021-03-2918
- 小高继续打卡,日常追剧。2020-12-057
- 芋头这一节对RPC框架有比较全面的了解,之前接触过的Dubbo和Webservice 及听说过的gRPC、Thrift.这几年微服务确实发展快,17年那会掌握Dubbo框架已经算比较时髦。当时用的websevice服务的使用下来的缺点很明显,服务之间依赖严重,serviceA依赖serviceB实现部分功能。 ,如果serviceB服务挂了,serviceA都启动不了,弊端很大。现在来来看这部分技术正在被SpringCloud 为代表的微服务组件所取代。这里有个疑问是Dubbo这种RPC框架未来的使用场景会在哪些方面呢?是否都可以被微服务取代。2021-03-201