談談我對服務熔斷、服務降級的理解專題

本文轉載自查看原文 2017-01-24 11:19 24017 服務熔斷服務降級 Resilience4J Sentinel Hystrix/ 專題

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

其實對老外的總結能力一直特別崇拜，Kevin Kelly、Martin Fowler、Werner Vogels……，都是著名的“演講家”。正好這段時間看了些微服務、容器的相關資料，也在我們新一代產品中進行了部分實踐，回過頭來，再來談談對一些概念的理解。

今天先來說說“服務熔斷”和“服務降級”。為什么要說這個呢，因為我很長時間里都把這兩個概念同質化了，不知道這兩個詞大家怎么理解，一個意思or有所不同？現在的我是這么來看的：

在股票市場，熔斷這個詞大家都不陌生，是指當股指波幅達到某個點后，交易所為控制風險采取的暫停交易措施。相應的，服務熔斷一般是指軟件系統中，由於某些原因使得服務出現了過載現象，為防止造成整個系統故障，從而采用的一種保護措施，所以很多地方把熔斷亦稱為過載保護。
大家都見過女生旅行吧，大號的旅行箱是必備物，平常走走近處綽綽有余，但一旦出個遠門，再大的箱子都白搭了，怎么辦呢？常見的情景就是把物品拿出來分分堆，比了又比，最后一些非必需品的就忍痛放下了，等到下次箱子夠用了，再帶上用一用。而服務降級，就是這么回事，整體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啟回來。

所以從上述分析來看，兩者其實從有些角度看是有一定的類似性的：

目的很一致，都是從可用性可靠性着想，為防止系統的整體緩慢甚至崩潰，采用的技術手段；
最終表現類似，對於兩者來說，最終讓用戶體驗到的是某些功能暫時不可達或不可用；
粒度一般都是服務級別，當然，業界也有不少更細粒度的做法，比如做到數據持久層（允許查詢，不允許增刪改）；
自治性要求很高，熔斷模式一般都是服務基於策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；

而兩者的區別也是明顯的：

觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
實現方式不太一樣，這個區別后面會單獨來說；

當然這只是我個人對兩者的理解，外面把兩者歸為完全一致的也不在少數，或者把熔斷機制理解為應對降級目標的一種實現也說的過去，可能“一討論就吵架”也正是這個原因吧！
概念算是說完了，避免空談，我再總結下對常用的實現方法的理解。對於這兩個概念，號稱支持的框架可不少，Hystrix當屬其中的佼佼者。
先說說最裸的熔斷器的設計思路，下面這張圖大家應該不陌生（我只是參考着又畫了畫），簡明扼要的給出了好的熔斷器實現的三個狀態機：

Closed：熔斷器關閉狀態，調用失敗次數積累，到了閾值（或一定比例）則啟動熔斷機制；
Open：熔斷器打開狀態，此時對下游的調用都內部直接返回錯誤，不走網絡，但設計了一個時鍾選項，默認的時鍾達到了一定時間（這個時間一般設置成平均故障處理時間，也就是MTTR），到了這個時間，進入半熔斷狀態；
Half-Open：半熔斷狀態，允許定量的服務請求，如果調用都成功（或一定比例）則認為恢復了，關閉熔斷器，否則認為還沒好，又回到熔斷器打開狀態；

那Hystrix，作為Netflix開源框架中的最受喜愛組件之一，是怎么處理依賴隔離，實現熔斷機制的呢，他的處理遠比我上面說個實現機制復雜的多。

一起來看看核心代碼吧，我只保留了代碼片段的關鍵部分：

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模式進行調用的，顯然，這個Command負責了核心的服務熔斷和降級的處理，子類要實現的方法主要有兩個：

run方法：實現依賴的邏輯，或者說是實現微服務之間的調用；
getFallBack方法：實現服務降級處理邏輯，只做熔斷處理的則可不實現；

使用時，可參考如下方式：

public class TestCommand extends HystrixCommand<String> {  
  
    protected TestCommand(HystrixCommandGroupKey group) {  
        super(group);  
    }  
  
    @Override  
    protected String run() throws Exception {  
        //這里需要做實際調用邏輯  
        return "Hello";  
    }  
      
    public static void main(String[] args) throws InterruptedException, ExecutionException, TimeoutException {  
        TestCommand command = new TestCommand(HystrixCommandGroupKey.Factory.asKey("TestGroup"));  
          
        //1.這個是同步調用  
        command.execute();  
          
        //2.這個是異步調用  
        command.queue().get(500, TimeUnit.MILLISECONDS);  
          
        //3.異步回調  
        command.observe().subscribe(new Action1<String>() {  
            public void call(String arg0) {  
                  
            }  
        });  
    }  
}

細心的同學肯定發現Command機制里大量使用了Observable相關的API，這個是什么呢？原來其隸屬於RxJava，這個框架就不多介紹了 --- 響應式開發，也是Netflix的作品之一，具體大家可參考這系列博客，我覺得作者寫的很通俗：http://blog.csdn.net/lzyzsd/article/details/41833541/

接着呢，大家一定會問，那之前說的熔斷閾值設置等，都在哪塊做的呢？再來看看另一塊核心代碼：

public abstract class HystrixPropertiesStrategy {  
  
    public HystrixCommandProperties getCommandProperties(HystrixCommandKey commandKey, HystrixCommandProperties.Setter builder) {  
        return new HystrixPropertiesCommandDefault(commandKey, builder);  
    }  
  
    ......  
}

這個類作為策略類，返回相關的屬性配置，大家可重新實現。而在具體的策略中，主要包括以下幾種策略屬性配置：

circuitBreakerEnabled：是否允許熔斷，默認允許；
circuitBreakerRequestVolumeThreshold：熔斷器是否開啟的閥值，也就是說單位時間超過了閥值請求數，熔斷器才開；
circuitBreakerSleepWindowInMilliseconds：熔斷器默認工作時間，超過此時間會進入半開狀態，即允許流量做嘗試；
circuitBreakerErrorThresholdPercentage：錯誤比例觸發熔斷；
......

屬性很多，這里就不一一說明了，大家可參考HystrixCommandProperties類里的詳細定義。還有一點要着重說明的，在熔斷器的設計里，隔離采用了線程的方式（據說還有信號的方式，這兩個區別我還沒搞太明白），處理依賴並發和阻塞擴展，示意圖如下：

如上圖，好處也很明顯，對於每個依賴都有獨立可控的線程池，當然高並發時，CPU切換較多，有一定的影響。

啰嗦了一堆，最后總結一下，我認為服務熔斷和服務降級兩者是有區別的，同時通過對Hystrix的簡單學習，了解了其實現機制，會逐步引入到我們的產品研發中。當然還有好多概念：服務限流、分流，請求與依賴分離等，后面有時間一一與大家分享。 
http://blog.csdn.net/guwei9111986/article/details/51649240
http://www.primeton.com/read.php?id=2230&his=1

Sentinel: 分布式系統的流量防衛兵

Sentinel 是什么？

隨着微服務的流行，服務和服務之間的穩定性變得越來越重要。Sentinel 以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。

Sentinel 具有以下特征:

