目录

 ● Dubbo

 ● Motan

 ● Thrift

 ● Grpc

上述四种流行RPC框架的对比

● Dubbo

    本来阿里2014年就不在维护Dubbo了，直到2017年9月份又恢复了维护，可能一来是用户量很多，哪怕是在不维护的情况下还是有很多的用户，二来是微服务比较火，比较看好微服务的方向。以下是Dubbo的架构模型（实线表示同步调用，虚线表示异步调用）：

   第1、2步：蓝色的箭头表示在服务初始化的时候做的工作，可以理解为服务提供者和消费者在启动的时候做的事情。在服务提供者启动时，服务提供者把服务注册到注册中心（比如说Zookeeper），消费者在启动的时候也会和注册中心打交道，订阅自己需要的服务。

第3步：注册中心会返回服务提供者的地址给消费者，如果服务提供者的地址有变化，注册中心会把变更通知到消费者。

第4步：服务消费者会从服务提供者地址列表中基于一些负载均衡算法，选择一个服务提供者进行调用，调用失败的时候会再选择另外一个服务提供者。

   消费者和提供者以及注册中心之间使用的是长连接，服务的消费者和提供者会在内存中累计服务调用的次数，并且定时将调用的信息发送到监控中心；消费者和提供者之间通信采用的是非阻塞I/O（即NIO）；Dubbo的序列化使用的是阿里修改过的hession序列化方式，Dubbo是基于java来进行开发的，所以也支持java的客户端和服务端。里边儿的服务注册、服务订阅、通知以及监控都是Dubbo为我们做好了的，有着比较完善的服务治理。

● Motan

    2016年5月份正式开源，号称是每天支撑了微博的千亿级别的调用量，它使用起来比较简单，通过Spring的配置，不需要额外的代码就可以拥有分布式的调用能力。以下为Motan的架构模型：

    Motan的服务提供者——RPC Server，服务调用方——RPC Client，服务注册中心——Registry，三个角色，和Dubbo类似。Server会向注册中心注册服务，Client使用服务需要先向注册中心Registry进行订阅，client根据Registry的返回列表与具体的Server建立连接，进行RPC通讯，当Server发生变更的时候，Registry也会同步变更，然后同步的通知到Client。

    服务的消费者和提供者进行调用的时候，默认使用的是Motan的协议，用hession进行序列化，motan也提供了服务治理的功能，包括服务的发现，服务的摘除、高可用以及负载均衡，Motan也是基于Java来开发的，即语言上只支持Java。

● Thrift

    2007年由Facebook开发的，2008年进入了Apache开源项目，它是跨语言的RPC框架。其架构图如下：

   从上图中可以看到，最开始 需要API负责定义一个文件，然后通过Thrift来生成对应的各种语言的代码，生成之后，服务的提供者和消费者都需要把这个代码引入进去，服务端把接口进行一个实现，消费者使用API的存根去直接调用提供者。

    目前支持的语言比较多，比如常见的C++、Java、Python、Ruby、C#、PHP等。Thrift属于C/S模式，它通过代码生成工具将接口定义的文件生成服务器端和客户端的代码，当然，服务端和客户端可以是不同语言的，从而实现了客户端和服务端之间跨语言的支持。传输的序列化也支持很多种，比如：二进制模式、压缩模式、JSON模式以及Debug模式，我们可以在开发的过程中使用Debug模式和JSON模式来方便的看到我们传输的数据，在线上环境使用二进制模式或压缩模式来提升性能。在通讯模式上也支持很多种，它支持阻塞的I/O和NIO，还有专门用来传输文件的传输方式。在线程模型上，它也支持很多种，比如简单的单线程模式、线程池模式、多线程使用非阻塞I/O模式。这样我们可以在不同的业务场景中使用更适合的技术来实现RPC调用。Thrift并没有服务治理相关的功能，消费者只能使用服务提供者IP和端口号来进行访问，如果要向Dubbo和Motan那样实现服务治理，需要我们自己把 服务提供者实现注册、消费者去注册中心寻找这个过程 实现。

● Grpc

    和Thrift类似，需要写API的定义文件，文件的格式是protobuf的，需要生成各个语言的接口，然后才能实现跨语言的调用，所以它和Thrift一样支持跨语言，Grpc的文件传输都是用的protobuf，protobuf是一个效率特别高（可以说是业界最高）的序列化方式，谷歌面向的应用是移动端的，所以它没有采用Socket，而是基于HTTP2（协议编码和传输机制的效率要低于传统的Socket）的一个协议标准。

   上述四种流行RPC框架的对比