這是我參與8月更文挑戰的第14天，活動詳情查看：8月更文挑戰web

📢歡迎點贊：👍 收藏 ⭐留言 📝 若有錯誤敬請指正，賜人玫瑰，手留餘香！

📢本文做者：由webmote 原創，首發於【掘金】

📢做者格言：生活在於折騰，當你不折騰生活時，生活就開始折騰你，讓咱們一塊兒加油！💪💪💪

🎏 序言

RPC，字面直譯是遠程過程調用，該項技術並非如今纔開始出現的，以前的net remoting、web service甚至DCom，都或多或少的實現了相似的功能，只不過它們或者沒重視數據的編解碼，或者每重視通信協議的通用性，所以在它們流行的時候，總給人感受或者性能沒那麼理想，或者難以應用。數據庫

而目前流行的RPC技術，例如Thrift、GRPC、Dubbo等均爲互聯網電商的高併發，高性能的分佈式應用通信而設計，其編解碼性能都很是優秀，通信的效率也都不錯。編程

🎏 01. 爲啥用RPC？

不少朋友對於微服務採用RPC通信都帶很大的疑問，難道直接使用webApi他不香嗎？json

是的，什麼事情都不是絕對的，當你的業務性能要求並非很高的狀況下，的確http的webapi已經足夠了吧，畢竟摳那麼一點性能，不如更快完成業務的好。c#

從拆分爲微服務的角度來看，因爲拆分的業務粒度問題，不可避免的會致使之前一個服務搞定的功能，如今是由多個服務聯合完成的。咱們畫個圖看看到底發生了什麼？api

是的，以前的業務A若是是各個數據須要調用數據庫，假設須要3次，那麼拆分爲微服務後，須要經過網絡分別調用各個微服務的接口，這些接口再經過網絡調用各自的數據庫。服務器

這只是通常複雜的場景，還有不少複雜的業務，可能調用鏈更長。markdown

那麼這多出來的網絡調用，每一個都會有延遲，加起來可能就比較客觀了。固然這就是你提升了擴展性而付出的代價。網絡

🎏 02. RPC的調用環節

RPC按照規定的協議序列化二進制流
網絡傳送（tcp或者 http2）
反序列化二進制流，按照指定的方法等參數交給動態代理處理，並獲得返回值（有些協議能夠定義沒有返回值）
返回值進行序列化，經過網絡傳回調用方。
調用方反序列化，獲得返回值。

所以從上面的環節也能夠看出，主要的性能能夠優化的地方就是網絡傳輸和序列化、反序列化。併發

在網絡傳輸方面，目前比較優秀的庫有netty，有能力的童鞋能夠在這個基礎上定義本身的協議來實現通信底層。

固然目前已經存在的也比較優秀，例如：thrift，dubbo，grpc。

若是咱們進行協議封裝，推薦的作法是支持異步IO，c#下支持async模式，這樣能夠極大提升吞吐量。

在序列化性能方面，有個基本的優先級： xml < json < protobuf、thrift。

在數據量稍微大點的狀況下，序列化json是一個很大的性能損耗，這個在以前的項目中有作過性能測試。

固然這些協議在使用中還有一些特性須要注意選擇合適的場景。好比簡單的能夠採用json，由於對於protobuf、thrift，它們都須要定義idl，相對麻煩些，固然這些麻煩就是爲了性能設計。

🎏 03. Thrift介紹

Thrift 是一個軟件框架，用來進行可擴展且跨語言的服務的開發。它結合了功能強大的軟件堆棧和代碼生成引擎，以構建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結合的、高效的服務。

thrift最初由facebook開發，目前是 Apache基金會的頂級項目。

thrift容許你定義一個簡單的數據類型和服務接口的idl接口文件，以做爲輸入文件，編譯器生成代碼用來方便地生成RPC客戶端和服務器通訊的編程語言。

🎏 04. grpc介紹

gRPC由 google 開發，是一款語言中立、平臺中立、開源的遠程過程調用(RPC)系統。

gRPC採用protobuf來定義接口，從而有更加嚴格的接口約束條件，經過protobuf能夠將數據序列化爲二進制編碼，這會大幅減小須要傳輸的數據量，從而大幅提升性能。

gRPC採用Http 2.0協議，在通信效率上相比採用Http協議的webapi仍是有必定的優點的。

🎏 05. 小結

其實還有不少內容，我想寫的更多，但是實力和時間不容許，暫時到這吧，後續有什麼不妥的還能夠修改追加，感謝你看到這裏！

例行小結，理性看待！

結的是啥啊，結的是我想你點贊而不可得的寂寞。😳😳😳

👓都看到這了，還在意點個贊嗎？

👓都點讚了，還在意一個收藏嗎？