1. 轻量级,简单易用。支持idl和手动编写协议两种方式。模拟函数式调用方式,更加符合rpc远程调用方式。linux
易修改易使用,已有的代码能够直接发布使用git
数据格式支持向下兼容,采用flatbuffer协议,兼容性更好,速度更快。github
支持多值返回特性,支持超时机制,类比grpc,thrift,dubbo快几倍甚至 几十倍。算法
支持snappy压缩算法,压缩速度,性能优越。ubuntu
支持管道数据压缩,动态数据压缩,请求式数据压缩,运用场景灵活普遍。windows
* 环境: linux, unix, windows, macOS
* 传输协议:flatbuffer for dlang(须要安装此依赖库, https://github.com/huntlabs/g...
* 压缩协议:snappy(须要安装此依赖库, https://github.com/google/sna...
* 开发语言:dlang
* 编译器:dub
* github:https://github.com/huntlabs/kiss-rpc
* 开发者笔记:[开发笔记](http://e222f542.wiz03.com/share/s/3y8Ll23R1kuW2E2Bv211ZNaJ3xapdS0TaQCk2ieqTL2UN24T))安全
IDL协议编写和使用说明:IDL协议详细说明](http://e222f542.wiz03.com/sha...服务器
数据压缩:使用google snappy压缩技术, 支持强制压缩和动态压缩方式,灵活的压缩方式可以运用于各类场景。网络
动态压缩技术: 当数据包大于200字节或者设定的阈值的时候,会压缩数据包,不然不压缩数据包,有助于空间的利用和性能的提高,response也会根据请求是否须要动态压缩数据。多线程
单请求压缩:对于单个request请求进行压缩,response也会根据请求的数据包压缩方式进行压缩。
管道压缩: 可对指定的管道进行数据包压缩。
数据加密: 使用多证书加密和单证书加密,更加安全。
负载均衡,反向代理:主动发现服务器,动态感知集群状态。
* 环境:ubuntu 16.04 lts(64位)
* 硬件:xeon cpu e3-1230@3.3GHz x 8
* 内存:8G
* 网络:localhost(本地环回)
单链接 100w QPS同步测试,耗时:20秒,平均每秒5w QPS
单链接 100w QPS异步测试, 耗时5秒,平均每秒20w QPS
1000并发, 100wQPS异步测试, 耗时:5秒,平均每秒QPS:20W
**
* 海量互联网业务系统只能依赖分布式架构来解决,而分布式开发的基石则是RPC;本文主要针对两个开源的RPC框架(gRPC、 Apache Thrift),以及配合GoLang、C++两个开发语言进行性能对比分析。
测试场景client, server都是单进程,长链接,在单次链接内发起1w(5w)次rpc调用,计算耗时;
client, server都是单进程,短链接,共发起1w(5w)次链接,每次链接单次RPC调用,计算耗时;
并发4个client进程,每一个进程长链接10w rpc,服务端单进程多线程(协程),计算耗时;
因为不一样语言,耗时统计存在误差,好比boost.timer在程序里计算出来的耗时明显偏小,因此统一使用linux命令time来计算耗时;
小结:
总体上看,长链接性能优于短链接,性能差距在两倍以上;
对比Go语言的两个RPC框架,Thrift性能明显优于gRPC,性能差距也在两倍以上;
对比Thrift框架下的的两种语言,长链接下Go 与C++的RPC性能基本在同一个量级,在短链接下,Go性能大概是C++的二倍;
对比Thrift&C++下的TSimpleServer与TNonblockingServer,在单进程客户端长链接的场景下,TNonblockingServer由于存在线程管理开销,性能较TSimpleServer差一些;但在短链接时,主要开销在链接创建上,线程池管理开销可忽略;
两套RPC框架,以及两大语言运行都很是稳定,5w次请求耗时约是1w次的5倍;