這篇文章主要描述RPC框架中的非同步與安全，包括服務調用方和服務提供方的非同步計算設計方案，服務調用方與服務提供方之間的身份驗證以及服務提供方和服務發現之間的安全設計。 ...
17 | 非同步RPC：壓榨單機吞吐量
在我們知道RPC框架基礎知識後，我們需要從RPC框架整體性能去考慮問題，例如怎麼提升RPC框架的性能、穩定性、安全性、吞吐量，以及如何在分散式的場景下快速定位問題等。
影響RPC調用吞吐量的根本原因是什麼？
處理RPC請求比較耗時，並且CPU大部分時間都在等待而非去計算，從而導致CPU利用率不高。RPC請求的耗時大部分是業務耗時，比如業務邏輯中有訪問資料庫執行慢SQL的操作，所以我們要看怎麼能提升業務邏輯處理。
要提升吞吐量，關鍵就兩個字：非同步。
服務調用端怎麼非同步？
對於調用端來說，向服務端發送請求消息與接受服務端發送過來的響應消息，這兩個處理過程是兩個完全獨立的過程，這兩個過程甚至在大多數情況下都不在一個線程中進行，也就是說，對於RPC框架，無論是同步調用還是非同步調用，調用端的內部實現都是非同步的。
調用端發送的每條信息都有一個唯一的消息標識，實際上調用端想服務端發送請求消息之前會創建一個Future，並會存儲這個消息標識與這個Future的映射，動態代理所獲得的返回值最終就是從這個Future中獲取的，當收到服務端響應的消息時，調用端會根據響應消息的唯一標識，通過之前存儲的映射找到對應的Future，將結果註入給那個Future，再進行一系列的處理邏輯，最後動態代理從Future中得到正確的返回值。
所謂同步調用，是指RPC框架在調用端的處理邏輯中主動執行了Future.get()方法，讓動態代理等待返回值，而非同步調用則是RPC框架沒有主動執行這個方法，用戶可以從請求上下文中得到這個Future，自己決定什麼時候執行Future.get()方法。
Future模式的示意圖如下。
服務提供方如何支持業務邏輯非同步？
我們可以讓RPC框架支持CompletableFuture，實現RPC調用在調用方和提供方之間完全非同步。
CompletableFuture是Java 8原生支持的。如果RPC框架能夠支持CompletableFuture，那發佈一個RPC服務，服務介面定義的返回值是CompletableFuture對象，整個調用過程會分為以下幾步：
- 服務調用方發起RPC請求，直接拿到返回值CompletableFuture對象，之後就不需要任何額外的與RPC框架相關的操作了，直接就可以進行非同步處理。
- 在服務提供方業務邏輯中創建一個返回值CompletableFuture對象，之後服務端真正的業務邏輯完全可以在一個線程池中非同步處理，業務邏輯完成之後再調用這個CompletableFuture對象的complete方法，完成非同步通知。
- 服務調用方在收到服務提供方發送過來的響應之後，RPC框架再自動地調用服務調用方拿到的那個 返回值CompletableFuture對象的complete方法，這樣一次非同步調用就完成了。
RPC遠程方法調用，有以下幾種方式：
- sync，預設方式，這是在“方法”內部同步，但RPC框架還是非同步處理的。
- future，RPC消費者得到future，自行決定何時獲取返回結果。
- callback，RPC調用端不需要同步處理響應結果，可以直接返回，最後返回結果將會在回調線程中非同步處理。
- oneway，調用端發起請求後不需要接收響應。
18 | 安全體系：如何建立可靠的安全體系？
RPC一般用於解決內部應用之間的通信，這裡的“內部”是指應用都部署在同一個大區域網中，這樣在RPC中，我們很少考慮像數據包篡改、請求偽造等惡意行為。
我們主要關註兩種類型的安全場景：
- 調用方之間的安全保證。
- 服務發現中的安全保證。
我們可以引入一個授權平臺，來對調用方的身份進行驗證，調用方可以在授權平臺上申請自己應用裡面需要調用的介面，而服務方可以在授權平臺上進行審批，只有服務提供方審批後，調用方纔能夠調用。
上面的設計方案，授權平臺承擔了公司內所有RPC請求的次數總和，當RPC請求量達到一定水平，授權平臺會成為一個瓶頸點。
為瞭解決這個問題，我們可以將授權平臺所做的事情轉移到服務提供方。我們使用一種不可逆加密演算法，例如HMAC演算法。服務提供方應用裡面放一個用於HMAC簽名的私鑰，在授權平臺上用這個私鑰為申請調用的調用方應用進行簽名，這個簽名生成的串就變成了調用方唯一的身份。服務提供方在收到調用方的授權請求之後，我們只需要驗證這個簽名更調用方應用信息是否對應的上就可以了。
服務提供方可以提供的安全校驗方式：
- md5摘要校驗
- 非對稱加密演算法
- OAuth2授權
為了避免同一個介面有多個應用做發佈提供者，我們需要把介面跟應用綁定上，一個介面只允許有一個應用發佈提供者，避免其他應用也能發佈這個介面。
當註冊中心收到服務提供方註冊申請時，可以驗證下請求過來的應用是否跟介面綁定的應用一樣，只有相同才允許註冊，否則就返回錯誤信息給啟動的應用，從而避免假冒的服務提供者對外提供錯誤服務。
作者：李潘 出處：http://wing011203.cnblogs.com/ 本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
