2 个回答
-
| 2017-10-09 07:01:31 广告
缺点:目前版本来说实测性能肯定是差thrift一截的(实测grpc0.8版本).应该就是缺点吧,虽然用了netty和protobuf
优点:采用HTTP2的好处在于,因为添加了头信息,可以方便在框架层面对调用做拦截和控制(比如说限流,调用链分析,安全认证等)
而且http2为标准协议,也方便以后扩展兼容其它调用端
不过目前的grpc虽然支持了拦截,但是Header信息和消息体是分离的,而且暂时没法控制方法执行与否,所以很多功能还不能实现
(主要是没能从protobuf层面解决Header的问题)
另外,使用grpc既要安装protobuf又要使用maven或gradle的生成xxxGRPC的插件,实在麻烦,而且
client_to_server
client_to_server_streaming
server_to_client_streaming
bidirectional_streaming
几类调用方式实现的API也过于繁琐
所以综合起来目前我们当协调的分布式服务框架里使的还是协调实现的infogen-rpc框架，如果后面的release版本确实好用或许会换回来吧，毕竟grpc的多语言还是做得不错本问答由匿名用户提供
-
| 2017-10-09 06:50:58 广告
我们今年在项目中正式引入了 gRPC，当时只是为了找一个 Protocol Buffer 的 RPC 库，因此选择的 gRPC。优点最主要的是支持 Protocol Buffer 已被证明是一个很高效的序列化技术，再就是支持 HTTP 2.0 标准化的协议，这一点在产品应用中是非常重要的。
缺点嘛，我看有人进行了一些性能上的测试说是比 Thrift 要慢，其实不完全，我们一开始测试的时候 Server 端是放在 OS X 系统上的，运行起来的确慢很多，大约一次调用 40ms 上下，后来经过调查我们发现 gRPC 的同步调用与 Nagle's algorithm 会产生冲突，虽然 gRPC 在代码中加入了 TCP_NODELAY 这个 socketopt 但在 OS X 中是没有效果的。后来通过设定 net.inet.tcp.delayed_ack = 0 来解决，同样我们在 linux 下也设置了 net.ipv4.tcp_low_latency = 1，这样在 100M 带宽下一次同步调用的时间在 500us 以下。
而且在实际应用中，我们通过 streaming 调用来解决大量重复数据传输的问题，而不是通过反复的同步调用来传相同的数据，这样一次写入可以在 5us 左右。其实批量写入一直都是一个很好的解决性能问题的方法，这在 mongodb 的新版 mongo-cxx-driver 也是必需的，同步调用也是非常缓慢。我感觉 gRPC 相对于 Thrift 可能有一些 overhead 比如 http2.0 头，以及每次调用需要 ack，但这个 overhead 应该可以忽略，我猜测 Thrift 也是底层采用批量写入的方式或异步写入而不需要那么多的 ack 因此才会比较快吧。本问答由匿名用户提供
更多
- 盛刷pos机24小时400客服电话是多少？
- 33
- 3
- 盛刷pos机刷卡不到账怎么办？
- 75
- 3
- U米pos机客户服务电话是多少？
- 83
- 3
- 速刷pos机400客户服务电话是什么？
- 45
- 3
- 闪电宝pos机官方客服电话24小时客服电话
- 14
- 3
- 速刷pos机24小时在线客服热线
- 34
- 3
- 汇付天下pos机24小时在线客服热线
- 87
- 3
- 速刷pos机售后服务热线是什么？
- 89
- 3
- 速刷pos机24小时在线客服热线
- 87
- 3
- 闪电宝pos机全国24小时服务热线号码
- 62
- 3