豐富的應用場景：Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺（即突發流量控制在系統容量可以承受的范圍）、消息削峰填谷、集群流量控制、實時熔斷下游不可用應用等。
完備的實時監控：Sentinel 同時提供實時的監控功能。您可以在控制台中看到接入應用的單台機器秒級數據，甚至 500 台以下規模的集群的匯總運行情況。
廣泛的開源生態：Sentinel 提供開箱即用的與其它開源框架/庫的整合模塊，例如與 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相應的依賴並進行簡單的配置即可快速地接入 Sentinel。
完善的 SPI 擴展點：Sentinel 提供簡單易用、完善的 SPI 擴展接口。您可以通過實現擴展接口來快速地定制邏輯。例如定制規則管理、適配動態數據源等。

Sentinel 的主要特性：

Sentinel 的開源生態：

Sentinel 分為兩個部分:

核心庫（Java 客戶端）不依賴任何框架/庫，能夠運行於所有 Java 運行時環境，同時對 Dubbo / Spring Cloud 等框架也有較好的支持。
控制台（Dashboard）基於 Spring Boot 開發，打包后可以直接運行，不需要額外的 Tomcat 等應用容器。

Quick Start

1.1 公網Demo:

如果你想最快的了解Sentinel在做什么，你可以通過Sentinel 新手指南來運行一個例子，並且能在控制台上看到最直觀的監控，流控效果等。

1.2 手動接入Sentinel以及Dashboard

下面的例子將展示應用如何三步接入 Sentinel。同時，Sentinel 也提供所見即所得的控制台，可以實時監控資源以及管理規則。

STEP 1. 在應用中引入Sentinel Jar包

如果應用使用 pom 工程，則在 pom.xml 文件中加入以下代碼即可：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-core</artifactId>
    <version>x.y.z</version>
</dependency>

注意: Sentinel 僅支持 Java 6 或者以上版本。如果您未使用依賴管理工具，請到 Maven Center Repository 直接下載 JAR 包。

STEP 2. 定義資源

接下來，把需要控制流量的代碼用 Sentinel API SphU.entry("HelloWorld") 和 entry.exit() 包圍起來即可。在下面的例子中，我們將 System.out.println("hello wolrd"); 作為資源，用 API 包圍起來。參考代碼如下:

public static void main(String[] args) {
    initFlowRules();
    while (true) {
        Entry entry = null;
        try {
        entry = SphU.entry("HelloWorld");
            /*您的業務邏輯 - 開始*/
            System.out.println("hello world");
            /*您的業務邏輯 - 結束*/
    } catch (BlockException e1) {
            /*流控邏輯處理 - 開始*/
        System.out.println("block!");
            /*流控邏輯處理 - 結束*/
    } finally {
       if (entry != null) {
           entry.exit();
       }
    }
    }
}

完成以上兩步后，代碼端的改造就完成了。當然，我們也提供了注解支持模塊，可以以低侵入性的方式定義資源。

STEP 3. 定義規則

接下來，通過規則來指定允許該資源通過的請求次數，例如下面的代碼定義了資源 HelloWorld 每秒最多只能通過 20 個請求。

private static void initFlowRules(){
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule = new FlowRule();
    rule.setResource("HelloWorld");
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    // Set limit QPS to 20.
    rule.setCount(20);
    rules.add(rule);
    FlowRuleManager.loadRules(rules);
}

完成上面 3 步，Sentinel 就能夠正常工作了。更多的信息可以參考使用文檔。

STEP 4. 檢查效果

Demo 運行之后，我們可以在日志 ~/logs/csp/${appName}-metrics.log.xxx 里看到下面的輸出:

|--timestamp-|------date time----|--resource-|p |block|s |e|rt
1529998904000|2018-06-26 15:41:44|hello world|20|0    |20|0|0
1529998905000|2018-06-26 15:41:45|hello world|20|5579 |20|0|728
1529998906000|2018-06-26 15:41:46|hello world|20|15698|20|0|0
1529998907000|2018-06-26 15:41:47|hello world|20|19262|20|0|0
1529998908000|2018-06-26 15:41:48|hello world|20|19502|20|0|0
1529998909000|2018-06-26 15:41:49|hello world|20|18386|20|0|0

其中 p 代表通過的請求, block 代表被阻止的請求, s 代表成功執行完成的請求個數, e 代表用戶自定義的異常, rt 代表平均響應時長。

可以看到，這個程序每秒穩定輸出 "hello world" 20 次，和規則中預先設定的閾值是一樣的。

更詳細的說明可以參考: 如何使用

更多的例子可以參考: Demo

STEP 5. 啟動 Sentinel 控制台

您可以參考 Sentinel 控制台文檔啟動控制台，可以實時監控各個資源的運行情況，並且可以實時地修改限流規則。

詳細文檔

請移步 Wiki，查閱詳細的文檔、示例以及使用說明。若您希望從其它熔斷降級組件（如 Hystrix）遷移或進行功能對比，可以參考遷移指南。

Please refer to README for README in English。

與 Sentinel 相關的生態（包括社區用戶實現的擴展、整合、示例以及文章）可以參見 Awesome Sentinel，歡迎補充！

如果您正在使用 Sentinel，歡迎在 Wanted: Who is using Sentinel 留言告訴我們您的使用場景，以便我們更好地去改進。

https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D

Sentinel 與 Hystrix 的對比

Sentinel 是阿里中間件團隊研發的面向分布式服務架構的輕量級高可用流量控制組件，最近正式開源。Sentinel 主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助用戶保護服務的穩定性。大家可能會問：Sentinel 和之前常用的熔斷降級庫 Netflix Hystrix 有什么異同呢？本文將從多個角度對 Sentinel 和 Hystrix 進行對比，幫助大家進行技術選型。

Overview

先來看一下 Hystrix 的官方介紹：

Hystrix is a library that helps you control the interactions between these distributed services by adding latency tolerance and fault tolerance logic. Hystrix does this by isolating points of access between the services, stopping cascading failures across them, and providing fallback options, all of which improve your system’s overall resiliency.

可以看到 Hystrix 的關注點在於以隔離和熔斷為主的容錯機制，超時或被熔斷的調用將會快速失敗，並可以提供 fallback 機制。

而 Sentinel 的側重點在於：

多樣化的流量控制
熔斷降級
系統負載保護
實時監控和控制台

可以看到兩者解決的問題還是有比較大的不同的，下面我們來分別對比一下。

共同特性

資源模型和執行模型上的對比

Hystrix 的資源模型設計上采用了命令模式，將對外部資源的調用和 fallback 邏輯封裝成一個命令對象（HystrixCommand / HystrixObservableCommand），其底層的執行是基於 RxJava 實現的。每個 Command 創建時都要指定 commandKey 和 groupKey（用於區分資源）以及對應的隔離策略（線程池隔離 or 信號量隔離）。線程池隔離模式下需要配置線程池對應的參數（線程池名稱、容量、排隊超時等），然后 Command 就會在指定的線程池按照指定的容錯策略執行；信號量隔離模式下需要配置最大並發數，執行 Command 時 Hystrix 就會限制其並發調用。

Sentinel 的設計則更為簡單。相比 Hystrix Command 強依賴隔離規則，Sentinel 的資源定義與規則配置的耦合度更低。Hystrix 的 Command 強依賴於隔離規則配置的原因是隔離規則會直接影響 Command 的執行。在執行的時候 Hystrix 會解析 Command 的隔離規則來創建 RxJava Scheduler 並在其上調度執行，若是線程池模式則 Scheduler 底層的線程池為配置的線程池，若是信號量模式則簡單包裝成當前線程執行的 Scheduler。而 Sentinel 並不指定執行模型，也不關注應用是如何執行的。Sentinel 的原則非常簡單：根據對應資源配置的規則來為資源執行相應的限流/降級/負載保護策略。在 Sentinel 中資源定義和規則配置是分離的。用戶先通過 Sentinel API 給對應的業務邏輯定義資源（埋點），然后可以在需要的時候配置規則。埋點方式有兩種：

