net框架平臺下RPC框架選型
近期開始研究分布式架構，會涉及到一個最核心的組件：RPC（Remote Procedure Call Protocol）。這個東西的穩定性與性能，直接決定了分布式架構系統的好壞。RPC技術，我們的產品中其實早就已經應用。但是產品中經常出現訪問失敗等錯誤，在沒有細致研究的情況下，大家懷疑是選用的RPC組件不穩定引起。今天也借這個機會給這個組件正名一下吧。
選型的思路很簡單，先baidu找業界最有名的RPC框架，看各種牛人的的對比分析，然後到github上搜索排名和評價靠前的組件，確定一個選型的大致範圍，然後進行一輪測試。當然，我們是有特性要求的：
1.最好支持TCP、HTTP兩種通訊協議。即使不支持也可以擴展，或者集成兩種RPC組件。
2.最好支持異步、同步兩種調用方式。
3.性能要盡可能的好。
4.通訊層最好要有失敗重試的機制或者類似的補償機制。
5..net技術路線。
經過篩選，大致確定了5個組件：Thrift、gRPC、Halibut、SCS、Shuttler.net（這是按照知名度排序的）。前兩個大家都很熟，後3個比較陌生吧。其中Halibut是Octopus deploy產品中的組件，已經在各種場景中驗證過了，對其也寄予一定的厚望（Octopus deploy是自動化部署的產品，微軟也在用，是個好東西）。
我的測試方法有些特殊，分為本機和局域網兩種網絡環境測試（我們的局域網是無線。300M帶寬？好像是！）。每種環境在細分為兩種場景：無限制、加入10MS延遲和1%丟包。
Thrift情況如下：
單連接 本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 79.1 0.0 10879.9 0.0 3816.1 0.0 8221.7 0.0 第二次測試 83.1 0.0 10613.9 0.0 3410.8 0.0 9189.4 0.0 第三次測試 80.6 0.0 12221.1 0.0 3726.1 0.0 9662.5 0.0 平均 80.9 0.0 11238.3 0.0 3651.0 0.0 9024.5 0.0
每次訪問
新建連接本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 81.6 0.0 19414.9 0.0 3298.6 0.0 13124.0 0.0 第二次測試 83.1 0.0 22372.1 0.0 3200.1 0.0 13680.2 0.0 第三次測試 82.1 0.0 21589.0 0.0 3958.9 0.0 15757.5 0.0 平均 82.2 0.0 21125.3 0.0 3485.9 0.0 14187.2 0.0
gRPC情況如下：
單連接 本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 200.8 0.0 16899.8 0.0 3990.4 0.0 9199.9 0.0 第二次測試 200.2 0.0 18200.1 0.0 4099.9 0.0 9200.1 0.0 第三次測試 200.4 0.0 16801.0 0.0 3800.2 0.0 9599.6 0.0 平均 200.5 0.0 17300.3 0.0 3963.5 0.0 9333.2 0.0
每次訪問
新建連接本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 20522.1 0.0 66560.1 0.0 41991.2 0.0 38106.0 0.0 第二次測試 20713.1 0.0 51348.0 0.0 40517.2 0.0 41988.8 0.0 第三次測試 20751.5 0.0 56108.4 0.0 42404.0 0.0 52477.6 0.0 平均 20662.2 0.0 58005.5 0.0 41637.5 0.0 44190.8 0.0
Halibut情況如下：
單連接 本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 75.1 0.0 15593.3 0.0 1056.6 0.0 13457.4 0.0 第二次測試 83.1 0.0 16775.7 0.0 775.9 0.0 9023.0 0.0 第三次測試 81.6 0.0 16857.4 0.0 891.4 0.0 10739.2 0.0 平均 79.9 0.0 16408.8 0.0 908.0 0.0 11073.2 0.0
每次訪問
新建連接本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 1237.4 0.0 46431.4 0.0 17210.6 0.0 25839.7 0.0 第二次測試 1237.9 0.0 44134.8 0.0 10440.8 0.0 34425.2 0.0 第三次測試 1232.4 0.0 43727.5 0.0 22320.3 0.0 26654.1 0.0 平均 1235.9 0.0 44764.6 0.0 16657.2 0.0 28973.0 0.0
SCS情況如下：
單連接 本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 67.0 0.0 15465.6 0.0 685.6 0.0 7179.0 0.0 第二次測試 68.0 0.0 18709.0 0.0 819.1 0.0 11511.9 0.0 第三次測試 69.0 0.0 14791.2 0.0 703.3 0.0 7319.3 0.0 平均 68.0 0.0 16321.9 0.0 736.0 0.0 8670.1 0.0
每次訪問
新建連接本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 74.1 0.0 20980.5 0.0 757.4 0.0 8978.9 0.0 第二次測試 70.0 0.0 22169.9 0.0 770.6 0.0 10990.9 0.0 第三次測試 77.6 0.0 16133.7 0.0 1019.4 0.0 14943.6 0.0 平均 73.9 0.0 19761.4 0.0 849.1 0.0 11637.8 0.0
Shuttler.net情況如下：
Shuttler是支持TCP和HTTP兩種協議的，但是TCP的錯誤太多了，我就不貼了
每次訪問
新建連接（HTTP）本機調用：100次耗時（毫秒） 局域網調用：100次耗時（毫秒） 無限制 丟包率：1%,延遲：10ms 無限制 丟包率：1%,延遲：10ms 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 響應時間 失敗次數 第一次測試 46.5 0.0 46950.1 0.0 3062.8 0.0 37665.3 0.0 第二次測試 40.5 0.0 42380.0 0.0 2016.0 0.0 42242.0 0.0 第三次測試 39.5 0.0 47681.7 0.0 2080.4 0.0 35739.7 0.0 平均 42.2 0.0 45670.6 0.0 2386.4 0.0 38549.0 0.0
實際環境中，肯定是局域網環境，所以我把局域網部分的結果統計了一下。因為失敗次數都為0，所以只統計了耗時。
項目(100次調用響應時間MS，局域網環境) Thrift Thrift（Teld） gRPC Halibut SCS Shuttler.net 單鏈接 無限制 3651.0 3774.8 3963.5 908.0 736.0 0.0 丟包率：1%,延遲：10ms 9024.5 9586.7 9333.2 11073.2 8670.1 0.0 多鏈接 無限制 3485.9 3777.6 41637.5 16657.2 849.1 2386.4 丟包率：1%,延遲：10ms 14187.2 9154.8 44190.8 28973.0 11637.8 38549.0
通過統計結果來看，SCS有三項第一，一項第二。特別是沒有加入丟包和網絡延遲的情況下，性能表現非常好。下一步對它和Thrift進行深入的研究。
net框架平臺下RPC框架選型