微服務架構的四大金剛利器
Photo @Christopher Campbell
概述
網際網路應用發展到今天,從單體應用架構到 SOA 以及今天的微服務,隨著微服務化的不斷升級進化,服務和服務之間的穩定性變得越來越重要,分散式系統之所以複雜,主要原因是分散式系統需要考慮到網路的延時和不可靠,微服務很重要的一個特質就是需要保證服務冪等,保證冪等性很重要的前提需要分散式鎖控制併發,同時快取、降級和限流是保護微服務系統執行穩定性的三大利器。
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伺服器快取 -> 應用程式快取 -> 資料庫快取等,幾乎每條鏈路都充斥著快取的使用,快取最直白的解釋就是“用空間換時間”的演算法。快取就是把一些資料暫時存放於某些地方,可能是記憶體,也有可能硬碟。總之,目的就是為了避免某些耗時的操作。我們常見的耗時的操作,比如資料庫的查詢、一些資料的計算結果,或者是為了減輕伺服器的壓力。其實減輕壓力也是因查詢或計算,雖然短耗時,但操作很頻繁,累加起來也很長,造成嚴重排隊等情況,伺服器抗不住。
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 刪除快取資料。
限流
在分散式系統中,尤其面對一些秒殺、瞬時高併發場景,都需要進行一些限流措施,保證系統的高可用。通常來說限流的目的是透過對併發訪問/請求進行限速,或者一個時間視窗內的的請求進行限速來保護系統,一旦達到限制速率則可以 拒絕服務(定向到錯誤頁或告知資源沒有了)、排隊 或 等待(比如秒殺、評論、下單)、降級(返回託底資料或預設資料,如商品詳情頁庫存預設有貨)。
/**
* 指定過期時間自增計數器,預設每次+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);
/**
* @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();
}
@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;
}
在 Java 單一程式中透過 synchronized 關鍵字和 ReentrantLock 可重入鎖可以實現在多執行緒環境中控制對資源的併發訪問,通常本地的加鎖往往不能滿足我們的需要,我們更多的面對場景是分散式系統跨程式的鎖,簡稱為分散式鎖。分散式鎖實現手段通常是將鎖標記存在記憶體中,只是該記憶體不是某個程式分配的記憶體而是公共記憶體如 Redis、Tair ,至於利用資料庫、檔案等做鎖與單機的實現是一樣的,只要保證標記能互斥就行。分散式鎖相對單機程式的鎖之所以複雜,主要原因是分散式系統需要考慮到網路的延時和不可靠。
互斥性:同本地鎖一樣具有互斥性,但是分散式鎖需要保證在不同節點程式的不同執行緒的互斥。
可重入性:同一個節點上的同一個執行緒如果獲取了鎖之後那麼也可以再次獲取這個鎖。
鎖超時:和本地鎖一樣支援鎖超時,防止死鎖,透過非同步心跳 demon 執行緒重新整理過期時間,防止特殊場景(如 FGC 死鎖超時)下死鎖。
高效能、高可用:加鎖和解鎖需要高效能,同時也需要保證高可用防止分散式鎖失效,可以增加降級。
支援阻塞和非阻塞:同 ReentrantLock 一樣支援 lock 和 trylock 以及 tryLock ( long timeOut )。
公平鎖和非公平鎖(不支援):公平鎖是按照請求加鎖的順序獲得鎖,非公平鎖就相反是無序的,目前 distributed-tools 元件提供的分散式鎖不支援該特性。
/**
* 分散式鎖處理模板執行器
*
* @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 的訊息冪等處理。
冪等 key 提取能力:獲取唯一冪等 key
分散式鎖服務能力:提供全域性加鎖、解鎖的能力
distributed-tools 冪等元件需要使用自身提供的分散式鎖功能,保證其併發唯一性, distributed-tools 提供的分散式鎖能夠提供其可靠、穩定的加鎖、解鎖能力。
高效能的寫入、查詢能力:針對冪等結果查詢與儲存
distributed-tools 冪等元件提供了基於 tair 、 redis 的儲存實現,同時支援自定義一級、二級儲存透過 spring 依賴注入到 IdempotentService ,建議 distributed-tools 冪等儲存結果一級儲存 tair mdb ,二級儲存ldb或者 tablestore ,一級儲存保證其高效能,二級儲存保證其可靠性。
二級儲存並行非同步寫入,進一步提高效能。
distributed-tools 冪等元件支援二級儲存,為了保證其高可用,畢竟二級儲存出現故障的機率太低,不會導致業務上不可用,如果二級儲存同時出現故障,業務上做了一定的容錯,針對不確定性的異常採取重試策略,會執行具體冪等方法。
首先判斷 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){
..................
}
/**
* 冪等模板處理器
*
* @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){
........
}
冪等引數 IdempotentRequest 組裝,可以設定冪等引數和冪等唯一 ID 。
具體冪等的方法邏輯,比如針對支付、下單介面,可以透過 JDK8 函式式介面 Supplier Callback 進行處理。
冪等返回結果的處理,該引數可以為空,如果為空採取預設的處理,根據冪等結果,如果成功、不可重試的異常錯誤碼,直接返回結果,如果失敗可重試異常錯誤碼,會進行重試處理。
作者資訊:
孔凡勇,花名雲狄,阿里雲-開放平臺高階技術家,對高併發、高效能、高可用、可伸縮的分散式系統架構設計有豐富經驗,Cloud Native堅定擁護者,堅守開發一線打磨匠藝的架構師。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31561268/viewspace-2666092/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 微服務架構四大金剛利器微服務架構
- 微服務架構的四大殺手鐧微服務架構
- 微服務2:微服務全景架構微服務架構
- [雲原生微服務架構](十)微服務架構的基礎知識微服務架構
- (四)整合spring cloud雲服務架構 - 企業分散式微服務雲架構構建SpringCloud架構分散式微服務
- 微服務業務架構的探索微服務架構
- 微服務架構:構建PHP微服務生態微服務架構PHP
- 微服務架構初探微服務架構
- 微服務 dubbospring 架構微服務Spring架構
- 檔案系統、服務、防火牆、SELINUX——安全四大金剛防火牆Linux
- SOA架構和微服務架構的區別架構微服務
- 單體架構&微服務架構&中臺服務架構架構微服務
- 架構演進之「微服務架構」架構微服務
- 架構之:微服務架構漫談架構微服務
- 微服務架構(一):什麼是微服務微服務架構
- 分散式架構和微服務架構的區別分散式架構微服務
- 微服務核心架構梳理微服務架構
- 微服務架構初識微服務架構
- 微服務架構詳談微服務架構
- 微服務與架構師微服務架構
- 聊聊微服務架構思想微服務架構
- 軟體架構模式之微服務架構架構模式微服務
- 如何拆分你的微服務架構?微服務架構
- 微服務下的資料架構微服務架構
- 微服務架構在阿里的演化微服務架構阿里
- C#中的微服務架構C#微服務架構
- 微服務架構和設計模式 - DZone微服務微服務架構設計模式
- SpringCloud(1) ——回顧微服務和微服務架構SpringGCCloud微服務架構
- 微服務架構—服務降級微服務架構
- 架構與思維:微服務架構的思想本質架構微服務
- 「乾貨分享」用友雲微服務架構下配置檔案管理利器:配置中心微服務架構
- spring微服務架構設計與輕量級微服務架構及最佳部署Spring微服務架構
- 微服務架構學習與思考(05):微服務架構適用場景分析微服務架構
- spring cloud微服務分散式雲架構(四)-斷路器(Hystrix)SpringCloud微服務分散式架構
- 如何快速搞定微服務架構?微服務架構
- 永別了,微服務架構!微服務架構
- 微服務 架構圖 參考微服務架構
- 微服務架構-雪崩效應微服務架構