try-catch 方式（通過 SphU.entry(...)），用戶在 catch 塊中執行異常處理 / fallback
if-else 方式（通過 SphO.entry(...)），當返回 false 時執行異常處理 / fallback

未來 Sentinel 還會引入基於注解的資源定義方式，同時可以通過注解參數指定異常處理函數和 fallback 函數。

Sentinel 提供多樣化的規則配置方式。除了直接通過 loadRules API 將規則注冊到內存態之外，用戶還可以注冊各種外部數據源來提供動態的規則。用戶可以根據系統當前的實時情況去動態地變更規則配置，數據源會將變更推送至 Sentinel 並即時生效。

隔離設計上的對比

隔離是 Hystrix 的核心功能之一。Hystrix 提供兩種隔離策略：線程池隔離（Bulkhead Pattern）和信號量隔離，其中最推薦也是最常用的是線程池隔離。Hystrix 的線程池隔離針對不同的資源分別創建不同的線程池，不同服務調用都發生在不同的線程池中，在線程池排隊、超時等阻塞情況時可以快速失敗，並可以提供 fallback 機制。線程池隔離的好處是隔離度比較高，可以針對某個資源的線程池去進行處理而不影響其它資源，但是代價就是線程上下文切換的 overhead 比較大，特別是對低延時的調用有比較大的影響。

但是，實際情況下，線程池隔離並沒有帶來非常多的好處。首先就是過多的線程池會非常影響性能。考慮這樣一個場景，在 Tomcat 之類的 Servlet 容器使用 Hystrix，本身 Tomcat 自身的線程數目就非常多了（可能到幾十或一百多），如果加上 Hystrix 為各個資源創建的線程池，總共線程數目會非常多（幾百個線程），這樣上下文切換會有非常大的損耗。另外，線程池模式比較徹底的隔離性使得 Hystrix 可以針對不同資源線程池的排隊、超時情況分別進行處理，但這其實是超時熔斷和流量控制要解決的問題，如果組件具備了超時熔斷和流量控制的能力，線程池隔離就顯得沒有那么必要了。

Sentinel 可以通過並發線程數模式的流量控制來提供信號量隔離的功能。這樣的隔離非常輕量級，僅限制對某個資源調用的並發數，而不是顯式地去創建線程池，所以 overhead 比較小，但是效果不錯。並且結合基於響應時間的熔斷降級模式，可以在不穩定資源的平均響應時間比較高的時候自動降級，防止過多的慢調用占滿並發數，影響整個系統。而 Hystrix 的信號量隔離比較簡單，無法對慢調用自動進行降級，只能等待客戶端自己超時，因此仍然可能會出現級聯阻塞的情況。

熔斷降級對比

Sentinel 和 Hystrix 的熔斷降級功能本質上都是基於熔斷器模式（Circuit Breaker Pattern）。Sentinel 與 Hystrix 都支持基於失敗比率（異常比率）的熔斷降級，在調用達到一定量級並且失敗比率達到設定的閾值時自動進行熔斷，此時所有對該資源的調用都會被 block，直到過了指定的時間窗口后才啟發性地恢復。上面提到過，Sentinel 還支持基於平均響應時間的熔斷降級，可以在服務響應時間持續飆高的時候自動熔斷，拒絕掉更多的請求，直到一段時間后才恢復。這樣可以防止調用非常慢造成級聯阻塞的情況。

實時指標統計實現對比

Hystrix 和 Sentinel 的實時指標數據統計實現都是基於滑動窗口的。Hystrix 1.5 之前的版本是通過環形數組實現的滑動窗口，通過鎖配合 CAS 的操作對每個桶的統計信息進行更新。Hystrix 1.5 開始對實時指標統計的實現進行了重構，將指標統計數據結構抽象成了響應式流（reactive stream）的形式，方便消費者去利用指標信息。同時底層改造成了基於 RxJava 的事件驅動模式，在服務調用成功/失敗/超時的時候發布相應的事件，通過一系列的變換和聚合最終得到實時的指標統計數據流，可以被熔斷器或 Dashboard 消費。

Sentinel 目前抽象出了 Metric 指標統計接口，底層可以有不同的實現，目前默認的實現是基於 LeapArray 的滑動窗口，后續根據需要可能會引入 reactive stream 等實現。

Sentinel 的特色

除了之前提到的兩者的共同特性之外，Sentinel 還提供以下的特色功能：

輕量級、高性能

Sentinel 作為一個功能完備的高可用流量管控組件，其核心 sentinel-core 沒有任何多余依賴，打包后只有不到 200 KB，非常輕量級。開發者可以放心地引入 sentinel-core 而不需擔心依賴問題。同時，Sentinel 提供了多種擴展點，用戶可以很方便地根據需求去進行擴展，並且無縫地切合到 Sentinel 中。

引入 Sentinel 帶來的性能損耗非常小。只有在業務單機量級超過 25W QPS 的時候才會有一些顯著的影響（5% - 10% 左右），單機 QPS 不太大的時候損耗幾乎可以忽略不計。

流量控制

Sentinel 可以針對不同的調用關系，以不同的運行指標（如 QPS、並發調用數、系統負載等）為基准，對資源調用進行流量控制，將隨機的請求調整成合適的形狀。

Sentinel 支持多樣化的流量整形策略，在 QPS 過高的時候可以自動將流量調整成合適的形狀。常用的有：

直接拒絕模式：即超出的請求直接拒絕。
慢啟動預熱模式：當流量激增的時候，控制流量通過的速率，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。

勻速器模式：利用 Leaky Bucket 算法實現的勻速模式，嚴格控制了請求通過的時間間隔，同時堆積的請求將會排隊，超過超時時長的請求直接被拒絕。

Sentinel 還支持基於調用關系的限流，包括基於調用方限流、基於調用鏈入口限流、關聯流量限流等，依托於 Sentinel 強大的調用鏈路統計信息，可以提供精准的不同維度的限流。

目前 Sentinel 對異步調用鏈路的支持還不是很好，后續版本會着重改善支持異步調用。

系統負載保護

Sentinel 對系統的維度提供保護，負載保護算法借鑒了 TCP BBR 的思想。當系統負載較高的時候，如果仍持續讓請求進入，可能會導致系統崩潰，無法響應。在集群環境下，網絡負載均衡會把本應這台機器承載的流量轉發到其它的機器上去。如果這個時候其它的機器也處在一個邊緣狀態的時候，這個增加的流量就會導致這台機器也崩潰，最后導致整個集群不可用。針對這個情況，Sentinel 提供了對應的保護機制，讓系統的入口流量和系統的負載達到一個平衡，保證系統在能力范圍之內處理最多的請求。

實時監控與控制面板

Sentinel 提供 HTTP API 用於獲取實時的監控信息，如調用鏈路統計信息、簇點信息、規則信息等。如果用戶正在使用 Spring Boot/Spring Cloud 並使用了 Sentinel Spring Cloud Starter，還可以方便地通過其暴露的 Actuator Endpoint 來獲取運行時的一些信息，如動態規則等。未來 Sentinel 還會支持標准化的指標監控 API，可以方便地整合各種監控系統和可視化系統，如 Prometheus、Grafana 等。

Sentinel 控制台（Dashboard）提供了機器發現、配置規則、查看實時監控、查看調用鏈路信息等功能，使得用戶可以非常方便地去查看監控和進行配置。

