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 e3-1230@3.3GHz 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框架和两大语言对比
