轉載自：https://colobu.com/2020/01/21/benchmark-2019-spring-of-popular-rpc-frameworks/
叙述
自人類文明以來，人類交流的方式就在不斷的變化，從最早的結繩記事、到烽火傳消息，從飛鴿傳書到驿站飛馬，從電報電話到網際網路傳送，交流的速度越來越快，資訊傳輸量越來越大。通過交流，人們編寫程式的時候就可以實作遠端方法調用，就像調用本地方法一樣便捷，是以RPC技術也在發展，尤其近幾年的微服務的大力推廣，RPC技術應用的越來越廣泛。
本質上講，鴻雁傳書也是一種RPC調用，隻不過速度比較慢，可靠性不是那麼高，現在RPC遠端方法調用一般直接使用TCP或者HTTP實作。 HTTP的服務暴露方式比較簡單，可以采用RESTful的方式提供通用的API, 用戶端的調用也比較簡單。直接TCP上實作的RPC遠端方法調用性能優良，可以用在高吞吐低延遲的場景上。
近日江湖百曉生兄提供了一份最新的
2020 RPC架構性能比較
文檔。
當然，作為一份榜單，必然會有争議，争議無外乎以下幾種：
- 利益相關者争議： 因為我是rpcx作者，會不會特意給rpcx開小竈。答案是沒有，因為測試代碼明明白白的開源出來了，可以供大家review
- 測試不全面：這是對的，沒有一份測試滿足所有的測試場景。有些場景是CPU敏感的、有些場景是IO敏感的，有些是記憶體敏感的業務，測試不太可能測試的各個方面，是以這一份測試隻是針對一個場景的測試：通過序列化/反序列化一個比較大的protobuf，來模拟業務的處理。（代碼中有delay參數，可以用來模拟耗時較長的服務，但是看這次的測試結果，這個場景沒有覆寫。CPU耗時大家可擴充以下，通過計算階乘或者挖礦的方式模拟CPU的消耗)
- 測試結果不全面：這次測試隻采集了并發數和耗時(latency), 并沒有采集伺服器和用戶端的CPU/記憶體占用等名額。
這次測試的隻是架構的性能，在評估一個架構的時候，還需要考慮架構的功能、易用性、活躍度等各個方面。
以上是測試背景。
測試環境
測試資料
payload
所有架構傳輸的資料都是在用戶端序列化好的protobuf對象，并使用一些測試資料填充這個對象。序列化後的payload大小是581個位元組，每個架構都會增加一些額外的資料，大小不等。收到的資料類型，并且需要反序列化。
服務端收到這個資料後會反序列化，設定幾個字段後再序列化傳回用戶端。
可以看出業務處理主要是對象的序列化和反序列化，這些操作對每一個架構都是一樣的。
測試結果
吞吐率比較
耗時比較