微服務架構四大金剛利器
概述
網際網路應用發展到今天,從單體應用架構到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包含三種狀態包括成功、失敗可重試、失敗不可重試)。
原文連結
本文為雲棲社群原創內容,未經允許不得轉載。
相關文章
- 微服務架構的四大金剛利器微服務架構
- 微服務架構的四大殺手鐧微服務架構
- 微服務架構微服務架構
- 微服務2:微服務全景架構微服務架構
- 微服務架構:構建PHP微服務生態微服務架構PHP
- 微服務架構初探微服務架構
- 慎用 “微服務” 架構微服務架構
- 單體架構&微服務架構&中臺服務架構架構微服務
- 架構演進之「微服務架構」架構微服務
- 架構之:微服務架構漫談架構微服務
- 如何構建微服務架構微服務架構
- 微服務架構(一):什麼是微服務微服務架構
- [雲原生微服務架構](十)微服務架構的基礎知識微服務架構
- 微服務架構初識微服務架構
- 微服務架構詳談微服務架構
- 微服務核心架構梳理微服務架構
- 微服務與架構師微服務架構
- 聊聊微服務架構思想微服務架構
- 微服務 dubbospring 架構微服務Spring架構
- 微服務架構簡介微服務架構
- 軟體架構模式之微服務架構架構模式微服務
- 微服務架構—服務降級微服務架構
- 微服務架構學習與思考(05):微服務架構適用場景分析微服務架構
- 「乾貨分享」用友雲微服務架構下配置檔案管理利器:配置中心微服務架構
- SOA架構和微服務架構的區別架構微服務
- 微服務架構和設計模式 - DZone微服務微服務架構設計模式
- 微服務開發攻略之淺析微服務架構微服務架構
- SpringCloud(1) ——回顧微服務和微服務架構SpringGCCloud微服務架構
- 微服務業務架構的探索微服務架構
- 微服務架構之「 配置中心 」微服務架構
- 微服務架構最佳實踐微服務架構
- 微服務架構-雪崩效應微服務架構
- 分散式微服務架構(一)分散式微服務架構
- 如何快速搞定微服務架構?微服務架構
- 微服務架構怎麼選?微服務架構
- 微服務架構優缺點微服務架構
- 單體架構,SOA,微服務架構微服務
- 微服務架構模式簡介微服務架構模式