Review

• 解決了服務(wù)拆分之后的服務(wù)治理問題：Nacos解決了服務(wù)治理問題
• OpenFeign解決了服務(wù)之間的遠程調(diào)用問題
• 網(wǎng)關(guān)與前端進行交互，基于網(wǎng)關(guān)的過濾器解決了登錄校驗的問題?

流量控制：避免因為突發(fā)流量而導致的服務(wù)宕機。

隔離和降級：避免微服務(wù)出現(xiàn)雪崩

避免非法的請求進入微服務(wù)當中

避免因為服務(wù)的重啟而導致這些規(guī)則的丟失

1. 初始Sentinel

1.1 雪崩問題及解決方案

1.1.1 雪崩問題

微服務(wù)中，服務(wù)間調(diào)用關(guān)系錯綜復(fù)雜，一個微服務(wù)往往依賴于其它多個微服務(wù)。

如圖，服務(wù)消費者調(diào)用服務(wù)提供者，如果服務(wù)提供者發(fā)生了故障，由于當前服務(wù)消費者應(yīng)用的部分業(yè)務(wù)依賴于服務(wù)提供者，導致服務(wù)消費者的業(yè)務(wù)請求會被阻塞，因為服務(wù)消費者要等待服務(wù)提供者結(jié)果的返回，請求被阻塞，用戶自然不會得到響應(yīng)，Tomcat的這個線程也不會釋放，因為阻塞它就不會釋放Tomcat的連接，于是越來越多的用戶請求到來，越來越多的線程會被阻塞，由于Tomcat服務(wù)器支持的線程和并發(fā)數(shù)有限，業(yè)務(wù)請求一直被阻塞，會導致服務(wù)器資源耗盡，從而導致其它業(yè)務(wù)請求請求不進來，導致當前服務(wù)也故障不可用了，形成級聯(lián)失敗，雪崩就發(fā)生了 => 一個服務(wù)故障導致依賴于它的服務(wù)最終也出現(xiàn)故障了，導致依賴于它的服務(wù)最終被拖垮

在微服務(wù)架構(gòu)中，服務(wù)與服務(wù)之間會通過遠程調(diào)用的方式進行通信，一旦微服務(wù)調(diào)用鏈路中的某個服務(wù)發(fā)生故障或某個資源出現(xiàn)不穩(wěn)定，例如，表現(xiàn)為timeout - 業(yè)務(wù)接口超時響應(yīng)，業(yè)務(wù)接口響應(yīng)時間過長，會導致其依賴服務(wù)也會發(fā)生故障，此時就會發(fā)生故障的蔓延，引起整個鏈路中的所有微服務(wù)都不可用，也就是引起整個鏈路中的所有微服務(wù)都無法訪問的情況，最終導致系統(tǒng)癱瘓，這就是服務(wù)雪崩問題或者叫級聯(lián)失敗問題。?

• 在微服務(wù)里面，雪崩問題是一個必須要解決的問題。

微服務(wù)保護?

• 保證服務(wù)運行的健壯性，避免級聯(lián)失敗導致的雪崩問題，就屬于微服務(wù)保護。?

服務(wù)保護方案或容錯保護措施?

• 服務(wù)降級、服務(wù)熔斷、流量控制（請求限流）、線程池隔離等

這些方案或多或少都會導致服務(wù)的體驗上略有下降，比如

• 請求限流：降低了并發(fā)上限；
• 線程池隔離：降低了可用資源的數(shù)量；
• 服務(wù)熔斷：降低了服務(wù)的完整度，部分服務(wù)變得不可用或弱可用。

但通過這些方案，服務(wù)的健壯性得到了提升。?

容錯保護就是當某個服務(wù)發(fā)生故障時，通過斷路器的監(jiān)控，給調(diào)用返回一個錯誤響應(yīng)，而不是長時間的等待，這樣就不會使得調(diào)用方由于長時間得不到響應(yīng)而占用線程，從而防止故障的蔓延。