生態

Sentinel 目前已經針對 Servlet、Dubbo、Spring Boot/Spring Cloud、gRPC 等進行了適配，用戶只需引入相應依賴並進行簡單配置即可非常方便地享受 Sentinel 的高可用流量防護能力。未來 Sentinel 還會對更多常用框架進行適配，並且會為 Service Mesh 提供集群流量防護的能力。

總結

最后用表格來進行對比總結：

	Sentinel	Hystrix
隔離策略	基於並發數	線程池隔離/信號量隔離
熔斷降級策略	基於響應時間或失敗比率	基於失敗比率
實時指標實現	滑動窗口	滑動窗口（基於 RxJava）
規則配置	支持多種數據源	支持多種數據源
擴展性	多個擴展點	插件的形式
基於注解的支持	即將發布	支持
調用鏈路信息	支持同步調用	不支持
限流	基於 QPS / 並發數，支持基於調用關系的限流	不支持
流量整形	支持慢啟動、勻速器模式	不支持
系統負載保護	支持	不支持
實時監控 API	各式各樣	較為簡單
控制台	開箱即用，可配置規則、查看秒級監控、機器發現等	不完善
常見框架的適配	Servlet、Spring Cloud、Dubbo、gRPC 等	Servlet、Spring Cloud Netflix

若有 Sentinel 設計上的疑問或討論，歡迎來提 issue。若對 Sentinel 的開發感興趣，不要猶豫，歡迎加入我們，我們隨時歡迎貢獻！

https://yq.aliyun.com/articles/623424

2017-12-15 發布

Hystrix工作原理（官方文檔翻譯）

工作流程圖

下面的流程圖展示了當使用Hystrix的依賴請求，Hystrix是如何工作的。

下面將更詳細的解析每一個步驟都發生哪些動作：

構建一個HystrixCommand或者HystrixObservableCommand對象。

第一步就是構建一個HystrixCommand或者HystrixObservableCommand對象，該對象將代表你的一個依賴請求，向構造函數中傳入請求依賴所需要的參數。

如果構建HystrixCommand中的依賴返回單個響應，例如：
```
HystrixCommand command = new HystrixCommand(arg1, arg2);
```
如果依賴需要返回一個Observable來發射響應，就需要通過構建HystrixObservableCommand對象來完成，例如：
```
HystrixObservableCommand command = new HystrixObservableCommand(arg1, arg2);
```
執行命令

有4種方式可以執行一個Hystrix命令。
- execute()—該方法是阻塞的，從依賴請求中接收到單個響應（或者出錯時拋出異常）。
- queue()—從依賴請求中返回一個包含單個響應的Future對象。
- observe()—訂閱一個從依賴請求中返回的代表響應的Observable對象。
- toObservable()—返回一個Observable對象，只有當你訂閱它時，它才會執行Hystrix命令並發射響應。
```
K             value   = command.execute();
Future<K>     fValue  = command.queue();
Observable<K> ohValue = command.observe();         //hot observable Observable<K> ocValue = command.toObservable(); //cold observable
```

同步調用方法execute()實際上就是調用queue().get()方法，queue()方法的調用的是toObservable().toBlocking().toFuture().也就是說，最終每一個HystrixCommand都是通過Observable來實現的，即使這些命令僅僅是返回一個簡單的單個值。

響應是否被緩存
如果這個命令的請求緩存已經開啟，並且本次請求的響應已經存在於緩存中，那么就會立即返回一個包含緩存響應的Observable（下面將Request Cache部分將對請求的cache做講解）。
回路器是否打開
當命令執行執行時，Hystrix會檢查回路器是否被打開。

如果回路器被打開（或者tripped），那么Hystrix就不會再執行命名，而是直接路由到第8步，獲取fallback方法，並執行fallback邏輯。

如果回路器關閉，那么將進入第5步，檢查是否有足夠的容量來執行任務。（其中容量包括線程池的容量，隊列的容量等等）。
線程池、隊列、信號量是否已滿
如果與該命令相關的線程池或者隊列已經滿了，那么Hystrix就不會再執行命令，而是立即跳到第8步,執行fallback邏輯。
HystrixObservableCommand.construct() 或者 HystrixCommand.run()

在這里，Hystrix通過你寫的方法邏輯來調用對依賴的請求，通過下列之一的調用：
- HystrixCommand.run()—返回單個響應或者拋出異常。
- HystrixObservableCommand.construct() —返回一個發射響應的Observable或者發送一個onError()的通知。
  如果執行run()方法或者construct()方法的執行時間大於命令所設置的超時時間值，那么該線程將會拋出一個TimeoutException異常（或者如果該命令沒有運行在它自己的線程中，[or a separate timer thread will, if the command itself is not running in its own thread]）。在這種情況下，Hystrix將會路由到第8步，執行fallback邏輯，並且如果run()或者construct()方法沒有被取消或者中斷，會丟棄這兩個方法最終返回的結果。
  
  請注意，沒有任何方式可以強制終止一個潛在[latent]的線程的運行，Hystrix能夠做的最好的方式是讓JVM拋出一個InterruptedException異常，如果你的任務被Hystrix所包裝，並不意味着會拋出一個InterruptedExceptions異常，該線程在Hystrix的線程池內會進行執行，雖然在客戶端已經接收到了TimeoutException異常，這個行為能夠滲透到Hystrix的線程池中，[though the load is 'correctly shed']，絕大多數的Http Client不會將這一行為視為InterruptedExceptions，所以，請確保正確配置連接或者讀取/寫入的超時時間。
  
  如果命令最終返回了響應並且沒有拋出任何異常，Hystrix在返回響應后會執行一些log和指標的上報，如果是調用run()方法，Hystrix會返回一個Observable，該Observable會發射單個響應並且會調用onCompleted方法來通知響應的回調，如果是調用construct()方法，Hystrix會通過construct()方法返回相同的Observable對象。
計算回路指標[Circuit Health]
Hystrix會報告成功、失敗、拒絕和超時的指標給回路器，回路器包含了一系列的滑動窗口數據，並通過該數據進行統計。

它使用這些統計數據來決定回路器是否應該熔斷，如果需要熔斷，將在一定的時間內不在請求依賴[短路請求]（譯者：這一定的時候可以通過配置指定），當再一次檢查請求的健康的話會重新關閉回路器。
獲取FallBack

當命令執行失敗時，Hystrix會嘗試執行自定義的Fallback邏輯：
- 當construct()或者run()方法執行過程中拋出異常。
- 當回路器打開，命令的執行進入了熔斷狀態。
- 當命令執行的線程池和隊列或者信號量已經滿容。
- 命令執行超時。

寫一個fallback方法，提供一個不需要網絡依賴的通用響應，從內存緩存或者其他的靜態邏輯獲取數據。如果再fallback內必須需要網絡的調用，更好的做法是使用另一個HystrixCommand或者HystrixObservableCommand。

如果你的命令是繼承自HystrixCommand，那么可以通過實現HystrixCommand.getFallback()方法返回一個單個的fallback值。

如果你的命令是繼承自HystrixObservableCommand，那么可以通過實現HystrixObservableCommand.resumeWithFallback()方法返回一個Observable，並且該Observable能夠發射出一個fallback值。

Hystrix會把fallback方法返回的響應返回給調用者。

如果你沒有為你的命令實現fallback方法，那么當命令拋出異常時，Hystrix仍然會返回一個Observable，但是該Observable並不會發射任何的數據，並且會立即終止並調用onError()通知。通過這個onError通知，可以將造成該命令拋出異常的原因返回給調用者。

