RPC 異步響應式調用

同步調用的缺點

咱們假設一個電子商城用戶購買商品的場景: 建立訂單前的驗證方法。

/**
 * 驗證訂單是否合法
 * 
 * @param userId 用戶id
 * @param itemId 商品id
 * @param discount 折扣
 * @return
 */
public boolean verifyOrder(long userId, long itemId, double discount) {
    
    // 驗證用戶可否享受這一折扣，RPC調用
    boolean verifyDiscount = discountService.verify(userId, itemId, discount);
    
    if(!verifyDiscount) {
        // 該用戶沒法享受這一折扣
        return false;
    }
    
    // 獲取商品單價，RPC調用
    double itemPrice = storeService.getPrice(itemId);
    
    // 用戶實際應該支付的價格
    double realPrice = itemPrice * discount;
    
    // 獲取用戶帳號餘額，限定了只能使用餘額購買，RPC調用
    double balance = userService.getBalance(userId);
            
    return realPrice <= balance;
}

這個方法裏面涉及到了 3 個 rpc 調用，假設每一個 rpc 調用都須要 10ms，那麼 verifyOrder 這個方法總耗時將不低於 30ms。

在同步調用系統中，延遲同時會致使吞吐量的降低。若是隻有一個線程，那麼系統每秒的吞吐量將不會高於 1000ms / 30ms，也就是最多 33 qps。同步系統要提升吞吐量，惟一的辦法就是加大線程數。同時啓用 1,000 個線程，吞吐量理論值能夠上升到 33,333 qps。不過實際使用中，這並非完美的方案：增長線程數量會致使頻繁的上下文切換，系統總體性能將會嚴重降低。

Future 的不足

爲了解決同步系統的問題，Java 5 引入了 Future。有了 Future 後，上面的方法能夠修改成：

/**
 * 驗證訂單是否合法
 * 
 * @param userId 用戶id
 * @param itemId 商品id
 * @param discount 折扣
 * @return
 */
public boolean verifyOrder(long userId, long itemId, double discount) {
    
    // 驗證用戶可否享受這一折扣，RPC調用
    Future<Boolean> verifyDiscountFuture = discountService.verify(userId, itemId, discount);
    
    // 獲取商品單價，RPC調用
    Future<Double> itemPriceFuture = storeService.getPrice(itemId);
    
    // 獲取用戶帳號餘額，限定了只能使用餘額購買，RPC調用
    Future<Double> balanceFuture = userService.getBalance(userId);

    if(!verifyDiscountFuture.get()) {
        // 該用戶沒法享受這一折扣
        return false;
    }

    // 用戶實際應該支付的價格
    double realPrice = itemPriceFuture.get() * discount;

    // 用戶帳號餘額
    double balance = balanceFuture.get();
            
    return realPrice <= balance;
}

3 個 rpc 調用能夠同時進行了，系統延遲下降爲以前的 1/3。不過延遲下降吞吐量的問題仍是沒有解決，依然須要經過增長線程數來提高吞吐量。

CompletableFuture 纔是王道

引入 CompletableFuture 後，咱們可使用以下形式：

/**
 * 驗證訂單是否合法
 * 
 * @param userId 用戶id
 * @param itemId 商品id
 * @param discount 折扣
 * @return
 */
public CompletableFuture<Boolean> verifyOrder(long userId, long itemId, double discount) {
    
    // 驗證用戶可否享受這一折扣，RPC調用
    CompletableFuture<Boolean> verifyDiscountFuture = discountService.verify(userId, itemId, discount);
    
    // 獲取商品單價，RPC調用
    CompletableFuture<Double> itemPriceFuture = storeService.getPrice(itemId);
    
    // 獲取用戶帳號餘額，限定了只能使用餘額購買，RPC調用
    CompletableFuture<Double> balanceFuture = userService.getBalance(userId);
        
    return CompletableFuture
        .allOf(verifyDiscountFuture, itemPriceFuture, balanceFuture)
        .thenApply(v -> {
    	    if(!verifyDiscountFuture.get()) {
    	        // 該用戶沒法享受這一折扣
    	        return false;
    	    }

    	    // 用戶實際應該支付的價格
    	    double realPrice = itemPriceFuture.get() * discount;

    	    // 用戶帳號餘額
    	    double balance = balanceFuture.get();
    	            
    	    return realPrice <= balance;
    	});	   
}

延遲下降爲原來 1/3，同時吞吐量也不會由於延遲而下降。很是完美，簡單高效，CompletableFuture 絕對稱得上是大殺器。在 rpc 異步調用這個問題上，沒什麼比 CompletableFuture 更適合的解決方案了。CompletableFuture 是 Doug Lea 的又一力做，完全解決了 Future 的缺陷，把 Java 帶入了異步響應式編程的新世界。

motan dubbo 的解決方案是否完美

不完美，會陷入回調地獄，motan 和 dubbo 的設計者應該考慮引入 CompletableFuture 了。

Akka RxJava Reactor 是否可用？

這 3 個方案都能完美解決上述問題。但我我的認爲這 3 個方案都有一些不足之處，不過這很是帶有主觀性偏見，僅供讀者參考。後面我可能會從 代碼量 代碼複雜度 性能 等方面給出更全面客觀評測。

1. Akka 歷來沒見過這樣複雜的系統，我以爲我搞不定它。actor 機制儘管有一堆的優勢，但在我看來這東西就是新形式的 goto。跳來跳去悠忽不定，簡直就是系統維護的地獄，徹底搞不定它。

2. RxJava 和 Reactor 沒什麼大問題，主要是引入了不少新的概念。要使用他們須要先花一段時間研究，這對在團隊中推廣很不利。不過若是你的團隊對這兩個中的任意一個已經有過深刻研究的話，我以爲用起來徹底沒問題。

廣告時間

Turbo 採用 CompletableFuture 做爲異步解決方案，性能很是好。

更多內容詳見：

• https://gitee.com/hank-whu/turbo-rpc
• https://github.com/hank-whu/turbo-rpc