解決雪崩問題的常見方式有四種：應(yīng)對服務(wù)雪崩的一種微服務(wù)鏈路保護機制

• 前面三種是已經(jīng)有服務(wù)故障了，我該怎么樣去避免這個故障傳遞到其它服務(wù)而引起雪崩（3解決 + 1預(yù)防）：?

如何避免因服務(wù)故障而引起的雪崩問題？?

超時處理：

• 調(diào)用業(yè)務(wù)時設(shè)定超時時間（給業(yè)務(wù)設(shè)定超時時間），如果請求超過一定時間沒有響應(yīng)就釋放該請求，直接返回錯誤信息，而不會讓請求無休止等待，這樣就不會導致一直占用Tomcat資源，可以在一定程序上緩解雪崩問題{緩解雪崩問題而不是100%解決雪崩問題，因為如果說釋放請求的速度沒有進入請求的速度快，那么終有一天服務(wù)器端的資源還是有可能會被耗盡}

艙壁模式（線程隔離）

• 限定每個業(yè)務(wù)接口能使用的線程數(shù)（說白了就是給每個業(yè)務(wù)接口都分配一個獨立的線程池），這個時候每個業(yè)務(wù)能夠使用的線程資源是有限的（同時也限制了每個業(yè)務(wù)請求處理的并發(fā)量），這樣就可以避免耗盡整個Tomcat的資源（因為一個業(yè)務(wù)一旦出現(xiàn)故障，它最多是把整個線程池內(nèi)的資源耗盡，而不會導致整個Tomcat的資源被耗盡），因此也叫線程隔離。?
• 這種模式它確實解決了雪崩問題，但是從資源上來講會造成一定的浪費，比如服務(wù)提供者真的宕機了，但服務(wù)消費者每次還來去請求訪問它，明明知道它掛了，還要去嘗試訪問，而且還要占用我一定的線程數(shù)，這顯然是一種浪費。

?

斷路器模式或熔斷降級(模式)：比較推薦的一種解決方案

• 由斷路器統(tǒng)計業(yè)務(wù)執(zhí)行的異常比例，如果超出閾值則會熔斷該業(yè)務(wù)，會認為該服務(wù)由導致雪崩的風險，會攔截訪問該業(yè)務(wù)的一切請求，形成熔斷，讓請求快速失敗，資源快速釋放，避免影響到其它的資源，從而避免最終雪崩問題的發(fā)生，該模式不會存在資源浪費的情況，因為如果知道服務(wù)出現(xiàn)故障了，就不讓請求再去訪問該服務(wù)了? =>? 類似于電路里面的保險絲兒。? ?
• 當檢測到服務(wù)恢復(fù)正常響應(yīng)以后，我們再去放行訪問該業(yè)務(wù)的請求。?
• 熔斷降級模式是解決雪崩問題里面比較好的一種方案。

?

如何避免因瞬間高并發(fā)流量而導致的服務(wù)故障？?

限流 - 流量控制：

• 當系統(tǒng)負載較高時，如果持續(xù)讓請求進入，可能會導致系統(tǒng)崩潰，無法響應(yīng)。
• 限制業(yè)務(wù)訪問的QPS（每秒查詢率，每秒的響應(yīng)請求數(shù)，每秒鐘處理請求的數(shù)量），限制接口訪問的并發(fā)流量，避免服務(wù)因流量的激增或突增而出現(xiàn)故障，?避免因為突發(fā)流量而導致的服務(wù)宕機。
• 使用Sentinel（限流器）實現(xiàn)限流：Sentinel它可以按照服務(wù)所能夠承受的一個頻率去釋放請求，當流量激增的時候，控制流量通過的速率，把雪崩問題扼殺在了搖籃當中?？偨Y(jié)：流量控制是預(yù)防雪崩，避免出現(xiàn)雪崩問題！

思考：那我就只用流量控制不就可以從根源上避免出現(xiàn)雪崩問題了嗎？其它三種我不用不就行了。。。?

