微服務架構的四大殺手鐧

Photo @Christopher Campbell 

文 | 孔凡勇

概述

網際網路應用發展到今天，從單體應用架構到 SOA 以及今天的微服務，隨著微服務化的不斷升級進化，服務和服務之間的穩定性變得越來越重要，分散式系統之所以複雜，主要原因是分散式系統需要考慮到網路的延時和不可靠，微服務很重要的一個特質就是需要保證服務冪等，保證冪等性很重要的前提需要分散式鎖控制併發，同時快取、降級和限流是保護微服務系統執行穩定性的三大利器。

隨著業務不斷的發展，按業務域的劃分子系統越來越多，每個業務系統都需要快取、限流、分散式鎖、冪等工具元件， distributed-tools 元件(暫未開源)正式包含了上述分散式系統所需要的基礎功能元件。

distributed-tools 元件基於 tair、redis 分別提供了 2 個 springboot starter ，使用起來非常簡單。

以使用快取使用 redis 為例， application.properties 新增如下配置：

redis.extend.hostName=127.0.0.1
redis.extend.port=6379
redis.extend.password=pwdcode
redis.extend.timeout=10000

redis.idempotent.enabled=true

接下來的篇幅，重點會介紹一下快取、限流、分散式鎖、冪等的使用方式。

快取

快取的使用可以說無處不在，從應用請求的訪問路徑來看，使用者 user -> 瀏覽器快取 -> 反向代理快取-> WEB伺服器快取 -> 應用程式快取 -> 資料庫快取等，幾乎每條鏈路都充斥著快取的使用，快取最直白的解釋就是“用空間換時間”的演算法。快取就是把一些資料暫時存放於某些地方，可能是記憶體，也有可能硬碟。總之，目的就是為了避免某些耗時的操作。我們常見的耗時的操作，比如資料庫的查詢、一些資料的計算結果，或者是為了減輕伺服器的壓力。其實減輕壓力也是因查詢或計算，雖然短耗時，但操作很頻繁，累加起來也很長，造成嚴重排隊等情況，伺服器抗不住。

distributed-tools 元件提供了一個 CacheEngine 介面，基於 Tair、Redis 分別有不同的實現，具體 CacheEngine 定義如下：

    public String get(String key);

    /**
     * 獲取指定的key對應的物件,異常也會返回null
     *
     * @param key
     * @param clazz
     * @return
     */
    public <T> T get(String key, Class<T> clz);

    /**
     * 儲存快取資料,忽略過期時間
     *
     * @param key
     * @param value
     * @return
     */
    public <T extends Serializable> booleanput(String key, T value);

    /**
     * 儲存快取資料
     *
     * @param key
     * @param value
     * @param expiredTime
     * @param unit
     * @return
     */
    public <T extends Serializable> booleanput(String key, T value, int expiredTime, TimeUnit unit);

    /**
     * 基於key刪除快取資料
     *
     * @param key
     * @return
     */
    publicbooleaninvalid(String key);

get 方法針對 key 進行查詢， put 儲存快取資料， invalid 刪除快取資料。

限流

在分散式系統中，尤其面對一些秒殺、瞬時高併發場景，都需要進行一些限流措施，保證系統的高可用。通常來說限流的目的是透過對併發訪問/請求進行限速，或者一個時間視窗內的的請求進行限速來保護系統，一旦達到限制速率則可以 拒絕服務（定向到錯誤頁或告知資源沒有了）、排隊 或 等待（比如秒殺、評論、下單）、降級（返回託底資料或預設資料，如商品詳情頁庫存預設有貨）。

常見的一些限流演算法包括固定視窗、滑動視窗、漏桶、令牌桶，distributed-tools 元件目前基於計數器只實現了固定視窗演算法，具體使用方式如下：

 /**
     * 指定過期時間自增計數器，預設每次+1，非滑動視窗
     *
     * @param key 計數器自增key
     * @param expireTime 過期時間
     * @param unit  時間單位
     * @return
     */
    publiclongincrCount(String key, int expireTime, TimeUnit unit);

    /**
     * 指定過期時間自增計數器,單位時間內超過最大值rateThreshold返回true，否則返回false
     *
     * @param key 限流key
     * @param rateThreshold 限流閾值
     * @param expireTime 固定視窗時間
     * @param unit 時間單位
     * @return
     */
    publicbooleanrateLimit(final String key, finalint rateThreshold, int expireTime, TimeUnit unit);

