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