• 因為高并發(fā)引起的服務(wù)故障只是故障的原因之一，往往服務(wù)還會因為其它問題而出現(xiàn)故障，比如因為網(wǎng)絡(luò)問題或者是Full GC引起的假死問題，這些問題都會引起服務(wù)故障，這個時候就要用到其它三種解決方案了。?

總結(jié)：

• 限流是對服務(wù)的保護，避免因突增的高并發(fā)流量而導致服務(wù)故障，進而避免雪崩，是一種預(yù)防措施。
• 而超時處理、線程隔離（艙壁模式）、熔斷降級（斷路器模式）是在部分服務(wù)故障時，將故障控制在一定范圍，避免雪崩，是一種補救措施。?

1.2 服務(wù)保護框架或技術(shù)對比 - 容錯保護技術(shù)選型對比

在SpringCloud當中支持多種服務(wù)保護技術(shù)：

• Netfix Hystrix：https://github.com/Netflix/Hystrix
• Sentinel：https://github.com/alibaba/Sentinel
• Resilience4J：https://github.com/resilience4j/resilience4j

Hystrix和Sentinel都是非常成熟可靠的服務(wù)保護工具，早期比較流行的是Hystrix框架，但目前國內(nèi)使用最廣泛的還是阿里巴巴的Sentinel服務(wù)保護框架（是Spring Cloud Alibaba的組件之一），這里我們做下對比：?

關(guān)于Hystrix和Sentinel的對比，在Sentinel的官網(wǎng)上有一篇文章寫的很詳細：?

sentinel-vs-hystrix | Sentinelsentinel-vs-hystrixhttps://sentinelguard.io/zh-cn/blog/sentinel-vs-hystrix.html

技術(shù)選型：Sentinel vs Hystrix本文將從多個角度對 Sentinel 和 Hystrix 進行對比，希望在面臨技術(shù)選型的時候，對各位開發(fā)者能有所幫助。https://mp.weixin.qq.com/s/D8RKfnzofM-br_y4fTLIaA

1.?開源和維護

• 首先兩者都是開源，Hystrix是Netflix開源的項目，而Sentinel是阿里巴巴開源的項目；
• 但Hystrix已經(jīng)停止維護，Spring Cloud在已經(jīng)發(fā)布的項目中已經(jīng)移除了對Hystrix的支持，而Sentinel在阿里巴巴內(nèi)部廣泛使用，阿里團隊一直在迭代更新，并且有著活躍的社區(qū)支持。
• Hystrix適用于Java語言的微服務(wù)架構(gòu)，而Sentinel則支持多種語言和多種類型的應(yīng)用架構(gòu)，包括微服務(wù)、API網(wǎng)關(guān)、消息隊列等

2. 隔離設(shè)計上的對比

Sentinel底層是基于信號量來實現(xiàn)資源隔離，而Hystrix提供兩種隔離策略，Hystrix支持線程池隔離或信號量隔離，但默認情況下都是使用線程池隔離來實現(xiàn)資源隔離。

線程池隔離模式下需要配置線程池對應(yīng)的參數(shù)，信號量隔離模式下需要配置最大并發(fā)數(shù)。