基於 CacheEngine 的 rateLimit 方法可以實現限流， expireTime 只能設定固定視窗時間，非滑動視窗時間。

另外 distributed-tools 元件提供了模板 RateLimitTemplate 可以簡化限流的易用性，可以直接呼叫 RateLimitTemplate 的 execute 方法處理限流問題。

 /**
     * @param limitKey 限流KEY
     * @param resultSupplier 回撥方法
     * @param rateThreshold 限流閾值
     * @param limitTime 限制時間段
     * @param blockDuration 阻塞時間段
     * @param unit 時間單位
     * @param errCodeEnum 指定限流錯誤碼
     * @return
     */
    public <T> T execute(String limitKey, Supplier<T> resultSupplier, long rateThreshold, long limitTime,
                         long blockDuration, TimeUnit unit, ErrCodeEnum errCodeEnum){
        boolean blocked = tryAcquire(limitKey, rateThreshold, limitTime, blockDuration, unit);
        if (errCodeEnum != null) {
            AssertUtils.assertTrue(blocked, errCodeEnum);
        } else {
            AssertUtils.assertTrue(blocked, ExceptionEnumType.ACQUIRE_LOCK_FAIL);
        }

        return resultSupplier.get();
    }

另外 distributed-tools 元件還提供了註解 @RateLimit 的使用方式，具體註解 RateLimit 定義如下：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Documented
public @interface RateLimit {

    /**
     * 限流KEY
     */
    String limitKey();

    /**
     * 允許訪問的次數，預設值MAX_VALUE
     */
    longlimitCount()default Long.MAX_VALUE;

    /**
     * 時間段
     */
    longtimeRange();

    /**
     * 阻塞時間段
     */
    longblockDuration();

    /**
     * 時間單位，預設為秒
     */
    TimeUnit timeUnit()default TimeUnit.SECONDS;
}

基於註解的方式限流使用程式碼如下：

@RateLimit(limitKey = "#key", limitCount = 5, timeRange = 2, blockDuration = 3, timeUnit = TimeUnit.MINUTES)
public String testLimit2(String key){
    ..........
    return key;
}

任何方法新增上述註解具備了一定的限流能力(具體方法需要在 spring aop 指定攔截範圍內)，如上程式碼表示以引數 key 作為限流 key ，每 2 分鐘請求次數不超過 5 次，超過限制後阻塞 3 分鐘。

分散式鎖

在 Java 單一程式中透過 synchronized 關鍵字和 ReentrantLock 可重入鎖可以實現在多執行緒環境中控制對資源的併發訪問，通常本地的加鎖往往不能滿足我們的需要，我們更多的面對場景是分散式系統跨程式的鎖，簡稱為分散式鎖。分散式鎖實現手段通常是將鎖標記存在記憶體中，只是該記憶體不是某個程式分配的記憶體而是公共記憶體如 Redis、Tair ，至於利用資料庫、檔案等做鎖與單機的實現是一樣的，只要保證標記能互斥就行。分散式鎖相對單機程式的鎖之所以複雜，主要原因是分散式系統需要考慮到網路的延時和不可靠。

 distributed-tools 元件提供的分散式鎖要具備如下特性：

• 互斥性:同本地鎖一樣具有互斥性，但是分散式鎖需要保證在不同節點程式的不同執行緒的互斥。

• 可重入性:同一個節點上的同一個執行緒如果獲取了鎖之後那麼也可以再次獲取這個鎖。

• 鎖超時:和本地鎖一樣支援鎖超時，防止死鎖，透過非同步心跳 demon 執行緒重新整理過期時間，防止特殊場景(如 FGC 死鎖超時)下死鎖。

• 高效能、高可用:加鎖和解鎖需要高效能，同時也需要保證高可用防止分散式鎖失效，可以增加降級。

• 支援阻塞和非阻塞:同 ReentrantLock 一樣支援 lock 和 trylock 以及 tryLock ( long timeOut )。

