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

時間 2019-11-30

標籤談談服務熔斷降級理解專題简体版

原文原文鏈接

伴隨着微服務架構被宣傳得如火如荼，一些概念也被推到了咱們面前（管你接受不接受），其實大多數概念之前就有，但不多被提的這麼頻繁（如今好像不說起都很差意思交流了）。
想起有人總結的一句話，微服務架構的特色就是：「一解釋就懂，一問就不知，一討論就吵架」。

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

今天先來講說「服務熔斷」和「服務降級」。爲何要說這個呢，由於我很長時間裏都把這兩個概念同質化了，不知道這兩個詞你們怎麼理解，一個意思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 以流量爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。html

Sentinel 具備如下特徵:java

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

Sentinel 的主要特性：react

Sentinel 的開源生態：git

Sentinel 分爲兩個部分:github

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

Quick Start

1.1 公網Demo:

若是你想最快的瞭解Sentinel在作什麼，你能夠經過Sentinel 新手指南來運行一個例子，而且能在控制檯上看到最直觀的監控，流控效果等。web

1.2 手動接入Sentinel以及Dashboard

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

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

若是應用使用 pom 工程，則在 pom.xml 文件中加入如下代碼便可：spring

<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培訓視頻的課堂筆記，寫在這裏只是爲了方便查閱。

一、概念：Hystrix 熔斷機制

二、具體內容

所謂的熔斷機制和平常生活中見到電路保險絲是很是類似的，當出現了問題以後，保險絲會自動燒斷，以保護咱們的電器，那麼若是換到了程序之中呢？

當如今服務的提供方出現了問題以後整個的程序將出現錯誤的信息顯示，而這個時候若是不想出現這樣的錯誤信息，而但願替換爲一個錯誤時的內容。

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

對於熔斷技術的實現須要考慮如下幾種狀況：

· 出現錯誤以後能夠 fallback 錯誤的處理信息；

· 若是要結合 Feign 一塊兒使用的時候還須要在 Feign（客戶端）進行熔斷的配置。

2.一、Hystrix 基本配置

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

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

二、【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 調用類中的指定方法，返回相應數據。

三、【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.二、服務降級（服務回退）

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

例如：在每一年年末 12306 都是最繁忙的時候，那麼在這個狀況會發現有一些神奇的狀況：當到了指定的時間你們開始搶票的時候，若是你不搶，然後查詢一些冷門的車次，票有可能查詢不出來。由於這個時候會將全部的系統資源給搶票調度了，而其它的服務因爲其暫時不受到過多的關注，這個時候能夠考慮將服務降級（服務暫停）。

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

一、【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;
            }
        };
    }

}

二、【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 接口的匿名對象信息。

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

feign:
  hystrix: 
    enabled: true

四、【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.三、HystrixDashboard服務監控

在 Hystrix 裏面提供有一種監控的功能，那麼這個功能就是「Hystrix Dashboard」，能夠利用它來進行總體微服務的監控操做。

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

二、【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>

三、【microcloud-provider-*】全部的服務提供者之中都必定要提供有監控服務依賴庫：

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

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

server:
  port: 9001

五、【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);
    }
}

六、修改 hosts 主機文件，增長主機列表：

127.0.0.1 dashboard.com

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

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

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

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

監控效果以下圖所示：

2.四、Turbine 聚合監控

HystrixDashboard 主要的功能是能夠針對於某一項微服務進行監控，可是若是說如今有許多的微服務須要進行總體的監控，那麼這種狀況下就能夠利用 turbine 技術來實現。

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

二、【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>

三、【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 + "]";
    }
}

四、【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 ;
    }
}

五、【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);
    }
}

六、【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

七、【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；

八、如果要想實現 trubine 的配置，則須要創建一個 turbine項目模塊，這個項目能夠直接經過以前的 microcloud-consumer-hystrix-dashboard 模塊進行復製爲「microcloud-consumer-turbine」模塊；

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

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

十、【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")  # 設置監控的表達式，經過此表達式表示要獲取監控信息名稱

十一、【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);
    }
}

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

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

· 可是在正常啓動 trubine 的時候出現瞭如下的錯誤提示信息，這是由於沒有對有安全認證的微服務MICROCLOUD-PROVIDER-DEPT進行安全認證

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

127.0.0.1 turbine.com

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

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

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

1五、【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的東西去監控斷路器。