• 線程池隔離：在一個業(yè)務(wù)請求進入Tomcat以后，它會給每一個被隔離的業(yè)務(wù)創(chuàng)建一個獨立的線程池，Hystrix也一樣，Hystrix的線程池隔離針對不同的資源分別創(chuàng)建不同的線程池，這樣，不同的服務(wù)調(diào)用都發(fā)生在不同的線程池中，在線程池阻塞情況時可以快速失敗，線程池隔離的好處是隔離度比較高，資源和資源之間做到了最徹底的隔離，可以針對某個資源的線程池去進行處理而不影響其它資源，但是代價就是線程上下文切換的overhead比較大，線程上下文切換會有非常大的損耗，增加了線程切換的成本，特別是對低延時的調(diào)用有比較大的影響。另外，還需要預(yù)先給各個資源做線程池大小的分配，實際情況下，線程池隔離并沒有帶來非常多的好處，最直接的影響，就是會讓機器資源碎片化。
• Hystrix的信號量隔離限制對某個資源調(diào)用的并發(fā)數(shù)，這樣的隔離非常輕量級，僅限制對某個資源調(diào)用的并發(fā)數(shù)，而不是顯式的去創(chuàng)建線程池（也就意味著不會去創(chuàng)建新的線程，這樣就減少了線程的創(chuàng)建），所以overhead比較小，但是效果不錯，但缺點是無法對慢調(diào)用自動進行降級，只能等待客戶端自己超時，因此仍然可能會出現(xiàn)級聯(lián)阻塞的情況。
• 而Sentinel可以通過并發(fā)線程數(shù)模式的流量控制來提供信號量隔離的功能，并且結(jié)合基于響應(yīng)時間的熔斷降級模式，可以在不穩(wěn)定資源的平均響應(yīng)時間比較高的時候自動降級，防止過多的慢調(diào)用占滿并發(fā)數(shù)，影響整個系統(tǒng)。

3. 熔斷降級的對比：熔斷降級的策略不同

• Sentinel和Hystrix的熔斷降級功能本質(zhì)上都是基于熔斷器或斷路器模式；

Sentinel和Hystrix都支持基于失敗比率（異常比率）的熔斷降級，在調(diào)用達到一定量級并且失敗比率達到設(shè)定的閾值時自動進行熔斷，此時所有對該資源的調(diào)用都會被block，直到過了指定的時間窗口后才啟發(fā)性的恢復(fù)；

• 而且Sentinel還支持基于平均響應(yīng)時間的熔斷降級，可以在服務(wù)響應(yīng)時間持續(xù)飆高的時候自動熔斷，拒絕掉更多的請求，直到一段時間后才恢復(fù)，這樣可以防止調(diào)用非常慢，也就是防止慢調(diào)用造成級聯(lián)阻塞的情況。

4. Sentinel特性

• Hystrix主要提供了服務(wù)降級、服務(wù)熔斷、線程隔離等功能，而Sentinel除了提供上述功能之外，還提供了實時監(jiān)控、流量控制、熱點參數(shù)限流、系統(tǒng)自適應(yīng)負載保護等功能。
• 另外Sentinel的很多配置都能夠動態(tài)推送到Sentinel客戶端進行更新無需重啟（熱更新），而Hystrix部分配置需要重啟才能更新

1. 輕量級、高性能

• Sentinel非常輕量級，其核心sentinel-core沒有任何多余依賴，打包后只有不到200KB，非常輕量級，同時Sentinel非常高性能，引入Sentinel帶來的性能損耗非常小，只有在業(yè)務(wù)單機量級超過25wQPS的時候才會有一些顯著的影響，單機QPS不太大的時候損耗幾乎可以忽略不計。

2. 流量控制

• Sentinel可以針對不同的調(diào)用關(guān)系，以不同的運行指標（如QPS、并發(fā)調(diào)用數(shù)、系統(tǒng)負載）為基準，對系統(tǒng)資源的調(diào)用進行流量控制，將隨機的請求調(diào)整成合適的形狀。

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

• 直接拒絕模式：即超出的請求直接拒絕。
• 慢啟動預(yù)熱模式：當流量激增的時候，控制流量通過的速率，讓通過的流量緩慢增加，在一定時間內(nèi)逐漸增加到閾值上限，給冷系統(tǒng)一個預(yù)熱的時間，避免冷系統(tǒng)被壓垮。
• 勻速器模式：利用Leaky Bucket漏桶算法實現(xiàn)的勻速模式，嚴格控制了請求通過的時間間隔，同時推積的請求將會排隊，超過超時時長的請求直接被拒絕。

