4.1 高並發帶來的問題
在微服務中，我們將業務拆分成一個個的服務，服務與服務之間可以相互調用，但是由於網絡原因或者自身的原因，服務並不能保證100%可用，如果單個服務出現問題，調用這個服務就會出現網絡延遲，此時若有大量的網絡涌入，會形成任務堆積，最終導致服務癱瘓。
接下來我們模擬一個高並發的場景
-
編寫java代碼
@RestController @Slf4j public calss OrderController2{ @Autowired private OrderService orderSerivce; @Autowired private ProductService productService; @RequestMapping("/order/prod/{pid}") public Order order(@Pathvariable("pid") Integer pid){ Product product = productService.findByPid(pid); Try{ Thread.sleep(100) }catch(InterruptedException e){ e.printStackTrace(); } Order order = new Order(); order.setUid(1); order.setUsername("測試賬號")； order.setPid(pid); order.setPname(product.getPname()); order.setPprice(product.getPprice()); order.setNumber(1); return order; } @RequestMapping("/order/message") public String message(){ return "高並發下的問題測試"; } } -
配置tocmat 並發數
server: port:8091 tomcat: max-threads: 10 -
接下來使用壓測工具，對請求進行壓測
下載地址：https://jmeter.apache.org
第一步：修改配置，並啟動軟件
進入bin目錄，修改jmeter.properties 文件中的語言支持為language=zh_CN，然后縣級jmeter.bat 啟動軟件。
第二步：添加線程組
第三步：配置線程並發數
第四步：添加http取樣
第五步：配置取樣，並啟動測試
-
訪問message方法觀察效果
-
結論：
*此時會發現，由於order方法囤積了大量的請求，導致message方法的訪問出現了問題，這就是服務雪崩的雛形
4.2 服務雪崩效應
*在分布式系統中，由於網絡原因或者自身原因，服務一版無法保證100%可用，如果一個服務出現了問題，調用這個服務就會出現線程阻塞的情況，此時若有大量的請求涌入，就會出現多條線程阻塞等待，進而導致服務癱瘓
由於服務與服務之間的依賴性，故障會傳播，會對整個微服務系統造成才災難性的嚴重后果，這就是服務故障“雪崩效應”。
雪崩發生的原因多種多樣，有不合理的容量設計，或者是高並發下某一個方法相應變慢，亦或者是某台機器的資源耗盡。我們無法完全杜絕雪崩源頭的放生，只有做好了足夠的融租哦，保證在一個服務發生問題，不會影響到其他服務的正常運行，也就是“雪落而不雪崩”。
4.3常見的容錯方案
要防止雪崩的擴散，我們就要做好服務的容錯，容錯說白了就是保護自己不被豬隊友拖垮的一些措施，下面介紹常見的服務容錯思路和組件。
常見的容錯思路：
常見的容錯思路有隔離、超時、限流、熔斷、降級這幾種，下面分別介紹下。
-
隔離
它是指將系統按照一定的原則划分為若干個服務模塊，各個模塊之間相互獨立，無強依賴。當有故障發生時，能將問題和影響隔離在某個模塊內部，而不擴散風險，不波及其他模塊，不影響整體的系統服務，常見的隔離方式有：線程池隔離和信號量隔離
-
超時
在上游服務調用下有服務的時候，設置一個最大響應時間，如果炒股哦這個時間，下游未做出反應，就斷開請求，釋放掉線程
-
限流
限流就是限制系統的輸入和輸出流量已達到保護系統的目的。為了保證系統的穩固運行，一單達到限制的閾值，就需要限制流量並采取少量措施以完成限制流量的目的。
-
熔斷
在互聯網系統中，當下有服務因訪問壓力過大而影響變慢或失敗，上游服務為了保護系統整體可用性，可用暫時切斷對下有服務的調用，這種犧牲局部，保全整體的措施就叫做熔斷
服務熔斷一般有三種狀態:
-
熔斷關閉狀態（Closed）
服務沒有故障時，熔斷器所處的狀態，對調用方的調用不做任何限制
-
熔斷開啟狀態（Open）
后續對該服務接口的調用不在經過網絡，直接執行本地的fallback方法
-
版熔斷狀態（Half-Open）
嘗試恢復服務調用，允許有限的流量調用該服務，並監控調用成功率，如果成功率達到預期，則說經服務已恢復，進入熔斷關閉狀態，如果成功率仍舊很低，則重新進入熔斷關閉狀態。
-
-
降級
降級其實就是為服務提供一個托底方案，一單服務無法正常調用，就使用托底方案。
4.4常見的容錯組件
-
Hystrix
Hystrix是由Netflix開源的一個延遲和容錯庫，用於隔離訪問遠程系統、服務或者第三方庫，防止級聯失敗，從而提升系統的可用性和容錯性。
-
Resilience4J
Resilience4J一款非常輕量、簡單、並且文檔非常清晰、豐富的熔斷工具，這也是Hystrix官方推薦的替代產品。不僅如此，Resilience4J還原生支持Spring Boot 1.x/2.x，而且監控也支持和prometheus等多款主流產品進行整合。
-
Sentinel
Sentinel是阿里巴巴開源的一款斷路器實現，本身在阿里內部已經被大規模采用，非常穩定。
下面是三個組件的在各方面的對比：
4.5Sentinel入門
4.5.1 什么是Sentinel
Sentinel（分布式系統的流量方衛兵）是阿里巴巴開源的一套用於服務容錯的中和解決方案。它以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來保護服務的穩定性。
Sentinel具有以下特征：
- 豐富的應用場景：Sentinel承接了阿里巴巴近10年的雙十一大促流浪的核心場景，例如秒殺（即突發榴蓮個控制在系統容量可以承受的范圍）、消息削峰填谷、集群流量控制、實施熔斷下游不可用應用等。
- 完備的實時監控：Sentinel提供了實時的監控功能。通過控制台可以看到接入應用的單台機器秒級數據，甚至500台以下規模的集群的匯總運行情況。
- 廣泛的開源生態：Sentinel提供了開箱即用的與其他開源框架/庫的整合模塊，例如與SpringCloud、Dubbo、gRPC的整合。只需要引入相應的依賴並進行簡單的配置即可快速地接入Sentinel。
- 完善的SPI擴展點：Ssentinel提供了簡單易用、完善的SPI擴展接口。您可以通過實現擴展接口來快速的定制邏輯。例如定制規則管理、適配動態數據源等。
Sentinel分為兩個部分
- 核心庫（Java客戶端）不依賴任何框架、庫，能夠運行於所有java運行時環境，同事對Dubbo/SpringCloud 等框架也有較好的支持。
- 控制台（Dashboard）基於Spring Boot開發，打包后可以直接運行，不需要額外的tomcat等應用容器。
4.5.2 微服務集成Sentinel
為微服務集成Sentinel非常的簡單，只需要添加Sentinel的依賴即可
-
在pom.xml中添加下面依賴
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency> -
編寫一個Controller測試使用
@RestController @Slf4j public class orderCOntroller3{ @RequestMapping("/order/message1") public String message2(){ return "message1"; } @RequestMapping("/order/message2") public String message2(){ return "message2"; } }
4.5.3 安裝Sentinel控制台
Sentinel提供一個輕量級的控制台，它提供機器發現、單機資源實時監控以及規則管理等功能。
-
下載jar包，解壓到文件夾。https://github.com/alibaba.Sentinel/releases
-
啟動控制台
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-xxx.jar -
修改shop-order,在里面加入有關控制台的配置
spring: cloud: sentinel: transport: port: 9999 dashboard: localhost:8080 -
通過瀏覽器訪問localhost:8080 進入控制台（默認用戶名密碼是：sentinel/sentinel）
-
補充：
Sentinel的控制台其實就是一個Soringboot編寫的程序。我們需要將我們的微服務程序注冊到控制台上，即在微服務中指定控制台的地址，並且還要開一個跟控台傳遞數據的端口，控制台也可以通過次端口調用微服務中的監控程序獲取微服務的各種信息。
4.5.4 實現一個接口的限流
- 通過控制台為message1添加一個流控規則
- 通過控制台快速頻繁訪問，觀察效果
4.6 Sentinel的概念和功能
4.6.1 基本概念
-
資源
資源就是Sentinel要保護的東西，資源是Sentinel的關鍵概念。它可以是java應用程序中的任何內容，可以是一個服務，也可以是一個方法，甚至是一段代碼。
我們入門案例中的message1方法就可以認為是一個資源
-
規則
規則就是用來定義如何進行保護資源的，作用在資源之上，定義以什么樣的方式保護資源，主要包括里流量控制規則，熔斷降級規則以及系統保護規則。
我們入門案例中就是message1資源設置了一種流控規則，限制了進入message1的流量。
4.6.2 重要功能
Sentinel的主要功能就是容錯，主要體現為一下3個方面：
-
流量控制
流量控制在網絡傳輸中是有一個常用的概念， 它用於調整網絡包的數據，任意時間來到請求往往是隨機不可控的，而系統的處理能力是有限的的，我們需要根據系統的處理能力對流量進行控制，Sentinel作為一個調配器，可以根據需要把隨機的請求調整為合適的形狀。
-
熔斷降級
當檢測到調用鏈路中某個資源出現不穩定的表現，例如請求響應時間長或者比例升高的時候，則對這個資源的調用進行限制，讓請求快速失敗，避免影響到其他的資源而導致級聯故障
Sentinel對這個問題采取了兩種手段
-
通過並發線程數進行控制
Sentinel通過限制資源並發線程的數量，來減少不穩定資源對其他資源的影響，當某個資源出現不穩定的情況下，例如響應時間過長，對資源的直接影響就是會造成線程數的逐步堆積。當線程數在特定資源上堆積到一定的數量之后，對該資源的新請求就會被拒絕。堆積的線程完成任務后才開始繼續接受請求。
-
通過響應誰極愛你對資源進行降級
除了對並發線程進行控制以外，Sentinel還可以通過響應時間來快速降級不穩定的資源，當依賴對資源出現響應時間過長后，所有對改資源的訪問都會被直接拒絕，知道過了指定的時間窗口之后才重新恢復。
Sentinel 和 Hystrix 的區別
兩者的原則是一直的，都是當一個資源出現問題時，讓其快速失敗，不要波及到其他服務，但是限制的手段上，卻采用了完全不一樣的方法
- Hystrix 采用的是線程池隔離的方法，優點是做到了資源之間的隔離，缺點是增加了線程切換的成本
- Sentinel采用的是通過並發線程的數量和響應時間來對資源做限制
-
系統負載保護
Sentinel同事提供了系統維度的自適應保護能力，當系統負載較高的時候，如果還持續讓請求進入可能會導致系統奔潰，無法響應。在集群環境下，會把本應該這台機器承載的流量轉發到其他的機器上去，如果這個時候其他的機器出在一個邊緣狀態的時候，Sentinel提供了對應的保護機制，讓系統的入口流量和系統的負載達到一個平衡，保證系統在能力范圍之內處理最多的請求
總之一句話：我們需要做的事情，就是在Sentinel的資源上配置各種各樣的規則，來實現各種容錯的功能。