微服務架構的四大金剛利器
【編者的話】互聯網應用發展到今天，從單體應用架構到 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 ，分布式系統中的網絡延時或中斷是避免不了的，通常會導致服務的調用層觸發重試。具有這一性質的接口在設計時總是秉持這樣的一種理念：調用接口發生異常并且重復嘗試時，總是會造成系統所無法承受的損失，所以必須阻止這種現象的發生。
冪等通常會有兩個維度：
- 空間維度上的冪等，即冪等對象的范圍，是個人還是機構，是某一次交易還是某種類型的交易。
- 時間維度上的冪等，即冪等的保證時間，是幾個小時、幾天還是永久性的。
在實際系統中有很多操作，不管操作多少次，都應該產生一樣的效果或返回相同的結果。以下這些應用場景也是通常比較常見的應用場景：
- 前端重復提交請求，且請求數據相同時，后臺需要返回對應這個請求的相同結果。
- 發起一次支付請求，支付中心應該只扣用戶賬戶一次錢，當遇到網絡中斷或系統異常時，也應該只扣一次錢。
- 發送消息，同樣內容的短信發給用戶只發一次。
- 創建業務訂單，一次業務請求只能創建一個，重試請求創建多個就會出大問題。
- 基于 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 的優先級：
- 首先判斷 Idempotent 的 spelKey 的屬性是否為空，如果不為空會根據 spelKey 定義的 Spring 表達式生成冪等 ID。
- 其次判斷參數是否包含 IdempotentTxId 注解，如果有 IdempotentTxId ，會直接獲取參數值生成冪等 ID。
- 再次通過反射獲取參數對象屬性是否包含 IdempotentTxId 注解，如果對象屬性包含 IdempotentTxId 注解會獲取該參數對象屬性生成冪等 ID。
- 最后以上三種情況仍未獲取到冪等 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 包含三種狀態包括成功、失敗可重試、失敗不可重試）。