• 公平鎖和非公平鎖(不支援):公平鎖是按照請求加鎖的順序獲得鎖，非公平鎖就相反是無序的，目前 distributed-tools 元件提供的分散式鎖不支援該特性。

distributed-tools 元件提供的分散式鎖，使用起來非常簡單，提供了一個分散式鎖模板：DistributedLockTemplate ，可以直接呼叫模板提供的靜態方法(如下)：

 /**
     * 分散式鎖處理模板執行器
     *
     * @param lockKey 分散式鎖key
     * @param resultSupplier 分散式鎖處理回撥
     * @param waitTime 鎖等待時間
     * @param unit 時間單位
     * @param errCodeEnum 指定特殊錯誤碼返回
     * @return
     */
    public static <T> T execute(String lockKey, Supplier<T> resultSupplier, long waitTime, TimeUnit unit,
                                ErrCodeEnum errCodeEnum){
        AssertUtils.assertTrue(StringUtils.isNotBlank(lockKey), ExceptionEnumType.PARAMETER_ILLEGALL);
        boolean locked = false;
        Lock lock = DistributedReentrantLock.newLock(lockKey);
        try {
            locked = waitTime > 0 ? lock.tryLock(waitTime, unit) : lock.tryLock();
        } catch (InterruptedException e) {
            throw new RuntimeException(String.format("lock error,lockResource:%s", lockKey), e);
        }
        if (errCodeEnum != null) {
            AssertUtils.assertTrue(locked, errCodeEnum);
        } else {
            AssertUtils.assertTrue(locked, ExceptionEnumType.ACQUIRE_LOCK_FAIL);
        }
        try {
            return resultSupplier.get();
        } finally {
            lock.unlock();
        }
    }

冪等

 在分散式系統設計中冪等性設計中十分重要的，尤其在複雜的微服務中一套系統中包含了多個子系統服務，而一個子系統服務往往會去呼叫另一個服務，而服務呼叫服務無非就是使用 RPC 通訊或者 restful ，分散式系統中的網路延時或中斷是避免不了的，通常會導致服務的呼叫層觸發重試。具有這一性質的介面在設計時總是秉持這樣的一種理念：呼叫介面發生異常並且重複嘗試時，總是會造成系統所無法承受的損失，所以必須阻止這種現象的發生。

冪等通常會有兩個維度：
1. 空間維度上的冪等，即冪等物件的範圍，是個人還是機構，是某一次交易還是某種型別的交易。
2. 時間維度上的冪等，即冪等的保證時間，是幾個小時、幾天還是永久性的。

在實際系統中有很多操作，不管操作多少次，都應該產生一樣的效果或返回相同的結果。以下這些應用場景也是通常比較常見的應用場景：
1. 前端重複提交請求，且請求資料相同時，後臺需要返回對應這個請求的相同結果。
2. 發起一次支付請求，支付中心應該只扣使用者賬戶一次錢，當遇到網路中斷或系統異常時，也應該只扣一次錢。
3. 傳送訊息，同樣內容的簡訊發給使用者只發一次。
4. 建立業務訂單，一次業務請求只能建立一個，重試請求建立多個就會出大問題。
5. 基於 msgId 的訊息冪等處理。

在正式使用 distributed-tools 元件提供的冪等之前，我們先看下 distributed-tools 冪等元件的設計。

冪等 key 提取能力：獲取唯一冪等 key

冪等 key 的提取支援 2 中註解：IdempotentTxId、IdempotentTxIdGetter，任意方法新增以上 2 註解，即可提取到相關冪等 key ，前提條件是需要將 Idempotent 註解新增相關需要冪等的方法上。

如果單純使用冪等模板進行業務處理，需要自己設定相關冪等key，且要保證其唯一性。

分散式鎖服務能力：提供全域性加鎖、解鎖的能力

distributed-tools 冪等元件需要使用自身提供的分散式鎖功能，保證其併發唯一性， distributed-tools 提供的分散式鎖能夠提供其可靠、穩定的加鎖、解鎖能力。

高效能的寫入、查詢能力：針對冪等結果查詢與儲存

