微服務架構四大金剛利器

概述

網際網路應用發展到今天，從單體應用架構到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> boolean put(String key, T value);

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

    /**
     * 基于key删除緩存資料
     * 
     * @param key
     * @return
     */
    public boolean invalid(String key);

get方法針對key進行查詢，put存儲緩存資料，invalid删除緩存資料。

限流

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

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

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

    /**
     * 指定過期時間自增計數器,機關時間内超過最大值rateThreshold傳回true，否則傳回false
     * 
     * @param key 限流key
     * @param rateThreshold 限流門檻值
     * @param expireTime 固定視窗時間
     * @param unit 時間機關
     * @return
     */
    public boolean rateLimit(final String key, final int 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
     */
    long limitCount() default Long.MAX_VALUE;

    /**
     * 時間段
     */
    long timeRange();

    /**
     * 阻塞時間段
     */
    long blockDuration();

    /**
     * 時間機關，預設為秒
     */
    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提供的幂等注解,具體幂等注解使用方式如下：

注解定義	使用範圍	使用描述
Idempotent	方法	Idempotent需要定義到具體Method上。Idempotent有個屬性定義： expireDate表示幂等有效期，預設30天。 spelKey表示可以使用spring表達式生成幂等唯一ID，比如直接擷取到對象屬性或者方法或者其他表達式。
IdempotentTxId	參數、對象屬性	IdempotentTxId可以直接定義到方法參數或者參數對象屬性上,直接擷取幂等ID
IdempotentTxIdGetter		IdempotentTxIdGetter可以直接定義參數對象的方法上，調用該方法擷取幂等ID

幂等攔截器擷取幂等ID的優先級：

首先判斷Idempotent的spelKey的屬性是否為空，如果不為空會根據spelKey定義的spring表達式生成幂等ID。
其次判斷參數是否包含IdempotentTxId注解，如果有IdempotentTxId，會直接擷取參數值生成幂等ID。
再次通過反射擷取參數對象屬性是否包含IdempotentTxId注解，如果對象屬性包含IdempotentTxId注解會擷取該參數對象屬性生成幂等ID。
最後以上三種情況仍未擷取到幂等ID，會進一步通過反射擷取參數對象的Method是否定義IdempotentTxIdGetter注解，如果包含該注解則通過反射生成幂等ID。

代碼使用示例：

@Idempotent(spelKey = "#request.requestId", firstLevelExpireDate = 7，secondLevelExpireDate = 30)
    public void execute(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包含三種狀态包括成功、失敗可重試、失敗不可重試)。

本文作者：中間件小哥

微服務架構四大金剛利器

繼續閱讀

HDU 4719 Oh My Holy FFF

CSU 1561 (More) Multiplication

CSU 1563 Lexicography

HDU 4721 Food and Productivity

ZOJ 1041 Transmitters

CSU 1562 Fun House

CodeChef PALPROB Palindromeness

UVA 10344- 23 out of 5

ZOJ 1104 Leaps Tall Buildings

HDU 2821 Pusher

UVA 1401 Remember the Word

ZOJ 2748 Free Kick

CSU 1567 Reverse Rot

JAVA 系列——>開發工具IntelliJ IDEA的安裝以及配置、快捷鍵IDEA 簡介

UVA 519 Puzzle (II)

磁盤結構及在Linux中的命名