Sentinel還支持調(diào)用關(guān)系的限流，包括基于調(diào)用方限流、基于調(diào)用鏈入口限流、關(guān)聯(lián)流量限流等，依托于Sentinel強大的調(diào)用鏈路統(tǒng)計信息，可以提供精準的不同維度的限流。

3. 系統(tǒng)負載保護或系統(tǒng)自適應(yīng)保護

• 當系統(tǒng)負載較高時，如果仍持續(xù)讓請求進入，可能會導致系統(tǒng)崩潰，無法響應(yīng)。
• 在集群環(huán)境下，網(wǎng)絡(luò)負載均衡會把本應(yīng)這臺機器承載的流量轉(zhuǎn)發(fā)到其它的機器上去，如果這個時候其它的汲取也處在一個邊緣狀態(tài)的時候，這個時候增加的流量就會導致這臺機器也崩潰，最后導致整個集群不可用，針對這個情況，Sentinel提供了對應(yīng)的保護機制，讓系統(tǒng)的入口流量和系統(tǒng)的負載達到一個平衡，保證系統(tǒng)在能力范圍之內(nèi)處理最多的請求。

4. 實時監(jiān)控和控制面板

• Sentinel控制臺（Dashboard）提供了機器發(fā)現(xiàn)、配置規(guī)則、查看實時監(jiān)控、查看調(diào)用鏈路信息等功能，使得用戶可以非常方便的去查看監(jiān)控和進行配置。

5. 生態(tài)

• Sentinel目前已經(jīng)針對Servlet、Dubbo、Spring Boot/Spring Cloud、gRPC等進行了適配，用戶只需引入相應(yīng)引來并進行簡單配置即可非常的方便的享受Sentinel的高可用流量防護能力。

1.3.Sentinel介紹和安裝

1.3.1.初識Sentinel

• Sentinel阿里巴巴開源的一款微服務(wù)流量控制組件，是阿里巴巴開源的一款服務(wù)保護框架，目前已經(jīng)加入SpringCloudAlibaba中，阿里開源的流量防衛(wèi)兵Sentinel。
• 官網(wǎng)地址：home | Sentinel ? ? ???

隨著微服務(wù)的流行，服務(wù)和服務(wù)之間的穩(wěn)定性變得越來越重要，Sentinel是面向分布式、多語言異構(gòu)化服務(wù)架構(gòu)的流量治理組件，主要以流量為切入點，從流量路由、流量控制、熔斷降級、系統(tǒng)自適應(yīng)過載保護、熱點流量防護等多個維度來幫助開發(fā)者保障微服務(wù)的穩(wěn)定性。

Sentinel 具有以下特征：

1. 豐富的應(yīng)用場景：Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺（即突發(fā)流量控制在系統(tǒng)容量可以承受的范圍）、預(yù)熱、消息隊列削峰填谷、集群流量控制、實時熔斷下游不可用應(yīng)用等。
2. 完備可視化的實時監(jiān)控：Sentinel 同時提供實時的監(jiān)控功能。您可以在控制臺中看到接入應(yīng)用的單臺機器秒級數(shù)據(jù)，甚至 500 臺以下規(guī)模的集群的匯總運行情況。
3. 廣泛的開源生態(tài)：Sentinel 提供開箱即用的與其它開源框架/庫的整合模塊，例如與 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相應(yīng)的依賴并進行簡單的配置即可快速地接入 Sentinel。
4. 多樣化的流量控制：資源粒度、調(diào)用關(guān)系、指標類型等多維度的流量控制
5. 完善的SPI擴展點：Sentinel 提供簡單易用、完善的 SPI 擴展接口。您可以通過實現(xiàn)擴展接口來快速地定制邏輯。例如定制規(guī)則管理、適配動態(tài)數(shù)據(jù)源等。

Sentinel的熔斷降級

什么是熔斷降級？

• 除了流量控制以外，降低調(diào)用鏈路中的不穩(wěn)定資源也是Sentinel的使命之一。
• 由于調(diào)用關(guān)系的復(fù)雜性，如果調(diào)用鏈路中的某個資源出現(xiàn)了不穩(wěn)定，最終會導致請求發(fā)生積壓。

