配置方式

Motan：支持 Xml 配置和 Spring注解配置。

Dubbo：支持 Xml 配置 、 注解配置、 属性配置 、 API 配置

gRPC：只支持 API 配置 。

Xml 配置是用 xml 文件来配置协议 、 服务 、 注册中心等信息 ，这是 rpc 框架最常用的配置方式，也是最基本的配置方式；

属性配置 是 用 properties 文件来配置协议 、 服务 、 注册中心等信息 ， 和Xml 配置使用上异曲同工 ；

注释配置是声明 Annotation 用来指定需要解析的包名 ， 使用 spring-boot 启动服务 ，这是很多 RPC 所追求的，简化了我们代码的书写， Maton 也是最新版本才开始支持的；

API 配置是 Dubbo 的 API 配置仅用于 OpenAPI, ESB, Test, Mock 等系统集成 ， API 属性与配置项一对一。

服务通信协议

Motan：支持 Motan 协议，使用tcp 长连接模式，基于 netty通信。

Dubbo：支持 Dubbo 协议、 Rmi 协议、 Hessian 协议、 HTTP 协议、 WebService 协议、Dubbo Thrift 协议、Memcached 协议！

gRPC：支持 HTTP/2.0 协议，基于 Netty4.1.3 通信。

序列化

Motan：默认使用对 java 更友好的 hessian2 进行序列化，还支持 Json 格式。

Dubbo：Dubbo 协议缺省序列化为hessian2 ， rmi 协议缺省为java ， http 协议缺省为 json！

gRPC：说到序列化，独一无二的使用 ProtoBuf 来定义服务！

gRPC 使用的 ProtoBuf 是由 Google 开发的一种数据序列化协议，用户使用 .proto 文件定义服务，并支持定义多种类型的方法参数。 ProtoBuf 能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。不过，当前 gRPC 仅支持 Protobuf ，且不支持在浏览器中使用。但由于 gRPC 的设计能够支持支持多种数据格式，所以能够很容易实现对其他数据格式（如 XML 、 JSON 等）的支持。这就是我强大的 IDL 特性！

protobuf为什么比json性能高？

1. protobuf比json快多少？

快六倍，Protobuf是由Google开发的二进制格式，用于在不同服务之间序列化数据。是一种IDL（interface description language）语言

2. 为什么protobuf比json快？

对比json数据和protobuf数据格式可以知道

• 体积小-无需分隔符：TLV存储方式不需要分隔符（逗号，双引号等）就能分隔字段，减少了分隔符的使用
• 体积小-空字段省略：若字段没有被设置字段值，那么该字段序列化时的数据是完全不存在的，即不需要进行编码，而json会传key和空值的value
• 体积小-tag二进制表示：是用字段的数字值然后转换成二进制进行表示的，比json的key用字符串表示更加省空间
• 编解码快：tag的里面存储了字段的类型，可以直接知道value的长度，或者当value是字符串的时候，则用length存储了长度，可以直接从length后取n个字节就是value的值，而如果不知道value的长度，我们就必须要做字符串匹配

负载均衡

Motan：我支持 ActiveWeight 、Random 、 RoundRobin 、LocalFirst 、 Consistent 、ConfigurableWeight 。

Dubbo：支持 Random（随机） 、RoundRobin （轮询）、ConsistentHash（一致性hash） 、 LeastActive(低并发度优先)。

gRPC：提供了可插拔负载均衡器的机制。

这里让我来解释下每种负载均衡的模式吧 ！

ActiveWeight / LeastActive ：低并发度优先， referer 的某时刻的 call 数越小优先级越高。

LocalFirst ：本地服务优先获取策略。

Consistent ：一致性 Hash ，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

ConfigurableWeight ：权重可配置的负载均衡策略。

容错

Motan：支持 Failover 失效切换、Failfast 快速失败。

Dubbo：支持 Failover 、 Failfast 、Failsafe 、 Failback 、 Forking、 Broadcast 。

gRPC：具有 Failover 失效切换的容错策略。

简单介绍：

Failover ：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。

Failfast ：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failsafe ：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failback ：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

Forking ：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。

Broadcast ：广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

注册中心与服务发现

Motan：支持使用 Consul 作为注册中心、使用 Zookeeper 作为注册中心、点对点直连。

Dubbo：支持使用 Zookeeper 作为注册中心、使用 Redis 注册中心、使用 Multicast 注册中心、使用 Simple 注册中心。

gRPC：只能让用户自己扩展注册中心 。

性能

Motan：在高并发、高负载场景的场景下，平均 TPS 和平均响应时间依旧保持良好，具备在高压力场景下的高可用能力。

Dubbo：Dubbo2.0 相比较 Dubbo1.0（默认使用的都是 hessian2序列化）性能均有提升。如对性能有更高要求可以使用dubbo 序列化，由其是在处理复杂对象时。 Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议。

gRPC：采用的是 ProtoBuf 序列化协议 ， ProtoBuf 与其他协议的性能对比 ，非常明显 的ProtoBuf 要远远优于其他 。

3、RPC框架的才艺角逐

Motan ：通过 spring 配置方式集成，无需额外编写代码即可为服务提供分布式调用能力完全不需要任何 xml 配置文件， Dubbo 的注解配置还需要配合 xml 文件的哦 。

Dubbo ：支持泛型调用 ，Dubbo 提供 GenericService 泛型调用接口 ， 让用户的调用更加灵活 。

Motan ： 明显支持负载均衡的模式我更多 。 我 拥有自定义动态负载均衡、跨机房流量调整等高级服务调度能力。

Dubbo ：成熟度更高的我在健壮性和伸缩性上还能比你们差么？让我来一一例举。 说到健壮性 ，监控中心宕掉不影响使用，只是丢失部分采样数据；数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务；注册中心对等集群，任意一台宕掉后，将自动切换到另一台；注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯；服务提供者无状态，任意一台宕掉后，不影响使用；服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。至于伸缩性，注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心；服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者。

gRPC ： 哼 ！ 本宝宝支持 服务的跨语言调用，目前所支持语言类型有 C++ 、 JAVA 、 GO 、 Python 、 Ruby 、 Node.js 、 Android 、 C# 、 PHP 、 Objective-C

4、RPC框架的终极PK