失敗或不存在回退的結果將根據您如何調用Hystrix命令而有所不同：

- execute()：拋出一個異常。
- queue()：成功返回一個Future，但是如果調用get()方法，將會拋出一個異常。
- observe()：返回一個Observable，當你訂閱它時，它將立即終止，並調用onError()方法。
- toObservable()：返回一個Observable，當你訂閱它時，它將立即終止，並調用onError()方法。
返回成功的響應
如果Hystrix命令執行成功，它將以Observable形式返回響應給調用者。根據你在第2步的調用方式不同，在返回Observablez之前可能會做一些轉換。

execute()：通過調用queue()來得到一個Future對象，然后調用get()方法來獲取Future中包含的值。
queue()：將Observable轉換成BlockingObservable，在將BlockingObservable轉換成一個Future。
observe()：訂閱返回的Observable，並且立即開始執行命令的邏輯，
toObservable()：返回一個沒有改變的Observable，你必須訂閱它，它才能夠開始執行命令的邏輯。

回路器

下面的圖展示了HystrixCommand和HystrixObservableCommand如何與HystrixCircuitBroker進行交互。

回路器打開和關閉有如下幾種情況：

假設回路中的請求滿足了一定的閾值（HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()）
假設錯誤發生的百分比超過了設定的錯誤發生的閾值HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()
回路器狀態由CLOSE變換成OPEN
如果回路器打開，所有的請求都會被回路器所熔斷。
一定時間之后HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()，下一個的請求會被通過（處於半打開狀態），如果該請求執行失敗，回路器會在睡眠窗口期間返回OPEN，如果請求成功，回路器會被置為關閉狀態，重新開啟1步驟的邏輯。

隔離

Hystrix采用艙壁模式來隔離相互之間的依賴關系，並限制對其中任何一個的並發訪問。

線程和線程池
客戶端（第三方包、網絡調用等）會在單獨的線程執行，會與調用的該任務的線程進行隔離，以此來防止調用者調用依賴所消耗的時間過長而阻塞調用者的線程。

[Hystrix uses separate, per-dependency thread pools as a way of constraining any given dependency so latency on the underlying executions will saturate the available threads only in that pool]

您可以在不使用線程池的情況下防止出現故障，但是這要求客戶端必須能夠做到快速失敗（網絡連接/讀取超時和重試配置），並始終保持良好的執行狀態。

Netflix，設計Hystrix，並且選擇使用線程和線程池來實現隔離機制，有以下幾個原因：

很多應用會調用多個不同的后端服務作為依賴。
每個服務會提供自己的客戶端庫包。
每個客戶端的庫包都會不斷的處於變更狀態。
[Client library logic can change to add new network calls]
每個客戶端庫包都可能包含重試、數據解析、緩存等等其他邏輯。
對用戶來說，客戶端庫往往是“黑盒”的，對於實現細節、網絡訪問模式。默認配置等都是不透明的。
[In several real-world production outages the determination was “oh, something changed and properties should be adjusted” or “the client library changed its behavior.]
即使客戶端本身沒有改變，服務本身也可能發生變化，這些因素都會影響到服務的性能，從而導致客戶端配置失效。
傳遞依賴可以引入其他客戶端庫，這些客戶端庫不是預期的，也許沒有正確配置。
大部分的網絡訪問是同步執行的。
客戶端代碼中也可能出現失敗和延遲，而不僅僅是在網絡調用中。

使用線程池的好處

通過線程在自己的線程池中隔離的好處是：
- 該應用程序完全可以不受失控的客戶端庫的威脅。即使某一個依賴的線程池已滿也不會影響其他依賴的調用。
- 應用程序可以低風險的接受新的客戶端庫的數據，如果發生問題，它會與出問題的客戶端庫所隔離，不會影響其他依賴的任何內容。
- 當失敗的客戶端服務恢復時，線程池將會被清除，應用程序也會恢復，而不至於使得我們整個Tomcat容器出現故障。
- 如果一個客戶端庫的配置錯誤，線程池可以很快的感知這一錯誤（通過增加錯誤比例，延遲，超時，拒絕等），並可以在不影響應用程序的功能情況下來處理這些問題（可以通過動態配置來進行實時的改變）。
- 如果一個客戶端服務的性能變差，可以通過改變線程池的指標（錯誤、延遲、超時、拒絕）來進行屬性的調整，並且這些調整可以不影響其他的客戶端請求。
- 除了隔離的優勢之外，擁有專用的線程池可以提供內置的請求任務的並發性，可以在同步客戶端上構建異步門面。

簡而言之，由線程池提供的隔離功能可以使客戶端庫和子系統性能特性的不斷變化和動態組合得到優雅的處理，而不會造成中斷。

注意：雖然單獨的線程提供了隔離，但您的底層客戶端代碼也應該有超時和/或響應線程中斷，而不能讓Hystrix的線程池處於無休止的等待狀態。

線程池的缺點
線程池最主要的缺點就是增加了CPU的計算開銷，每個命令都會在單獨的線程池上執行，這樣的執行方式會涉及到命令的排隊、調度和上下文切換。

Netflix在設計這個系統時，決定接受這個開銷的代價，來換取它所提供的好處，並且認為這個開銷是足夠小的，不會有重大的成本或者是性能影響。
線程成本
Hystrix在子線程執行construct()方法和run()方法時會計算延遲，以及計算父線程從端到端的執行總時間。所以，你可以看到Hystrix開銷成本包括（線程、度量，日志，斷路器等）。

Netflix API每天使用線程隔離的方式處理10億多的Hystrix Command任務，每個API實例都有40多個線程池，每個線程池都有5-20個線程（大多數設置為10）

下圖顯示了一個HystrixCommand在單個API實例上每秒執行60個請求（每個服務器每秒執行大約350個線程執行總數）：

在中間位置（或者下線位置）不需要單獨的線程池。

在第90線上，單獨線程的成本為3ms。

在第99線上，單獨的線程花費9ms。但是請注意，線程成本的開銷增加遠小於單獨線程（網絡請求）從2跳到28而執行時間從0跳到9的增加。

對於大多數Netflix用例來說，這樣的請求在90％以上的開銷被認為是可以接受的，這是為了實現韌性的好處。

對於非常低延遲請求（例如那些主要觸發內存緩存的請求），開銷可能太高，在這種情況下，可以使用另一種方法，如信號量，雖然它們不允許超時，提供絕大部分的有點，而不會產生開銷。然而，一般來說，開銷是比較小的，以至於Netflix通常更偏向於通過單獨的線程來作為隔離實現。

請求合並

您可以使用請求合並器（HystrixCollapser是抽象父代）來提前發送HystrixCommand，通過該合並器您可以將多個請求合並為一個后端依賴項調用。

下面的圖展示了兩種情況下的線程數和網絡連接數，第一張圖是不使用請求合並，第二張圖是使用請求合並（假定所有連接在短時間窗口內是“並發的”，在這種情況下是10ms）。

為什么使用請求合並

事情請求合並來減少執行並發HystrixCommand請求所需要的線程數和網絡連接數。請求合並以自動方式執行的，不需要代碼層面上進行批處理請求的編碼。
- 全局上下文（所有的tomcat線程）
  理想的合並方式是在全局應用程序級別來完成的，以便來自任何用戶的任何Tomcat線程的請求都可以一起合並。
  
  例如，如果將HystrixCommand配置為支持任何用戶請求獲取影片評級的依賴項的批處理，那么當同一個JVM中的任何用戶線程發出這樣的請求時，Hystrix會將該請求與其他請求一起合並添加到同一個JVM中的網絡調用。
  
  請注意，合並器會將一個HystrixRequestContext對象傳遞給合並的網絡調用，為了使其成為一個有效選項，下游系統必須處理這種情況。
