關鍵思路：
網絡通信，序列化，傳輸協議，服務調用
相關技術：dubbo,grpc,thrift
RPC 功能目標
RPC 的主要功能目標是讓構建分布式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。?
RPC 調用分類
RPC 調用分以下兩種：
1. 同步調用
客戶方等待調用執行完成并返回結果。
2. 異步調用
客戶方調用后不用等待執行結果返回，但依然可以通過回調通知等方式獲取返回結果。
若客戶方不關心調用返回結果，則變成單向異步調用，單向調用不用返回結果。
異步和同步的區分在于是否等待服務端執行完成并返回結果。
RPC 結構拆解
RPC 服務方通過 RpcServer 去導出（export）遠程接口方法，而客戶方通過 RpcClient 去引入（import）遠程接口方法。客戶方像調用本地方法一樣去調用遠程接口方法，RPC 框架提供接口的代理實現，實際的調用將委托給代理RpcProxy 。代理封裝調用信息并將調用轉交給RpcInvoker 去實際執行。在客戶端的RpcInvoker 通過連接器RpcConnector 去維持與服務端的通道RpcChannel，并使用RpcProtocol 執行協議編碼（encode）并將編碼后的請求消息通過通道發送給服務方。
RPC 服務端接收器 RpcAcceptor 接收客戶端的調用請求，同樣使用RpcProtocol 執行協議解碼（decode）。解碼后的調用信息傳遞給RpcProcessor 去控制處理調用過程，最后再委托調用給RpcInvoker 去實際執行并返回調用結果。
RPC 組件職責
1. RpcServer
負責導出（export）遠程接口
2. RpcClient
負責導入（import）遠程接口的代理實現
3. RpcProxy
遠程接口的代理實現
4. RpcInvoker
客戶方實現：負責編碼調用信息和發送調用請求到服務方并等待調用結果返回
服務方實現：負責調用服務端接口的具體實現并返回調用結果
5. RpcProtocol
負責協議編/解碼
6. RpcConnector
負責維持客戶方和服務方的連接通道和發送數據到服務方
7. RpcAcceptor
負責接收客戶方請求并返回請求結果
8. RpcProcessor
負責在服務方控制調用過程，包括管理調用線程池、超時時間等
9. RpcChannel
數據傳輸通道
RPC 實現分析
導出遠程接口
導出遠程接口的意思是指只有導出的接口可以供遠程調用，而未導出的接口則不能。在 java 中導出接口的代碼片段可能如下：
DemoService demo? = new ...;
RpcServer? server = new ...;
server.export(DemoService.class, demo, options);
我們可以導出整個接口，也可以更細粒度一點只導出接口中的某些方法，如：
// 只導出 DemoService 中簽名為 hi(String s) 的方法
server.export(DemoService.class, demo, "hi", new Class[] { String.class }, options);
java 中還有一種比較特殊的調用就是多態，也就是一個接口可能有多個實現，那么遠程調用時到底調用哪個？這個本地調用的語義是通過 jvm 提供的引用多態性隱式實現的，那么對于 RPC 來說跨進程的調用就沒法隱式實現了。如果前面DemoService 接口有 2 個實現，那么在導出接口時就需要特殊標記不同的實現，如：
DemoService demo? = new ...;
DemoService demo2? = new ...;
RpcServer? server = new ...;
server.export(DemoService.class, demo, options);
server.export("demo2", DemoService.class, demo2, options);
上面 demo2 是另一個實現，我們標記為 "demo2" 來導出，那么遠程調用時也需要傳遞該標記才能調用到正確的實現類，這樣就解決了多態調用的語義。
導入遠程接口與客戶端代理
導入相對于導出遠程接口，客戶端代碼為了能夠發起調用必須要獲得遠程接口的方法或過程定義。
代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對于同一語言平臺的 RPC 則可以通過共享接口定義來實現。在 java 中導入接口的代碼片段可能如下：
RpcClient client = new ...;
DemoService demo = client.refer(DemoService.class);
demo.hi("how are you?");
在 java 中 'import' 是關鍵字，所以代碼片段中我們用 refer 來表達導入接口的意思。這里的導入方式本質也是一種代碼生成技術，只不過是在運行時生成，比靜態編譯期的代碼生成看起來更簡潔些。java 里至少提供了兩種技術來提供動態代碼生成，一種是 jdk 動態代理，另外一種是字節碼生成。動態代理相比字節碼生成使用起來更方便，但動態代理方式在性能上是要遜色于直接的字節碼生成的，而字節碼生成在代碼可讀性上要差很多。兩者權衡起來，個人認為犧牲一些性能來獲得代碼可讀性和可維護性顯得更重要。
協議編解碼
客戶端代理在發起調用前需要對調用信息進行編碼，這就要考慮需要編碼些什么信息并以什么格式傳輸到服務端才能讓服務端完成調用。出于效率考慮，編碼的信息越少越好（傳輸數據少），編碼的規則越簡單越好（執行效率高）。我們先看下需要編碼些什么信息：
-- 調用編碼 --
1. 接口方法
包括接口名、方法名
2. 方法參數
包括參數類型、參數值
3. 調用屬性
包括調用屬性信息，例如調用附件隱式參數、調用超時時間等
-- 返回編碼 --
1. 返回結果
接口方法中定義的返回值
2. 返回碼
異常返回碼
3. 返回異常信息
調用異常信息
除了以上這些必須的調用信息，我們可能還需要一些元信息以方便程序編解碼以及未來可能的擴展。這樣我們的編碼消息里面就分成了兩部分，一部分是元信息、另一部分是調用的必要信息。如果設計一種 RPC 協議消息的話，元信息我們把它放在協議消息頭中，而必要信息放在協議消息體中。下面給出一種概念上的 RPC 協議消息設計格式：
-- 消息頭 --
magic? ? ? : 協議魔數，為解碼設計
header size: 協議頭長度，為擴展設計
version? ? : 協議版本，為兼容設計
st? ? ? ? : 消息體序列化類型
hb? ? ? ? : 心跳消息標記，為長連接傳輸層心跳設計
ow? ? ? ? : 單向消息標記，
rp? ? ? ? : 響應消息標記，不置位默認是請求消息
status code: 響應消息狀態碼
reserved? : 為字節對齊保留
message id : 消息 id
body size? : 消息體長度
-- 消息體 --
采用序列化編碼，常見有以下格式
xml? : 如 webservie soap
json? : 如 JSON-RPC
binary: 如 thrift; hession; kryo 等
格式確定后編解碼就簡單了，由于頭長度一定所以我們比較關心的就是消息體的序列化方式。序列化我們關心三個方面：
1. 序列化和反序列化的效率，越快越好。
2. 序列化后的字節長度，越小越好。
3. 序列化和反序列化的兼容性，接口參數對象若增加了字段，是否兼容。
上面這三點有時是魚與熊掌不可兼得，這里面涉及到具體的序列化庫實現細節，就不在本文進一步展開分析了。
傳輸服務
協議編碼之后，自然就是需要將編碼后的 RPC 請求消息傳輸到服務方，服務方執行后返回結果消息或確認消息給客戶方。RPC 的應用場景實質是一種可靠的請求應答消息流，和 HTTP 類似。因此選擇長連接方式的 TCP 協議會更高效，與 HTTP 不同的是在協議層面我們定義了每個消息的唯一 id，因此可以更容易的復用連接。
既然使用長連接，那么第一個問題是到底 client 和 server 之間需要多少根連接？實際上單連接和多連接在使用上沒有區別，對于數據傳輸量較小的應用類型，單連接基本足夠。單連接和多連接最大的區別在于，每根連接都有自己私有的發送和接收緩沖區，因此大數據量傳輸時分散在不同的連接緩沖區會得到更好的吞吐效率。所以，如果你的數據傳輸量不足以讓單連接的緩沖區一直處于飽和狀態的話，那么使用多連接并不會產生任何明顯的提升，反而會增加連接管理的開銷。
連接是由 client 端發起建立并維持。如果 client 和 server 之間是直連的，那么連接一般不會中斷（當然物理鏈路故障除外）。如果 client 和 server 連接經過一些負載中轉設備，有可能連接一段時間不活躍時會被這些中間設備中斷。為了保持連接有必要定時為每個連接發送心跳數據以維持連接不中斷。心跳消息是 RPC 框架庫使用的內部消息，在前文協議頭結構中也有一個專門的心跳位，就是用來標記心跳消息的，它對業務應用透明。
執行調用
client stub 所做的事情僅僅是編碼消息并傳輸給服務方，而真正調用過程發生在服務方。server stub 從前文的結構拆解中我們細分了 RpcProcessor 和 RpcInvoker 兩個組件，一個負責控制調用過程，一個負責真正調用。這里我們還是以 java 中實現這兩個組件為例來分析下它們到底需要做什么？
java 中實現代碼的動態接口調用目前一般通過反射調用。除了原生的 jdk 自帶的反射，一些第三方庫也提供了性能更優的反射調用，因此 RpcInvoker 就是封裝了反射調用的實現細節。
調用過程的控制需要考慮哪些因素，RpcProcessor 需要提供什么樣地調用控制服務呢？下面提出幾點以啟發思考：
1. 效率提升
每個請求應該盡快被執行，因此我們不能每請求來再創建線程去執行，需要提供線程池服務。
2. 資源隔離
當我們導出多個遠程接口時，如何避免單一接口調用占據所有線程資源，而引發其他接口執行阻塞。
3. 超時控制
當某個接口執行緩慢，而 client 端已經超時放棄等待后，server 端的線程繼續執行此時顯得毫無意義。
RPC 異常處理
無論 RPC 怎樣努力把遠程調用偽裝的像本地調用，但它們依然有很大的不同點，而且有一些異常情況是在本地調用時絕對不會碰到的。在說異常處理之前，我們先比較下本地調用和 RPC 調用的一些差異：
1. 本地調用一定會執行，而遠程調用則不一定，調用消息可能因為網絡原因并未發送到服務方。
2. 本地調用只會拋出接口聲明的異常，而遠程調用還會跑出 RPC 框架運行時的其他異常。
3. 本地調用和遠程調用的性能可能差距很大，這取決于 RPC 固有消耗所占的比重。
正是這些區別決定了使用 RPC 時需要更多考量。當調用遠程接口拋出異常時，異常可能是一個業務異常，也可能是 RPC 框架拋出的運行時異常（如：網絡中斷等）。業務異常表明服務方已經執行了調用，可能因為某些原因導致未能正常執行，而 RPC 運行時異常則有可能服務方根本沒有執行，對調用方而言的異常處理策略自然需要區分。
2 如何發布自己的服務？
如何讓別人使用我們的服務呢？有同學說很簡單嘛，告訴使用者服務的IP以及端口就可以了啊。確實是這樣，這里問題的關鍵在于是自動告知還是人肉告知。
人肉告知的方式：如果你發現你的服務一臺機器不夠，要再添加一臺，這個時候就要告訴調用者我現在有兩個ip了，你們要輪詢調用來實現負載均衡；調用者咬咬牙改了，結果某天一臺機器掛了，調用者發現服務有一半不可用，他又只能手動修改代碼來刪除掛掉那臺機器的ip。現實生產環境當然不會使用人肉方式。
有沒有一種方法能實現自動告知，即機器的增添、剔除對調用方透明，調用者不再需要寫死服務提供方地址？當然可以，現如今zookeeper被廣泛用于實現服務自動注冊與發現功能！
簡單來講，zookeeper可以充當一個服務注冊表（Service Registry），讓多個服務提供者形成一個集群，讓服務消費者通過服務注冊表獲取具體的服務訪問地址（ip+端口）去訪問具體的服務提供者。如下圖所示：
具體來說，zookeeper就是個分布式文件系統，每當一個服務提供者部署后都要將自己的服務注冊到zookeeper的某一路徑上:?/{service}/{version}/{ip:port}, 比如我們的HelloWorldService部署到兩臺機器，那么zookeeper上就會創建兩條目錄：分別為/HelloWorldService/1.0.0/100.19.20.01:16888 ?/HelloWorldService/1.0.0/100.19.20.02:16888。
zookeeper提供了“心跳檢測”功能，它會定時向各個服務提供者發送一個請求（實際上建立的是一個 socket 長連接），如果長期沒有響應，服務中心就認為該服務提供者已經“掛了”，并將其剔除，比如100.19.20.02這臺機器如果宕機了，那么zookeeper上的路徑就會只剩/HelloWorldService/1.0.0/100.19.20.01:16888。
服務消費者會去監聽相應路徑（/HelloWorldService/1.0.0），一旦路徑上的數據有任務變化（增加或減少），zookeeper都會通知服務消費方服務提供者地址列表已經發生改變，從而進行更新。
更為重要的是zookeeper 與生俱來的容錯容災能力（比如leader選舉），可以確保服務注冊表的高可用性。
由于 RPC 固有的消耗相對本地調用高出幾個數量級，本地調用的固有消耗是納秒級，而 RPC 的固有消耗是在毫秒級。那么對于過于輕量的計算任務就并不合適導出遠程接口由獨立的進程提供服務，只有花在計算任務上時間遠遠高于 RPC 的固有消耗才值得導出為遠程接口提供服務。