Sentinel和Hystrix的原則是一致的：當調(diào)用鏈路中的某個資源出現(xiàn)不穩(wěn)定，例如，表現(xiàn)為 timeout，異常比例升高的時候，則對這個資源的調(diào)用進行限制，并讓請求快速失敗，避免影響到其它的資源，最終產(chǎn)生雪崩的效果。?

熔斷降級設(shè)計理念

在限制的手段上，Sentinel和Hystrix采取了完全不一樣的方法。

Sentinel對這個問題采取了兩種手段：

• 通過并發(fā)線程數(shù)進行限制

和資源池隔離的方法不同，Sentinel通過限制資源并發(fā)線程的數(shù)量，來減少不穩(wěn)定資源對其它資源的影響，這樣不但沒用線程切換的損耗，也不需要您預(yù)先分配線程池的大小。當某個資源出現(xiàn)不穩(wěn)定的情況下，例如響應(yīng)時間變長，對資源的直接影響就是會造成線程數(shù)的逐步堆積，當線程數(shù)在特定資源上堆積到一定的數(shù)量之后，對該資源的新請求就會被拒絕，堆積的線程完成任務(wù)后才開始繼續(xù)接收請求。

當線程池阻塞時，你其它所有請求打進來也會被阻塞，除非當線程池能夠處理新請求了，那你此時被阻塞的線程就要被喚醒，這個時候就會有線程上下文的切換開銷；

而控制線程并發(fā)數(shù)就是你一旦達到我這個線程上限的閾值，你還來請求，我就直接給你拒絕掉，這樣也就不存在什么阻塞了，自然不會有線程上下文切換的開銷。?

• 通過響應(yīng)時間對資源進行降級

除了對并發(fā)線程數(shù)進行控制以外，Sentinel還可以通過響應(yīng)時間來快速降級不穩(wěn)定的資源，當依賴的資源出現(xiàn)響應(yīng)時間過長后，所有對該資源的訪問都會被直接拒絕，直到過了指定的時間窗口之后才重新恢復(fù)。

1.3.2 安裝Sentinel控制臺

官網(wǎng)詳情：?

dashboard | Sentinel?

Sentinel官方提供了UI控制臺，方便我們對系統(tǒng)做限流設(shè)置，其實就是下載一個jar包。

1. 將其拷貝到一個你能記住的非中文、不包含特殊字符的目錄下，重命名為sentinel-dashboard，然后運行命令：

java -jar sentinel-dashboard.jar

2. jar包運行完成以后它底層其實就是一個基于Spring Boot的Web應(yīng)用，然后訪問：localhost:8080 即可看到控制臺頁面，默認的賬戶和密碼都是sentinel?

?

注意：Sentinel控制臺目前僅支持單機部署，啟動Sentinel控制臺需要JDK版本為1.8及以上版本。?

登錄后，即可看到控制臺，但是登錄后，我們發(fā)現(xiàn)一片空白，什么都沒有：

默認會監(jiān)控sentinel-dashboard服務(wù)本身。。。。。

• 這是因為我們還沒有讓微服務(wù)去和Sentinel去做整合，因此我們在控制臺看不到任何信息。?

1.4 微服務(wù)整合Sentinel?

• 要使用Sentinel肯定要結(jié)合微服務(wù)。?

我們在微服務(wù)模塊中整合Sentinel，并且連接sentinel-dashboard控制臺，步驟如下：

1. 引入Sentinel依賴

<!-- 引入sentinel依賴-->
<dependency><groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2. 配置Sentinel的控制臺地址，修改application.yaml文件，添加下面內(nèi)容：

spring:cloud: sentinel:transport:dashboard: localhost:8080

3. 重啟微服務(wù)，訪問微服務(wù)的任意端點，觸發(fā)sentinel監(jiān)控?

什么是端點呢？

• Spring MVC的任意一個Controller接口都是一個端點。?

?