- 用戶請求上下文（單個tomcat線程）
  如果將HystrixCommand配置為僅處理單個用戶的批處理請求，則Hystrix僅僅會合並單個Tomcat線程的請求。
  
  例如，如果一個用戶想要加載300個影片的標簽，Hystrix能夠把這300次網絡調用合並成一次調用。
- 對象建模和代碼的復雜性
  有時候，當你創建一個對象模型對消費的對象而言是具有邏輯意義的，這與對象的生產者的有效資源利用率不匹配。
  
  例如，給你300個視頻對象，遍歷他們，並且調用他們的getSomeAttribute()方法，但是如果簡單的調用，可能會導致300次網絡調用（可能很快會占滿資源）。
  
  有一些手動的方法可以解決這個問題，比如在用戶調用getSomeAttribute()方法之前，要求用戶聲明他們想要獲取哪些視頻對象的屬性，以便他們都可以被預取。
  
  或者，您可以分割對象模型，以便用戶必須從一個位置獲取視頻列表，然后從其他位置請求該視頻列表的屬性。
  
  這些方法可以會使你的API和對象模型顯得笨拙，並且這種方式也不符合心理模式與使用模式（譯者：不太懂什么意思）。由於多個開發人員在代碼庫上工作，可能會導致低級的錯誤和低效率開發的問題。因為對一個用例的優化可以通過執行另一個用例和通過代碼的新路徑來打破。
  
  通過將合並邏輯移到Hystrix層，不管你如何創建對象模型，調用順序是怎樣的，或者不同的開發人員是否知道是否完成了優化或者是否完成。
  
  getSomeAttribute（）方法可以放在最適合的地方，並以任何適合使用模式的方式被調用，並且合並器會自動將批量調用放置到時間窗口。

####請求Cache

HystrixCommand和HystrixObservableCommand實現可以定義一個緩存鍵，然后用這個緩存鍵以並發感知的方式在請求上下文中取消調用（不需要調用依賴即可以得到結果，因為同樣的請求結果已經按照緩存鍵緩存起來了）。

以下是一個涉及HTTP請求生命周期的示例流程，以及在該請求中執行工作的兩個線程：

請求cache的好處有：

不同的代碼路徑可以執行Hystrix命令，而不用擔心重復的工作。

這在許多開發人員實現不同功能的大型代碼庫中尤其有用。

例如，多個請求路徑都需要獲取用戶的Account對象，可以像這樣請求：

Account account = new UserGetAccount(accountId).execute();
//or
Observable<Account> accountObservable = new UserGetAccount(accountId).observe();

Hystrix RequestCache將只執行一次底層的run（）方法，執行HystrixCommand的兩個線程都會收到相同的數據，盡管實例化了多個不同的實例。

整個請求的數據檢索是一致的。

每次執行該命令時，不再會返回一個不同的值（或回退），而是將第一個響應緩存起來，后續相同的請求將會返回緩存的響應。

消除重復的線程執行。

由於請求緩存位於construct（）或run（）方法調用之前，Hystrix可以在調用線程執行之前取消調用。

如果Hystrix沒有實現請求緩存功能，那么每個命令都需要在構造或者運行方法中實現，這將在一個線程排隊並執行之后進行。

https://segmentfault.com/a/1190000012439580

聲明：本文來源於MLDN培訓視頻的課堂筆記，寫在這里只是為了方便查閱。

1、概念：Hystrix 熔斷機制

2、具體內容

所謂的熔斷機制和日常生活中見到電路保險絲是非常相似的，當出現了問題之后，保險絲會自動燒斷，以保護我們的電器，那么如果換到了程序之中呢？

當現在服務的提供方出現了問題之后整個的程序將出現錯誤的信息顯示，而這個時候如果不想出現這樣的錯誤信息，而希望替換為一個錯誤時的內容。

一個服務掛了后續的服務跟着不能用了，這就是雪崩效應

對於熔斷技術的實現需要考慮以下幾種情況：

· 出現錯誤之后可以 fallback 錯誤的處理信息；

· 如果要結合 Feign 一起使用的時候還需要在 Feign（客戶端）進行熔斷的配置。

2.1、Hystrix 基本配置

1、【microcloud-provider-dept-hystrix-8001】修改 pom.xml 配置文件，追加 Hystrix 配置類：

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
        </dependency>

2、【microcloud-provider-dept-hystrix-8001】修改 DeptRest 程序

package cn.study.microcloud.rest;

import javax.annotation.Resource;

import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;

import cn.study.microcloud.service.IDeptService;
import cn.study.vo.Dept;

@RestController
public class DeptRest {
    @Resource
    private IDeptService deptService;
    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    @HystrixCommand(fallbackMethod="getFallback")    // 如果當前調用的get()方法出現了錯誤，則執行fallback
    public Object get(@PathVariable("id") long id) {
        Dept vo = this.deptService.get(id) ;    // 接收數據庫的查詢結果
        if (vo == null) {    // 數據不存在，假設讓它拋出個錯誤
            throw new RuntimeException("部門信息不存在！") ;
        }
        return vo ;
    }
    public Object getFallback(@PathVariable("id") long id) {    // 此時方法的參數 與get()一致
        Dept vo = new Dept() ;
        vo.setDeptno(999999L);
        vo.setDname("【ERROR】Microcloud-Dept-Hystrix");    // 錯誤的提示
        vo.setLoc("DEPT-Provider");
        return vo ;
    }
    
    
}

一旦 get()方法上拋出了錯誤的信息，那么就認為該服務有問題，會默認使用“@HystrixCommand”注解之中配置好的 fallbackMethod 調用類中的指定方法，返回相應數據。

3、【microcloud-provider-dept-hystrix-8001】在主類之中啟動熔斷處理

package cn.study.microcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
@EnableDiscoveryClient
public class Dept_8001_StartSpringCloudApplication {
    public static void main(String[] args) {
        SpringApplication.run(Dept_8001_StartSpringCloudApplication.class, args);
    }
}

現在的處理情況是：服務器出現了錯誤（但並不表示提供方關閉），那么此時會調用指定方法的 fallback 處理。

2.2、服務降級（服務回退）

所有的 RPC 技術里面服務降級是一個最為重要的話題，所謂的降級指的是當服務的提供方不可使用的時候，程序不會出現異常，而會出現本地的操作調用。

例如：在每年年底 12306 都是最繁忙的時候，那么在這個情況會發現有一些神奇的情況：當到了指定的時間大家開始搶票的時候，如果你不搶，而后查詢一些冷門的車次，票有可能查詢不出來。因為這個時候會將所有的系統資源給搶票調度了，而其它的服務由於其暫時不受到過多的關注，這個時候可以考慮將服務降級（服務暫停）。

服務的降級處理是在客戶端實現的，與你的服務器端沒有關系。

1、【microcloud-service】擴充一個 IDeptService 的失敗調用（服務降級）處理：

