高性能异步RPC框架 kiss-rpc-flatbuffer介绍和测试

kiss-rpc特性:

1. 轻量级，简单易用。支持idl和手动编写协议两种方式。模拟函数式调用方式，更加符合rpc远程调用方式。
2. 易修改易使用，已有的代码可以直接发布使用
3. 数据格式支持向下兼容,采用flatbuffer协议，兼容性更好，速度更快。
4. 支持多值返回特性，支持超时机制，类比grpc,thrift,dubbo快几倍甚至 几十倍。
5. 支持snappy压缩算法，压缩速度，性能优越。
6. 支持管道数据压缩，动态数据压缩，请求式数据压缩，运用场景灵活广泛。

开发环境

 * 环境: linux, unix, windows, macOS
 * 传输协议:flatbuffer for dlang(需要安装此依赖库, https://github.com/huntlabs/google-flatbuffers)
 * 压缩协议:snappy(需要安装此依赖库, https://github.com/google/snappy)
 * 开发语言：dlang
 * 编译器:dub
 * github:https://github.com/huntlabs/kiss-rpc
 * 开发者笔记:[开发笔记](http://e222f542.wiz03.com/share/s/3y8Ll23R1kuW2E2Bv211ZNaJ0CD40M16VAzs2tpsxy2bq6Ha)](http://e222f542.wiz03.com/share/s/3y8Ll23R1kuW2E2Bv211ZNaJ3xapdS0TaQCk2ieqTL2UN24T))

IDL介绍和使用说明:

• IDL协议编写和使用说明：IDL协议详细说明](http://e222f542.wiz03.com/share/s/3y8Ll23R1kuW2E2Bv211ZNaJ02PboQ0P_kXV2XlO0z3W9I69))

关于kiss-rpc使用的压缩方式

• 数据压缩:使用google snappy压缩技术, 支持强制压缩和动态压缩方式，灵活的压缩方式能够运用于各种场景。
• 动态压缩技术: 当数据包大于200字节或者设定的阈值的时候，会压缩数据包，否则不压缩数据包，有助于空间的利用和性能的提升，response也会根据请求是否需要动态压缩数据。
• 单请求压缩：对于单个request请求进行压缩，response也会根据请求的数据包压缩方式进行压缩。
• 管道压缩: 可对指定的管道进行数据包压缩。

待开发

• 数据加密: 使用多证书加密和单证书加密，更加安全。
• 负载均衡，反向代理：主动发现服务器，动态感知集群状态。

kiss rpc 同步和异步测试:

 * 环境：ubuntu 16.04 lts(64位)
 * 硬件：xeon cpu [email protected] x 8
 * 内存：8G
 * 网络:localhost(本地环回)

kiss rpc flatbuffer版本测试:

• 单连接 100w QPS同步测试，耗时:20秒，平均每秒5w QPS
• 单连接 100w QPS异步测试,   耗时5秒，平均每秒20w QPS

1000并发异步测试

• 1000并发, 100wQPS异步测试, 耗时:5秒，平均每秒QPS:20W

其他rpc性能对比 测试:(http://blog.csdn.net/jek123456/article/details/53395206)

**
* 海量互联网业务系统只能依赖分布式架构来解决，而分布式开发的基石则是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来计算耗时；

1.单进程下，长短连接，两个RPC框架和两大语言对比

• 小结：
  整体上看，长连接性能优于短连接，性能差距在两倍以上；
  对比Go语言的两个RPC框架，Thrift性能明显优于gRPC，性能差距也在两倍以上；
  对比Thrift框架下的的两种语言，长连接下Go 与C++的RPC性能基本在同一个量级，在短连接下，Go性能大概是C++的二倍；
  对比Thrift&C++下的TSimpleServer与TNonblockingServer，在单进程客户端长连接的场景下，TNonblockingServer因为存在线程管理开销，性能较TSimpleServer差一些；但在短连接时，主要开销在连接建立上，线程池管理开销可忽略；
  两套RPC框架，以及两大语言运行都非常稳定，5w次请求耗时约是1w次的5倍；

2.多进程（线程，协程）下，两大RPC框架和两大语言对比