伴隨著微服務(wù)架構(gòu)被宣傳得如火如荼，一些概念也被推到了我們面前（管你接受不接受），其實大多數(shù)概念以前就有，但很少被提的這么頻繁（現(xiàn)在好像不提及都不好意思交流了）。想起有人總結(jié)的一句話，微服務(wù)架構(gòu)的特點就是：“一解釋就懂，一問就不知，一討論就吵架”。

其實對老外的總結(jié)能力一直特別崇拜，Kevin Kelly、Martin Fowler、Werner Vogels……，都是著名的“演講家”。正好這段時間看了些微服務(wù)、容器的相關(guān)資料，也在我們新一代產(chǎn)品中進(jìn)行了部分實踐，回過頭來，再來談?wù)剬σ恍└拍畹睦斫狻?br /> 今天先來說說“服務(wù)熔斷”和“服務(wù)降級”。為什么要說這個呢，因為我很長時間里都把這兩個概念同質(zhì)化了，不知道這兩個詞大家怎么理解，一個意思o(jì)r有所不同？現(xiàn)在的我是這么來看的：
在股票市場，熔斷這個詞大家都不陌生，是指當(dāng)股指波幅達(dá)到某個點后，交易所為控制風(fēng)險采取的暫停交易措施。相應(yīng)的，服務(wù)熔斷一般是指軟件系統(tǒng)中，由于某些原因使得服務(wù)出現(xiàn)了過載現(xiàn)象，為防止造成整個系統(tǒng)故障，從而采用的一種保護(hù)措施，所以很多地方把熔斷亦稱為過載保護(hù)。
大家都見過女生旅行吧，大號的旅行箱是必備物，平常走走近處綽綽有余，但一旦出個遠(yuǎn)門，再大的箱子都白搭了，怎么辦呢？常見的情景就是把物品拿出來分分堆，比了又比，最后一些非必需品的就忍痛放下了，等到下次箱子夠用了，再帶上用一用。而服務(wù)降級，就是這么回事，整體資源快不夠了，忍痛將某些服務(wù)先關(guān)掉，待渡過難關(guān)，再開啟回來。
所以從上述分析來看，兩者其實從有些角度看是有一定的類似性的：
目的很一致，都是從可用性可靠性著想，為防止系統(tǒng)的整體緩慢甚至崩潰，采用的技術(shù)手段；
最終表現(xiàn)類似，對于兩者來說，最終讓用戶體驗到的是某些功能暫時不可達(dá)或不可用；
粒度一般都是服務(wù)級別，當(dāng)然，業(yè)界也有不少更細(xì)粒度的做法，比如做到數(shù)據(jù)持久層（允許查詢，不允許增刪改）；
自治性要求很高，熔斷模式一般都是服務(wù)基于策略的自動觸發(fā)，降級雖說可人工干預(yù)，但在微服務(wù)架構(gòu)下，完全靠人顯然不可能，開關(guān)預(yù)置、配置中心都是必要手段；
而兩者的區(qū)別也是明顯的：
觸發(fā)原因不太一樣，服務(wù)熔斷一般是某個服務(wù)（下游服務(wù)）故障引起，而服務(wù)降級一般是從整體負(fù)荷考慮；
管理目標(biāo)的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務(wù)都需要（無層級之分），而降級一般需要對業(yè)務(wù)有層級之分（比如降級一般是從最外圍服務(wù)開始）
實現(xiàn)方式不太一樣，這個區(qū)別后面會單獨來說；
當(dāng)然這只是我個人對兩者的理解，外面把兩者歸為完全一致的也不在少數(shù)，或者把熔斷機制理解為應(yīng)對降級目標(biāo)的一種實現(xiàn)也說的過去，可能“一討論就吵架”也正是這個原因吧！
概念算是說完了，避免空談，我再總結(jié)下對常用的實現(xiàn)方法的理解。對于這兩個概念，號稱支持的框架可不少，Hystrix當(dāng)屬其中的佼佼者。
先說說最裸的熔斷器的設(shè)計思路，下面這張圖大家應(yīng)該不陌生（我只是參考著又畫了畫），簡明扼要的給出了好的熔斷器實現(xiàn)的三個狀態(tài)機：
?? ??? ?
Closed：熔斷器關(guān)閉狀態(tài)，調(diào)用失敗次數(shù)積累，到了閾值（或一定比例）則啟動熔斷機制；
Open：熔斷器打開狀態(tài)，此時對下游的調(diào)用都內(nèi)部直接返回錯誤，不走網(wǎng)絡(luò)，但設(shè)計了一個時鐘選項，默認(rèn)的時鐘達(dá)到了一定時間（這個時間一般設(shè)置成平均故障處理時間，也就是MTTR），到了這個時間，進(jìn)入半熔斷狀態(tài)；
Half-Open：半熔斷狀態(tài)，允許定量的服務(wù)請求，如果調(diào)用都成功（或一定比例）則認(rèn)為恢復(fù)了，關(guān)閉熔斷器，否則認(rèn)為還沒好，又回到熔斷器打開狀態(tài)；
那Hystrix，作為Netflix開源框架中的最受喜愛組件之一，是怎么處理依賴隔離，實現(xiàn)熔斷機制的呢，他的處理遠(yuǎn)比我上面說個實現(xiàn)機制復(fù)雜的多，一起來看看核心代碼吧，我只保留了代碼片段的關(guān)鍵部分：
public abstract class HystrixCommand<R> extends AbstractCommand<R> implements HystrixExecutable<R>, HystrixInvokableInfo<R>, HystrixObservable<R> {
?
? ? protected abstract R run() throws Exception;
?
? ? protected R getFallback() {
? ? ? ? throw new UnsupportedOperationException("No fallback available.");
? ? }
?
? ? @Override
? ? final protected Observable<R> getExecutionObservable() {
? ? ? ? return Observable.defer(new Func0<Observable<R>>() {
? ? ? ? ? ? @Override
? ? ? ? ? ? public Observable<R> call() {
? ? ? ? ? ? ? ? try {
? ? ? ? ? ? ? ? ? ? return Observable.just(run());
? ? ? ? ? ? ? ? } catch (Throwable ex) {
? ? ? ? ? ? ? ? ? ? return Observable.error(ex);
? ? ? ? ? ? ? ? }
? ? ? ? ? ? }
? ? ? ? });
? ? }
?
? ? @Override
? ? final protected Observable<R> getFallbackObservable() {
? ? ? ? return Observable.defer(new Func0<Observable<R>>() {
? ? ? ? ? ? @Override
? ? ? ? ? ? public Observable<R> call() {
? ? ? ? ? ? ? ? try {
? ? ? ? ? ? ? ? ? ? return Observable.just(getFallback());
? ? ? ? ? ? ? ? } catch (Throwable ex) {
? ? ? ? ? ? ? ? ? ? return Observable.error(ex);
? ? ? ? ? ? ? ? }
? ? ? ? ? ? }
? ? ? ? });
? ? }
?
? ? public R execute() {
? ? ? ? try {
? ? ? ? ? ? return queue().get();
? ? ? ? } catch (Exception e) {
? ? ? ? ? ? throw decomposeException(e);
? ? ? ? }
? ? }
HystrixCommand是重重之重，在Hystrix的整個機制中，涉及到依賴邊界的地方，都是通過這個Command模式進(jìn)行調(diào)用的，顯然，這個Command負(fù)責(zé)了核心的服務(wù)熔斷和降級的處理，子類要實現(xiàn)的方法主要有兩個：
run方法：實現(xiàn)依賴的邏輯，或者說是實現(xiàn)微服務(wù)之間的調(diào)用；
getFallBack方法：實現(xiàn)服務(wù)降級處理邏輯，只做熔斷處理的則可不實現(xiàn)；
使用時，可參考如下方式：
public class TestCommand extends HystrixCommand<String> {
?
?? ?protected TestCommand(HystrixCommandGroupKey group) {
?? ??? ?super(group);
?? ?}
?
?? ?@Override
?? ?protected String run() throws Exception {
?? ??? ?//這里需要做實際調(diào)用邏輯
?? ??? ?return "Hello";
?? ?}
?? ?
?? ?public static void main(String[] args) throws InterruptedException, ExecutionException, TimeoutException {
?? ??? ?TestCommand command = new TestCommand(HystrixCommandGroupKey.Factory.asKey("TestGroup"));
?? ??? ?
?? ??? ?//1.這個是同步調(diào)用
?? ??? ?command.execute();
?? ??? ?
?? ??? ?//2.這個是異步調(diào)用
?? ??? ?command.queue().get(500, TimeUnit.MILLISECONDS);
?? ??? ?
?? ??? ?//3.異步回調(diào)
?? ??? ?command.observe().subscribe(new Action1<String>() {
?? ??? ??? ?public void call(String arg0) {
?? ??? ??? ??? ?
?? ??? ??? ?}
?? ??? ?});
?? ?}
}
細(xì)心的同學(xué)肯定發(fā)現(xiàn)Command機制里大量使用了Observable相關(guān)的API，這個是什么呢？原來其隸屬于RxJava，這個框架就不多介紹了 --- 響應(yīng)式開發(fā)，也是Netflix的作品之一，具體大家可參考這系列博客，我覺得作者寫的很通俗：http://blog.csdn.net/lzyzsd/article/details/41833541/
接著呢，大家一定會問，那之前說的熔斷閾值設(shè)置等，都在哪塊做的呢？再來看看另一塊核心代碼：
public abstract class HystrixPropertiesStrategy {
?
? ? public HystrixCommandProperties getCommandProperties(HystrixCommandKey commandKey, HystrixCommandProperties.Setter builder) {
? ? ? ? return new HystrixPropertiesCommandDefault(commandKey, builder);
? ? }
?
? ? ......
}
這個類作為策略類，返回相關(guān)的屬性配置，大家可重新實現(xiàn)。而在具體的策略中，主要包括以下幾種策略屬性配置：
circuitBreakerEnabled：是否允許熔斷，默認(rèn)允許；
circuitBreakerRequestVolumeThreshold：熔斷器是否開啟的閥值，也就是說單位時間超過了閥值請求數(shù)，熔斷器才開；
circuitBreakerSleepWindowInMilliseconds：熔斷器默認(rèn)工作時間，超過此時間會進(jìn)入半開狀態(tài)，即允許流量做嘗試；
circuitBreakerErrorThresholdPercentage：錯誤比例觸發(fā)熔斷；
......
屬性很多，這里就不一一說明了，大家可參考HystrixCommandProperties類里的詳細(xì)定義。還有一點要著重說明的，在熔斷器的設(shè)計里，隔離采用了線程的方式（據(jù)說還有信號的方式，這兩個區(qū)別我還沒搞太明白），處理依賴并發(fā)和阻塞擴展，示意圖如下：
?? ?
如上圖，好處也很明顯，對于每個依賴都有獨立可控的線程池，當(dāng)然高并發(fā)時，CPU切換較多，有一定的影響。
啰嗦了一堆，最后總結(jié)一下，我認(rèn)為服務(wù)熔斷和服務(wù)降級兩者是有區(qū)別的，同時通過對Hystrix的簡單學(xué)習(xí)，了解了其實現(xiàn)機制，會逐步引入到我們的產(chǎn)品研發(fā)中。當(dāng)然還有好多概念：服務(wù)限流、分流，請求與依賴分離等，后面有時間一一與大家分享。?
---------------------?
作者：guwei9111986?
來源：CSDN?
原文：https://blog.csdn.net/guwei9111986/article/details/51649240?
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！

總結(jié)

以上是生活随笔為你收集整理的谈谈我对服务熔断、服务降级的理解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。