package cn.study.service.fallback;
import java.util.List;
import org.springframework.stereotype.Component;
import cn.study.service.IDeptClientService;
import cn.study.vo.Dept;
import feign.hystrix.FallbackFactory;
@Component
public class IDeptClientServiceFallbackFactory
        implements
            FallbackFactory<IDeptClientService> {

    @Override
    public IDeptClientService create(Throwable cause) {
        return new IDeptClientService() {
            @Override
            public Dept get(long id) {
                Dept vo = new Dept();
                vo.setDeptno(888888L);
                vo.setDname("【ERROR】Feign-Hystrix"); // 錯誤的提示
                vo.setLoc("Consumer客戶端提供");
                return vo;
            }

            @Override
            public List<Dept> list() {
                return null;
            }

            @Override
            public boolean add(Dept dept) {
                return false;
            }
        };
    }

}

2、【microcloud-service】修改 IDeptClientService 接口，追加本地的 Fallback 配置。

package cn.study.service;

import java.util.List;

import org.springframework.cloud.netflix.feign.FeignClient;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

import cn.study.commons.config.FeignClientConfig;
import cn.study.service.fallback.IDeptClientServiceFallbackFactory;
import cn.study.vo.Dept;
@FeignClient(value = "MICROCLOUD-PROVIDER-DEPT", configuration = FeignClientConfig.class, fallbackFactory = IDeptClientServiceFallbackFactory.class)
public interface IDeptClientService {
    @RequestMapping(method = RequestMethod.GET, value = "/dept/get/{id}")
    public Dept get(@PathVariable("id") long id);
    @RequestMapping(method = RequestMethod.GET, value = "/dept/list")
    public List<Dept> list();
    @RequestMapping(method = RequestMethod.POST, value = "/dept/add")
    public boolean add(Dept dept);
}

此時當服務不可用的時候就會執行“IDeptClientServiceFallbackFactory”類中返回的 IDeptClientService 接口的匿名對象信息。

3、【microcloud-consumer-hystrix】修改 application.yml 配置文件，追加 feign 配置啟用。

feign:
  hystrix: 
    enabled: true

4、【microcloud-consumer-hystrix】修改程序啟動主類：

package cn.study.microcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.cloud.netflix.feign.EnableFeignClients;
import org.springframework.context.annotation.ComponentScan;
@SpringBootApplication
@EnableEurekaClient
@ComponentScan("cn.study.service,cn.study.microcloud")
@EnableFeignClients(basePackages={"cn.study.service"})
public class Consumer_80_StartSpringCloudApplication {
    public static void main(String[] args) {
        SpringApplication.run(Consumer_80_StartSpringCloudApplication.class,
                args);
    }
}

當追加上了“@ComponentScan("cn.mldn.service")”注解之后才可以進行包的掃描配置。

此時即使服務端無法繼續提供服務了，由於存在有服務降級機制，也會保證服務不可用時可以得到一些固定的提示信息。

2.3、HystrixDashboard服務監控

在 Hystrix 里面提供有一種監控的功能，那么這個功能就是“Hystrix Dashboard”，可以利用它來進行整體微服務的監控操作。

1、首先為了方便監控，將建立一個新的監控項目：microcloud-consumer-hystrix-dashboard；

2、【microcloud-consumer-hystrix-dashboard】修改項目中的 pom.xml 配置文件：

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
        </dependency>

3、【microcloud-provider-*】所有的服務提供者之中都一定要提供有監控服務依賴庫：

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

4、【microcloud-consumer-hystrix-dashboard】修改 application.yml 配置文件，主要進行端口的配置：

server:
  port: 9001

5、【microcloud-consumer-hystrix-dashboard】創建一個監控的主類：

package cn.study.microcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard;
@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardApplication_9001 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixDashboardApplication_9001.class, args);
    }
}

6、修改 hosts 主機文件，增加主機列表：

127.0.0.1 dashboard.com

服務運行地址：http://dashboard.com:9001/hystrix；

7、得到 microcloud-provider-dept 的監控信息：http://studyjava:hello@dept-8001.com:8001/hystrix.stream；

· 如果此時要想獲取監控信息必須去運行微服務；

8、將之前的監控的路徑http://studyjava:hello@dept-8001.com:8001/hystrix.stream填寫到之前啟動好的 dashboard 程序頁面之中；

監控效果如下圖所示：

2.4、Turbine 聚合監控

HystrixDashboard 主要的功能是可以針對於某一項微服務進行監控，但是如果說現在有許多的微服務需要進行整體的監控，那么這種情況下就可以利用 turbine 技術來實現。

1、下面准備出一個新的微服務：Company，這個微服務不打算使用 SpringSecurity 安全處理以及 Mybatis 數據庫連接，只是做一個簡單的數據信息。通過一個已有的 microcloud-provider-hystrix-8001 復制一個新的項目：microcloud-provider-company-8101；

2、【microcloud-provider-company-8101】修改項目中的 pom.xml 配置文件，將與安全有關的依賴包刪除掉以及與數據庫連接池、MyBatis 的相關的程序類或接口全部刪除掉，只保留有用的包；

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>
        <dependency>
            <groupId>cn.study</groupId>
            <artifactId>microcloud-api</artifactId>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jetty</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>springloaded</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
        </dependency>
    </dependencies>

3、【microcloud-api】追加一個新的 VO 類：Company。

package cn.study.vo;

import java.io.Serializable;

@SuppressWarnings("serial")
public class Company implements Serializable {
    private String title ;
    private String note ;
    public String getTitle() {
        return title;
    }
    public void setTitle(String title) {
        this.title = title;
    }
    public String getNote() {
        return note;
    }
    public void setNote(String note) {
        this.note = note;
    }
    @Override
    public String toString() {
        return "Company [title=" + title + ", note=" + note + "]";
    }
}

4、【microcloud-provider-company-8101】建立一個新的微服務的程序類：CompanyRest

package cn.study.microcloud.rest;

import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;

import cn.study.vo.Company;

@RestController
public class CompanyRest {
    @RequestMapping(value = "/company/get/{title}", method = RequestMethod.GET)
    @HystrixCommand    // 如果需要進行性能監控，那么必須要有此注解
    public Object get(@PathVariable("title") String title) {
        Company vo = new Company() ;
        vo.setTitle(title);
        vo.setNote("www.study.cn");
        return vo ;
    }
}

5、【microcloud-provider-company-8101】修改程序的啟動主類：

package cn.study.microcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
@EnableDiscoveryClient
public class Company_8101_StartSpringCloudApplication {
    public static void main(String[] args) {
        SpringApplication.run(Company_8101_StartSpringCloudApplication.class, args);
    }
}

6、【microcloud-provider-company-8101】修改 application.yml 配置文件：

server:
  port: 8101
eureka: 
  client: # 客戶端進行Eureka注冊的配置
    service-url:
      defaultZone: http://edmin:studyjava@eureka-7001.com:7001/eureka,http://edmin:studyjava@eureka-7002.com:7002/eureka,http://edmin:studyjava@eureka-7003.com:7003/eureka
  instance:
    lease-renewal-interval-in-seconds: 2 # 設置心跳的時間間隔（默認是30秒）
    lease-expiration-duration-in-seconds: 5 # 如果現在超過了5秒的間隔（默認是90秒）
    instance-id: dept-8001.com  # 在信息列表時顯示主機名稱
    prefer-ip-address: true     # 訪問的路徑變為IP地址
info: 
  app.name: study-microcloud
  company.name: www.study.cn
  build.artifactId: $project.artifactId$
  build.version: $project.verson$
spring: 
  application:
    name: microcloud-provider-company

7、【microcloud-provider-company-8101】啟動微服務，隨后取得監控信息：

