漫谈grpc 4：grpc和其他rpc框架的横向对比，到底好在哪里？

1，什么是grpc

• gRpc 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本，分别是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持.
• gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。
• 参考：grpc官方文档英文版 和 grpc官方文档中文版

2，为什么我们要用grpc

• 生态好：背靠Google。还有比如nginx也对grpc提供了支持，参考链接
• 跨语言：跨语言，且自动生成sdk
• 性能高：比如protobuf性能高过json, 比如http2.0性能高过http1.1
• 强类型：编译器就给你解决了很大一部分问题
• 流式处理（基于http2.0）：支持客户端流式，服务端流式，双向流式

3，grpc 的优点是怎么实现的

3.1 grpc性能高：protobuf为什么比json性能高？

1，什么是protobuf？

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

2，他比json快多少？

• 快六倍，参考链接

3，为什么protobuf比json快？

• protobuf的二进制数据流和json数据流如下图

• 

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

3.2 grpc性能高：http2.0为什么比http1.1性能高？

1，多路复用

• http2.0和http 1. 还有 http1.1pipling的对比*
  • 示意图

  • 

  • http/1.* ：一次请求，一个响应，建立一个连接用完关闭，每一个请求都要建立一个连接
  • http1.1 pipeling: Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞
  • http2: 多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行
• grpc 多路复用还有哪些优点 - 减少了tcp的连接，降低了服务端和客户端对于内存，cpu等的压力 - 减少了tcp的连接，保证了不频繁触发tcp重新建立，这样就不会频繁有慢启动 - 减少了tcp的连接，使网络拥塞情况得以改善
• 为什么http/1.1不能实现多路复用而http2.0可以？ - 因为http/1.1传输是用的文本，而http2.0用的是二进制分帧传输

2, 头部压缩

• 固定字段压缩：http可以通过http对body进行gzip压缩，这样可以节省带宽，但是报文中header也有很多字段没有进行压缩，比如cookie， user agent accept，这些有必要进行压缩
• 避免重复：大量请求和响应的报文里面又很多字段值是重复的，所以有必要避免重复性
• 编码改进：字段是ascii编码，效率低，改成二进制编码可以提高
• 以上通过HPACK算法来进行实现，算法主要包含三个部分
  • 静态字典：将常用的header字段整成字典,比如{":method":"GET"} 就可以用单个数字 2来表示
  • 动态字典：没有在静态字典里面的一些头部字段，则用动态字典
  • Huffman 编码： 压缩编码

3, 二进制分帧

• 在二进制分帧层上，HTTP 2.0 会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码 ，其中HTTP1.x的首部信息会被封装到Headers帧，而我们的request body则封装到Data帧里面。
• 这样分帧以后这些帧就可以乱序发送，然后根据每个帧首部的流标识符号进行组装
• 对比http/1.1因为是基于文本以换行符分割每一条key：value则会有以下问题：
  • 一次只能处理一个请求或者响应，因为这种以分隔符分割消息的数据，在完成之前不能停止解析
  • 解析这种数据无法预知需要多少内存，会给服务端有很大压力

4, 服务器主动推送资源

• 由于支持服务器主动推送资源，则可以省去一部分请求。比如你需要两个文件1.html,1.css，如果是http1.0则需要请求两次，服务端返回两次。但是http2.0则可以客户端请求一次，然后服务端直接回吐两次

作者：蜗牛Snail
链接：https://juejin.cn/post/6969787751084654605
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

rpc框架横向比对

1、RPC 框架谁最美？

Hello，everybody！说到RPC框架，可能大家能想到一堆RPC开源框架，那么在微服务平台中，微服务间的服务调用，不可避免的会遇到一个问题，该选用哪一个RPC框架好呢？今天我们就请到三位RPC框架，来进行一场选美大赛，看看谁更适合微服务平台中的服务间调用。

大家好，我是Dubbo！我是阿里开源的分布式服务框架，最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。

大家好，我是Motan！我是微博开源的一套高性能、易于使用的分布式远程服务调用(RPC)框架。

大家好，我是gRPC！我是Google开源的一套面向移动和HTTP/2设计的，高性能的、通用的远程调用框架。

2、RPC框架的形体争美

• 配置方式

  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 特性！

• 负载均衡

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

  Dubbo：我可以支持 Random 、RoundRobin 、ConsistentHash 、 LeastActive。

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

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

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

• Random ：随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

• RoundRobin ：轮循，按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

• 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 的优势更大！

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

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

Motan ：对，我在功能上或许不是那么全面，但我更注重简单、易用以及在高并发高可用场景的使用。服务发现灵活支持多种配置管理组件，基于高并发高负载场景的高可用策略优化，良好的 SPI(Service Provider Interface) 扩展，详细的调用统计，灵活支持多种 RPC 传输协议。

Dubbo ：说了这么多你能支持泛型调用么？我能！ Dubbo 提供 GenericService 泛型调用接口 ， 让用户的调用更加灵活 。

Motan ： 我的 工程依赖只涉及核心 5 个模块，且可以按需依赖，不要的说舍弃就舍弃。看看你那么一堆堆的工程，啧啧啧 ……

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

Motan ： 额 ，是啊，我们不能，可是你有服务发现相关机制么？

Dubbo ：而且你的负载均衡和容错也太弱了 …..

gRPC ： 嘤嘤嘤 ……

4、RPC框架的终极PK

Dubbo作为阿里开源的分布式服务框架，实现高性能的 RPC 调用同时提供了丰富的管理功能，是一款应用广泛的优秀的 RPC 框架，但现在较少维护更新。如果你需要一款高成熟度的服务治理型的RPC框架，不如选我！

Motan作为微博的 Motan RPC 倾向于服务治理型，与 Dubbo 系列相比在功能上或许不是那么全，扩展实现也没有那么多，但如果你需要一款高性能轻量级易上手的RPC框架，记得选我！

gRPC作为google2015年才开源的跨语言调用型的RPC框架，侧重于服务的跨语言调用，能够支持大部分的语言进行语言无关的调用，非常适合多语言调用场景。如果你需要支持多语言，跨语言调用的RPC框架，选我吧！

看了以上三位RPC框架的选美比赛不知道大家是否都有了自己的选择。当然，现如今的市场中开源的RPC远远不止这三个，到底哪个才是你现在所需要的，这里也只是个参考，也是我们在微服务中RPC框架选择的一个方向，最终的选择还是要“因地制宜”。

作为踏入微服务行列的普元，我们的微服务平台采用了 Maton RPC 框架，高并发高负载 、轻量易维护 以及无需任何额外代码和配置的 Spring 注解配置，都是我们所需要的。当然我们也并不是完全满足于当前的Maton 功能，不过 Motan 良好的扩展机制，也给我们提供了便利，我们扩展了 ETCD 注册中心以及我们自己的日志记录方式，当然还有更多的贴合我们实际应用的改造。相信在每个正在寻找微服务交互的 RPC 框架的你们，经过反复的对比研究，也能找到你们心中的那个唯一！