微服务 Spring Cloud 8，开源RPC框架如何选型？

在这里插入图片描述

- 一、开源RPC框架有哪些？
- - 1、跟语言平台绑定的开源RPC框架
  - 2、跨语言平台的开源RPC框架
- 二、跟语言平台绑定的开源RPC框架 -- Dubbo
- - 1、Dubbo的架构主要包含四个角色
  - 2、Dubbo的调用框架是如何实现的？
- 三、如何选择？
- 四、跨语言平台的开源RPC框架 -- gRPC
- 五、跨语言平台的开源RPC框架 -- Thrift
- 六、对比选型
- 七、总结
- 微服务 Spring Cloud系列

大家好，我是哪吒。

一、开源RPC框架有哪些？

1、跟语言平台绑定的开源RPC框架

Dubbo：国内最早开源的RPC框架，由阿里巴巴公司开发并于2011年末对外开源，仅支持Java语言。
Motan：微博内部使用的RPC框架，于2016年对外开源，仅支持Java语言。
Tars：腾讯内部使用的RPC框架，于2017年对外开源，仅支持C++语言。
Spring Cloud：国外Pivotal公司2014年对外开源的RPC框架，仅支持Java语言。

2、跨语言平台的开源RPC框架

gRPC：Google于2015年对外开源的跨语言RPC框架，支持多种语言。
Thrift：最初是由Facebook开发的内部系统跨语言的RPC框架，2007年贡献给了Apache基金，成为Apache开源项目之一，支持多种语言。

如果你的业务场景仅仅局限于一种语言的话，可以选择跟语言绑定的RPC框架中的一种；如果涉及多个语言平台之间的相互调用，就应该选择跨语言平台的RPC框架。

二、跟语言平台绑定的开源RPC框架 – Dubbo

1、Dubbo的架构主要包含四个角色

服务提供者（Provider）：提供服务的实体，通常是一个具体的业务服务实现类。
服务消费者（Consumer）：调用远程服务的实体，通常是一个具体的业务服务调用方。
注册中心（Registry）：负责服务的注册与发现，通常是一个高可用的分布式服务注册中心。
监控中心（Monitor）：收集服务调用的统计信息，通常用于监控服务调用的性能、质量等。

在这里插入图片描述

具体的交互流程是Consumer一端通过注册中心获取到Provider节点后，通过Dubbo的客户端SDK与Provider建立连接，并发起调用。Provider一端通过Dubbo的服务端SDK接收到Consumer的请求，处理后再把结果返回给Consumer。

可以看出服务消费者和服务提供者都需要引入Dubbo的SDK才来完成RPC调用，因为Dubbo本身是采用Java语言实现的，所以要求服务消费者和服务提供者也都必须采用Java语言实现才可以应用。

2、Dubbo的调用框架是如何实现的？

Dubbo的调用框架的实现主要基于以下几个核心组件和服务治理策略：

服务注册与发现：Dubbo通过注册中心进行服务的注册与发现。服务提供者在启动时，将自己的元数据（如服务IP、Port等）注册到注册中心。服务消费者在启动时，向注册中心订阅服务提供者的元数据。注册中心将服务提供者地址列表提供给消费者，并在数据变更时推送给订阅的消费者。
RPC调用：在获取服务提供者的元数据后，服务消费者可以发起RPC调用。Dubbo的RPC层负责建立网络通信连接，实现服务的远程调用。同时，RPC层还支持负载均衡、容灾和集群功能，以确保调用的稳定性和性能。
服务监控：在RPC调用前后，Dubbo会向监控中心上报统计信息，如并发数、调用接口等。这些信息可以用于服务的性能监控和调优。

此外，Dubbo的实现还采用了分层的思想，每层负责不同的职责，使得用户可以基于Dubbo框架进行二次开发，扩展其功能。同时，Dubbo还支持与Spring框架的无缝集成，使得用户可以更方便地将其应用于实际的业务场景中。

三、如何选择？

SpringCloud提供了服务注册组件、配置中心组件、负载均衡组件、断路器组件、分布式消息追踪组件等一系列组件；
Dubbo只提供了最基础的RPC框架的功能，其他微服务组件都需要自己去实现。
Spring Cloud的RPC通信采用了HTTP协议，相比Dubbo所采用的私有协议来说，在高并发的通信场景下，性能相对要差一些，所以对性能有苛刻要求的情况下，可以考虑Dubbo。

因此，在堆性能没有苛刻要求的场景下，都会选择SpringCloud。

四、跨语言平台的开源RPC框架 – gRPC

gRPC通过IDL（Interface Definition Language）文件定义服务接口的参数和返回值类型，然后通过代码生成程序生成服务端和客户端的具体实现代码，这样在gRPC里，客户端应用可以像调用本地对象一样调用另一台服务器上对应的方法。

在这里插入图片描述
它的主要特性包括三个方面。

通信协议采用了HTTP/2，HTTP/2提供了连接复用、双向流、服务器推送、请求优先级、首部压缩等机制，在通信过程中可以节省带宽、降低TCP连接次数、节省CPU、尤其对移动端来说，可以帮助延长电池寿命。
IDL使用了ProtoBuf，ProtoBuf是由Google开发的一种数据序列化协议，它的压缩和传输效率极高，语法也简单，所以被广泛应用在数据存储和通信协议上。
多语言支持，能够基于多种语言自动生成对应语言的客户端和服务端的代码。

五、跨语言平台的开源RPC框架 – Thrift

Thrift是一种轻量级的跨语言RPC通信方案，支持多达25种编程语言。为了支持多种语言，跟gRPC一样，Thrift也有一套自己的接口定义语言IDL，可以通过代码生成器，生成各种编程语言的Client端和Server端的SDK代码，这样就保证了不同语言之间可以相互通信。它的架构图可以用下图来描述。

在这里插入图片描述
从这张图上可以看出Thrift RPC框架的特性。

支持多种序列化格式：如Binary、Compact、JSON、Multiplexed等。
支持多种通信方式：如Socket、Framed、File、Memory、zlib等。
服务端支持多种处理方式：如Simple 、Thread Pool、Non-Blocking等。

六、对比选型

那么涉及跨语言的服务调用场景，到底该选择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调用。

Dubbo在去年年底又重启了维护，并且宣称要引入Sidecar组件来构建Dubbo Mesh提供多语言支持。
Motan也在去年对外开源了其内部的Sidecar组件：Motan-go，目前支持PHP、Java语言之间的相互调用。
Spring Cloud也提供了Sidecar组件spring-cloud-netflix-sideca，可以让其他语言也可以使用Spring Cloud的组件。

所以未来语言不会成为使用上面这几种RPC框架的约束，而gRPC和Thrift虽然支持跨语言的RPC调用，但是因为它们只提供了最基本的RPC框架功能，缺乏一系列配套的服务化组件和服务治理功能的支撑，所以使用它们作为跨语言调用的RPC框架，就需要自己考虑注册中心、熔断、限流、监控、分布式追踪等功能的实现，不过好在大多数功能都有开源实现，可以直接采用。