大家好,我是哪吒。
如果你的业务场景仅仅局限于一种语言的话,可以选择跟语言绑定的RPC框架中的一种;如果涉及多个语言平台之间的相互调用,就应该选择跨语言平台的RPC框架。
具体的交互流程是Consumer一端通过注册中心获取到Provider节点后,通过Dubbo的客户端SDK与Provider建立连接,并发起调用。Provider一端通过Dubbo的服务端SDK接收到Consumer的请求,处理后再把结果返回给Consumer。
可以看出服务消费者和服务提供者都需要引入Dubbo的SDK才来完成RPC调用,因为Dubbo本身是采用Java语言实现的,所以要求服务消费者和服务提供者也都必须采用Java语言实现才可以应用。
Dubbo的调用框架的实现主要基于以下几个核心组件和服务治理策略:
此外,Dubbo的实现还采用了分层的思想,每层负责不同的职责,使得用户可以基于Dubbo框架进行二次开发,扩展其功能。同时,Dubbo还支持与Spring框架的无缝集成,使得用户可以更方便地将其应用于实际的业务场景中。
因此,在堆性能没有苛刻要求的场景下,都会选择SpringCloud。
gRPC通过IDL(Interface Definition Language)文件定义服务接口的参数和返回值类型,然后通过代码生成程序生成服务端和客户端的具体实现代码,这样在gRPC里,客户端应用可以像调用本地对象一样调用另一台服务器上对应的方法。
它的主要特性包括三个方面。
Thrift是一种轻量级的跨语言RPC通信方案,支持多达25种编程语言。为了支持多种语言,跟gRPC一样,Thrift也有一套自己的接口定义语言IDL,可以通过代码生成器,生成各种编程语言的Client端和Server端的SDK代码,这样就保证了不同语言之间可以相互通信。它的架构图可以用下图来描述。
从这张图上可以看出Thrift RPC框架的特性。
那么涉及跨语言的服务调用场景,到底该选择gRPC还是Thrift呢?
从成熟度上来讲,Thrift因为诞生的时间要早于gRPC,所以使用的范围要高于gRPC,在HBase、Hadoop、Scribe、Cassandra等许多开源组件中都得到了广泛地应用。而且Thrift支持多达25种语言,这要比gRPC支持的语言更多,所以如果遇到gRPC不支持的语言场景下,选择Thrift更合适。
但gRPC作为后起之秀,因为采用了HTTP/2作为通信协议、ProtoBuf作为数据序列化格式,在移动端设备的应用以及对传输带宽比较敏感的场景下具有很大的优势,而且开发文档丰富,根据ProtoBuf文件生成的代码要比Thrift更简洁一些,从使用难易程度上更占优势,所以如果使用的语言平台gRPC支持的话,建议还是采用gRPC比较好。
以上就是我对几种使用最广泛的开源RPC框架的选型建议,也是基于它们目前现状所作出的判断,从长远来看,支持多语言是RPC框架未来的发展趋势。正是基于此判断,各个RPC框架都提供了Sidecar组件来支持多语言平台之间的RPC调用。
所以未来语言不会成为使用上面这几种RPC框架的约束,而gRPC和Thrift虽然支持跨语言的RPC调用,但是因为它们只提供了最基本的RPC框架功能,缺乏一系列配套的服务化组件和服务治理功能的支撑,所以使用它们作为跨语言调用的RPC框架,就需要自己考虑注册中心、熔断、限流、监控、分布式追踪等功能的实现,不过好在大多数功能都有开源实现,可以直接采用。
微服务 Spring Cloud 1,服务如何拆分?使用微服务的注意事项?
微服务 Spring Cloud 2,一文讲透微服务核心架构(注册中心、服务通信、服务监控、服务追踪、服务治理)
微服务 Spring Cloud 3,如何对微服务进行有效的监控?
微服务 Spring Cloud 4,分布式系统如何进行数据分区
微服务 Spring Cloud 5,一图说透Spring Cloud微服务架构
微服务 Spring Cloud 6,用了这么多年Docker容器,殊不知你还有这么多弯弯绕
微服务 Spring Cloud 7,Nacos配置中心的Pull原理,附源码
🏆哪吒多年工作总结:Java学习路线总结,搬砖工逆袭Java架构师。
华为OD机试 2023B卷题库疯狂收录中,刷题点这里
刷的越多,抽中的概率越大,每一题都有详细的答题思路、详细的代码注释、样例测试,发现新题目,随时更新,全天CSDN在线答疑。