distributed-tools 冪等元件提供了基於 tair 、 redis 的儲存實現，同時支援自定義一級、二級儲存透過 spring 依賴注入到 IdempotentService ，建議 distributed-tools 冪等儲存結果一級儲存 tair mdb ，二級儲存ldb或者 tablestore ，一級儲存保證其高效能，二級儲存保證其可靠性。

二級儲存並行查詢會返回查詢最快的冪等結果。
二級儲存並行非同步寫入，進一步提高效能。

高可用的冪等寫入、查詢能力：冪等儲存出現異常，不影響業務正常流程，增加容錯
distributed-tools 冪等元件支援二級儲存，為了保證其高可用，畢竟二級儲存出現故障的機率太低，不會導致業務上不可用，如果二級儲存同時出現故障，業務上做了一定的容錯，針對不確定性的異常採取重試策略，會執行具體冪等方法。

一級儲存與二級儲存的寫入與查詢處理進行隔離，任何一級儲存的異常不會影響整體業務執行。

在瞭解了 distributed-tools 元件冪等之後，接下來我們來看下如何去使用冪等元件，首先了解下 common-api 提供的冪等註解,具體冪等註解使用方式如下：

冪等攔截器獲取冪等 ID 的優先順序：

1. 首先判斷 Idempotent 的 spelKey 的屬性是否為空，如果不為空會根據 spelKey 定義的 spring 表示式生成冪等 ID 。
2. 其次判斷引數是否包含 IdempotentTxId 註解，如果有 IdempotentTxId ，會直接獲取引數值生成冪等 ID 。
3. 再次透過反射獲取引數物件屬性是否包含 IdempotentTxId 註解，如果物件屬性包含 IdempotentTxId 註解會獲取該引數物件屬性生成冪等 ID 。
4. 最後以上三種情況仍未獲取到冪等 ID ，會進一步透過反射獲取引數物件的 Method 是否定義 IdempotentTxIdGetter 註解，如果包含該註解則透過反射生成冪等 ID 。

程式碼使用示例：

    @Idempotent(spelKey = "#request.requestId", firstLevelExpireDate = 7，secondLevelExpireDate = 30)
    publicvoidexecute(BizFlowRequest request){
       ..................
    }

如上述程式碼表示從 request 獲取 requestId 作為冪等 key ，一級儲存有效期 7 天，二級儲存有效期 30 天。

distributed-tools 除了可以使用冪等註解外，冪等元件還提供了一個通用冪等模板 IdempotentTemplate ，使用冪等模板的前提必須設定 tair.idempotent.enabled=true或者redis.idempotent.enabled=true ，預設為 false ，同時需要指定冪等結果一級儲存，冪等結果儲存為可選項配置。

具體使用冪等模板 IdempotentTemplate 的方法如下：

/**
     * 冪等模板處理器
     *
     * @param request 冪等Request資訊
     * @param executeSupplier 冪等處理回撥function
     * @param resultPreprocessConsumer 冪等結果回撥function 可以對結果做些預處理
     * @param ifResultNeedIdempotence 除了根據異常還需要根據結果判定是否需要冪等性的場景可以提供此引數
     * @return
     */
    public R execute(IdempotentRequest<P> request, Supplier<R> executeSupplier,
                     Consumer<IdempotentResult<P, R>> resultPreprocessConsumer, Predicate<R> ifResultNeedIdempotence){

      ........
    }

request：
冪等引數 IdempotentRequest 組裝，可以設定冪等引數和冪等唯一 ID 。

executeSupplier：
具體冪等的方法邏輯，比如針對支付、下單介面，可以透過 JDK8 函式式介面 Supplier Callback 進行處理。

resultBiConsumer：
冪等返回結果的處理，該引數可以為空，如果為空採取預設的處理，根據冪等結果，如果成功、不可重試的異常錯誤碼，直接返回結果，如果失敗可重試異常錯誤碼，會進行重試處理。

如果該引數值不為空，可以針對返回冪等結果進行特殊邏輯處理設定 ResultStatus(ResultStatus 包含三種狀態包括成功、失敗可重試、失敗不可重試)。

作者資訊：

孔凡勇，花名雲狄，阿里雲-開放平臺高階技術家，對高併發、高效能、高可用、可伸縮的分散式系統架構設計有豐富經驗，Cloud Native堅定擁護者，堅守開發一線打磨匠藝的架構師。