· 在 hosts 配置文件之中追加有一個映射路徑：

127.0.0.1 company-8101.com

· 訪問地址：http://company-8101.com:8101/company/get/hello；

· hystrix 監控地址：http://company-8101.com:8101/hystrix.stream；

8、如果要想實現 trubine 的配置，則需要建立一個 turbine項目模塊，這個項目可以直接通過之前的 microcloud-consumer-hystrix-dashboard 模塊進行復制為“microcloud-consumer-turbine”模塊；

9、【microcloud-consumer-turbine】修改 pom.xml 配置文件，追加 turbine 的依賴程序包：

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-turbine</artifactId>
        </dependency>

10、【microcloud-consumer-turbine】修改 application.yml 配置文件：

server:
  port: 9101  # turbine的監聽端口為9101
eureka: 
  client: # 客戶端進行Eureka注冊的配置
    service-url:
      defaultZone: http://edmin:studyjava@eureka-7001.com:7001/eureka,http://edmin:studyjava@eureka-7002.com:7002/eureka,http://edmin:studyjava@eureka-7003.com:7003/eureka
  instance:
    lease-renewal-interval-in-seconds: 2 # 設置心跳的時間間隔（默認是30秒）
    lease-expiration-duration-in-seconds: 5 # 如果現在超過了5秒的間隔（默認是90秒）
    instance-id: dept-8001.com  # 在信息列表時顯示主機名稱
    prefer-ip-address: true     # 訪問的路徑變為IP地址
turbine: 
  app-config: MICROCLOUD-PROVIDER-COMPANY,MICROCLOUD-PROVIDER-DEPT  # 定義所有要監控的微服務信息
  cluster-name-expression: new String("default")  # 設置監控的表達式，通過此表達式表示要獲取監控信息名稱

11、【microcloud-consumer-turbine】建立一個 turbine 的使用主類信息

package cn.study.microcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard;
import org.springframework.cloud.netflix.turbine.EnableTurbine;
@SpringBootApplication
@EnableHystrixDashboard
@EnableTurbine
public class TurbineApplication_9101 {
    public static void main(String[] args) {
        SpringApplication.run(TurbineApplication_9101.class, args);
    }
}

12、【microcloud-consumer-hystrix-dashboard】運行 hystrix-dashboard 監控程序；

13、【microcloud-consumer-turbine】運行 trubine 聚合監控程序；

· 但是在正常啟動 trubine 的時候出現了以下的錯誤提示信息，這是因為沒有對有安全認證的微服務MICROCLOUD-PROVIDER-DEPT進行安全認證

· 修改 hosts 配置文件，追加一個映射路徑：

127.0.0.1 turbine.com

· trubine 訪問路徑：http://turbine.com:9101/turbine.stream

14、運行 HystrixDashboard 監控程序：http://dashboard.com:9001/hystrix.stream；

· 在監控的位置上填寫之前設置好的 turbine 的訪問地址看到的效果如下：

15、【microcloud-security】如果現在需要 turbine 進行加密的微服務的訪問操作，只能夠采取一種折衷方案，就是要去修改整個項目中的安全策略，追加 WEB 安全策略配置：

package cn.study.microcloud.config;

import javax.annotation.Resource;

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.authentication.builders.AuthenticationManagerBuilder;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.builders.WebSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.config.http.SessionCreationPolicy;
@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    public void configure(WebSecurity web) throws Exception {
        web.ignoring().antMatchers("/hystrix.stream","/turbine.stream") ;
    }
    
    @Resource
    public void configGlobal(AuthenticationManagerBuilder auth)
            throws Exception {
        auth.inMemoryAuthentication().withUser("studyjava").password("hello")
                .roles("USER").and().withUser("admin").password("hello")
                .roles("USER", "ADMIN");
    }
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // 表示所有的訪問都必須進行認證處理后才可以正常進行
        http.httpBasic().and().authorizeRequests().anyRequest()
                .fullyAuthenticated();
        // 所有的Rest服務一定要設置為無狀態，以提升操作性能
        http.sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS);
    }
}

現在所有的安全策略會自動拋開以上的兩個訪問路徑，這種是基於 Bean 配置，如果要是你現在基於的是 application.yml 文件的配置，則就必須修改 application.yml 配置文件，追加如下內容：

security:
  ignored:
  - /hystrix.stream
  - /turbine.stream

這個時候如果啟動之后沒有出現任何的錯誤提示，那么就表示現在已經可以繞過了 Security 的配置而直接進行服務的訪問了。

https://www.cnblogs.com/leeSmall/p/8847652.html

是的，Hystrix停止開發了。官方的新聞如下：

考慮到之前Netflix宣布Eureka 2.0孵化失敗時，被業界過度消費（關於Eureka 2.x，別再人雲亦雲了！），為了防止再度出現類似現象，筆者編寫了這篇文章。

我相信看到這篇文章，大家無非會思考幾個問題：

如果Hystrix還能不能繼續用於生產？
Spring Cloud生態中是否有替代實現？

下面依次展開：

就筆者經驗來看，Hystrix是比較穩定的，並且Hystrix只是停止開發新的版本，並不是完全停止維護，Bug什么的依然會維護的。因此短期內，Hystrix依然是繼續使用的。

但從長遠來看，Hystrix總會達到它的生命周期，那么Spring Cloud生態中是否有替代產品呢？

答案顯然是有。

Alibaba Sentinel

Sentinel 是阿里巴巴開源的一款斷路器實現，目前在Spring Cloud的孵化器項目Spring Cloud Alibaba中，預計Spring Cloud H系列中可以孵化完成。

盡管Sentinel尚未在Spring Cloud項目中孵化完成，但Sentinel本身在阿里內部已經被大規模采用，非常穩定。因此可以作為一個較好的替代品。

Resilience4J

Resilicence4J 在今年的7月進入筆者視野，小玩了一下，覺得非常輕量、簡單，並且文檔非常清晰、豐富。個人比較看好，這也是Hystrix官方推薦的替代產品。

不僅如此，Resilicence4j還原生支持Spring Boot 1.x/2.x，而且監控也不像Hystrix一樣弄Dashboard/Hystrix等一堆輪子，而是支持和Micrometer（Pivotal開源的監控門面，Spring Boot 2.x中的Actuator就是基於Micrometer的）、prometheus（開源監控系統，來自谷歌的論文）、以及Dropwizard metrics（Spring Boot曾經的模仿對象，類似於Spring Boot）進行整合。

筆者特別看重Resilience4J和micrometer整合的能力，這意味着：如果你用Spring Boot 2.x並在項目中引入Resilience4J，那么監控數據和Actuator天生就是打通的！你不再需要一個專屬的、類似於Hystrix Dashboard的東西去監控斷路器。

預報

考慮到目前國內Resilience4J的文檔還比較少，筆者准備近期分享系列博客，敬請期待！

原文：http://www.itmuch.com/spring-cloud-sum/hystrix-no-longer/ ，轉載請說明出處

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 限流、熔斷、服務降級理解【原創】談談服務雪崩、降級與熔斷服務降級和服務熔斷 SpringCloud Hystrix（服務熔斷/降級）【springcloud】服務熔斷與降級（Hystrix） dubbo熔斷、限流、服務降級什么是服務熔斷、服務降級、服務限流？ Hystrix的服務熔斷和服務降級 Feign + Hystrix 服務熔斷和服務降級 Spring Cloud微服務如何實現熔斷降級？

談談我對服務熔斷、服務降級的理解 專題