kiss-rpc特性:
- 輕量級(jí)，簡單易用。支持idl和手動(dòng)編寫協(xié)議兩種方式。模擬函數(shù)式調(diào)用方式，更加符合rpc遠(yuǎn)程調(diào)用方式。
- 易修改易使用，已有的代碼可以直接發(fā)布使用
- 數(shù)據(jù)格式支持向下兼容,采用flatbuffer協(xié)議，兼容性更好，速度更快。
- 支持多值返回特性，支持超時(shí)機(jī)制，類比grpc,thrift,dubbo快幾倍甚至 幾十倍。
- 支持snappy壓縮算法，壓縮速度，性能優(yōu)越。
- 支持管道數(shù)據(jù)壓縮，動(dòng)態(tài)數(shù)據(jù)壓縮，請求式數(shù)據(jù)壓縮，運(yùn)用場景靈活廣泛。
開發(fā)環(huán)境
- 環(huán)境: linux, unix, windows, macOS
- 傳輸協(xié)議:flatbuffer for dlang(需要安裝此依賴庫, https://github.com/huntlabs/google-flatbuffers)
- 壓縮協(xié)議:snappy(需要安裝此依賴庫, https://github.com/google/snappy)
- 開發(fā)語言：dlang
- 編譯器:dub
- github:https://github.com/huntlabs/kiss-rpc
- 開發(fā)者筆記:開發(fā)筆記](http://e222f542.wiz03.com/share/s/3y8Ll23R1kuW2E2Bv211ZNaJ3xapdS0TaQCk2ieqTL2UN24T))
IDL介紹和使用說明:
- IDL協(xié)議編寫和使用說明：IDL協(xié)議詳細(xì)說明](http://e222f542.wiz03.com/share/s/3y8Ll23R1kuW2E2Bv211ZNaJ02PboQ0P_kXV2XlO0z3W9I69))
關(guān)于kiss-rpc使用的壓縮方式
- 數(shù)據(jù)壓縮:使用google snappy壓縮技術(shù), 支持強(qiáng)制壓縮和動(dòng)態(tài)壓縮方式，靈活的壓縮方式能夠運(yùn)用于各種場景。
- 動(dòng)態(tài)壓縮技術(shù): 當(dāng)數(shù)據(jù)包大于200字節(jié)或者設(shè)定的閾值的時(shí)候，會(huì)壓縮數(shù)據(jù)包，否則不壓縮數(shù)據(jù)包，有助于空間的利用和性能的提升，response也會(huì)根據(jù)請求是否需要?jiǎng)討B(tài)壓縮數(shù)據(jù)。
- 單請求壓縮：對于單個(gè)request請求進(jìn)行壓縮，response也會(huì)根據(jù)請求的數(shù)據(jù)包壓縮方式進(jìn)行壓縮。
- 管道壓縮: 可對指定的管道進(jìn)行數(shù)據(jù)包壓縮。
待開發(fā)
- 數(shù)據(jù)加密: 使用多證書加密和單證書加密，更加安全。
- 負(fù)載均衡，反向代理：主動(dòng)發(fā)現(xiàn)服務(wù)器，動(dòng)態(tài)感知集群狀態(tài)。
kiss rpc 同步和異步測試:
- 環(huán)境：ubuntu 16.04 lts(64位)
- 硬件：xeon cpu e3-1230@3.3GHz x 8
- 內(nèi)存：8G
- 網(wǎng)絡(luò):localhost(本地環(huán)回)
59582266.png
kiss rpc flatbuffer版本測試:
- 單連接 100w QPS同步測試，耗時(shí):20秒，平均每秒5w QPS
- 單連接 100w QPS異步測試, 耗時(shí)5秒，平均每秒20w QPS
59682393.png
1000并發(fā)異步測試
- 1000并發(fā), 100wQPS異步測試, 耗時(shí):5秒，平均每秒QPS:20W
59698927.png
其他rpc性能對比 測試:(http://blog.csdn.net/jek123456/article/details/53395206)
**
** 海量互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)只能依賴分布式架構(gòu)來解決，而分布式開發(fā)的基石則是RPC；本文主要針對兩個(gè)開源的RPC框架（gRPC、 Apache Thrift），以及配合GoLang、C++兩個(gè)開發(fā)語言進(jìn)行性能對比分析。*
測試場景client, server都是單進(jìn)程，長連接，在單次連接內(nèi)發(fā)起1w（5w）次rpc調(diào)用，計(jì)算耗時(shí)；
client, server都是單進(jìn)程，短連接，共發(fā)起1w（5w）次連接，每次連接單次RPC調(diào)用，計(jì)算耗時(shí)；
并發(fā)4個(gè)client進(jìn)程，每個(gè)進(jìn)程長連接10w rpc，服務(wù)端單進(jìn)程多線程（協(xié)程），計(jì)算耗時(shí)；由于不同語言，耗時(shí)統(tǒng)計(jì)存在偏差，比如boost.timer在程序里計(jì)算出來的耗時(shí)明顯偏小，所以統(tǒng)一使用linux命令time來計(jì)算耗時(shí)；
1.單進(jìn)程下，長短連接，兩個(gè)RPC框架和兩大語言對比
1846c0c8-42c3-4b40-b188-d6c024f94d34.png
6bcf041a-1779-494b-a543-ec34dafa4069.png
- 小結(jié)：
整體上看，長連接性能優(yōu)于短連接，性能差距在兩倍以上；
對比Go語言的兩個(gè)RPC框架，Thrift性能明顯優(yōu)于gRPC，性能差距也在兩倍以上；
對比Thrift框架下的的兩種語言，長連接下Go 與C++的RPC性能基本在同一個(gè)量級(jí)，在短連接下，Go性能大概是C++的二倍；
對比Thrift&C++下的TSimpleServer與TNonblockingServer，在單進(jìn)程客戶端長連接的場景下，TNonblockingServer因?yàn)榇嬖诰€程管理開銷，性能較TSimpleServer差一些；但在短連接時(shí)，主要開銷在連接建立上，線程池管理開銷可忽略；
兩套R(shí)PC框架，以及兩大語言運(yùn)行都非常穩(wěn)定，5w次請求耗時(shí)約是1w次的5倍；
2.多進(jìn)程（線程，協(xié)程）下，兩大RPC框架和兩大語言對比
8b632946-5b54-4552-a1b2-898c5f1441cd.png
6fda7744-ec65-48b8-ae72-3ba2cb73b5c2.png
