溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了微服務架構中四大利器的用法示例，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
概述
互聯網應用發展到今天，從單體應用架構到 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 ，分布式系統中的網絡延時或中斷是避免不了的，通常會導致服務的調用層觸發重試。具有這一性質的接口在設計時總是秉持這樣的一種理念：調用接口發生異常并且重復嘗試時，總是會造成系統所無法承受的損失，所以必須阻止這種現象的發生。
冪等 key 提取能力：獲取唯一冪等 key
分布式鎖服務能力：提供全局加鎖、解鎖的能力
distributed-tools 冪等組件需要使用自身提供的分布式鎖功能，保證其并發唯一性， distributed-tools 提供的分布式鎖能夠提供其可靠、穩定的加鎖、解鎖能力。
高性能的寫入、查詢能力：針對冪等結果查詢與存儲
distributed-tools 冪等組件提供了基于 tair 、 redis 的存儲實現，同時支持自定義一級、二級存儲通過 spring 依賴注入到 IdempotentService ，建議 distributed-tools 冪等存儲結果一級存儲 tair mdb ，二級存儲ldb或者 tablestore ，一級存儲保證其高性能，二級存儲保證其可靠性。
@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){
........
}感謝你能夠認真閱讀完這篇文章，希望小編分享的“微服務架構中四大利器的用法示例”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
