1 高并發(fā)帶來的問題

在微服務(wù)架構(gòu)中，我們將業(yè)務(wù)拆分成一個個的服務(wù)，服務(wù)與服務(wù)之間可以相互調(diào)用，但是由于網(wǎng)絡(luò)
原因或者自身的原因，服務(wù)并不能保證服務(wù)的100%可用，如果單個服務(wù)出現(xiàn)問題，調(diào)用這個服務(wù)就會出現(xiàn)網(wǎng)絡(luò)延遲，此時若有大量的網(wǎng)絡(luò)涌入，會形成任務(wù)堆積，最終導(dǎo)致服務(wù)癱瘓。

接下來，我們來模擬一個高并發(fā)的場景
1 編寫java代碼

@RestController
@Slf4j
public class OrderController2 {@Autowiredprivate OrderService orderService;@Autowiredprivate ProductService productService;@RequestMapping("/order/prod/{pid}")public Order order(@PathVariable("pid") Integer pid) {log.info("接收到{}號商品的下單請求,接下來調(diào)用商品微服務(wù)查詢此商品信息", pid);
//調(diào)用商品微服務(wù),查詢商品信息Product product = productService.findByPid(pid);log.info("查詢到{}號商品的信息,內(nèi)容是:{}", pid, JSON.toJSONString(product));//模擬一次網(wǎng)絡(luò)延時try {Thread.sleep(100);} catch (InterruptedException e) {e.printStackTrace();}//下單(創(chuàng)建訂單)Order order = new Order();order.setUid(1);order.setUsername("測試用戶");order.setPid(pid);order.setPname(product.getPname());order.setPprice(product.getPprice());order.setNumber(1);//為了不產(chǎn)生太多垃圾數(shù)據(jù),暫時不做訂單保存//orderService.createOrder(order);log.info("創(chuàng)建訂單成功,訂單信息為{}", JSON.toJSONString(order));return order;}@RequestMapping("/order/message")public String message() {return "高并發(fā)下的問題測試";}
}

2 修改配置文件中tomcat的并發(fā)數(shù)

server:
port: 8091
tomcat:max-threads: 10 ?#tomcat的最大并發(fā)值修改為10,默認是200

3 接下來使用壓測工具,對請求進行壓力測試
下載地址https://jmeter.apache.org/

• 第一步：修改配置，并啟動軟件

進入bin目錄,修改jmeter.properties文件中的語言支持為language=zh_CN，然后點擊jmeter.bat
啟動軟件。

• 第二步：添加線程組?

• ?第三步：配置線程并發(fā)數(shù)

• ?第四步：添加Http取樣

• ?第五步：配置取樣，并啟動測試

?4 訪問ｍessage方法觀察效果
結(jié)論:
?此時會發(fā)現(xiàn), 由于order方法囤積了大量請求, 導(dǎo)致ｍessage方法的訪問出現(xiàn)了問題，這就是服務(wù)雪
崩的雛形。

2 服務(wù)雪崩效應(yīng)

在分布式系統(tǒng)中,由于網(wǎng)絡(luò)原因或自身的原因,服務(wù)一般無法保證 100% 可用。如果一個服務(wù)出現(xiàn)了
問題，調(diào)用這個服務(wù)就會出現(xiàn)線程阻塞的情況，此時若有大量的請求涌入，就會出現(xiàn)多條線程阻塞等待，進而導(dǎo)致服務(wù)癱瘓。
由于服務(wù)與服務(wù)之間的依賴性，故障會傳播，會對整個微服務(wù)系統(tǒng)造成災(zāi)難性的嚴重后果，這就是
服務(wù)故障的 “雪崩效應(yīng)” 。

?雪崩發(fā)生的原因多種多樣，有不合理的容量設(shè)計，或者是高并發(fā)下某一個方法響應(yīng)變慢，亦或是某臺機器的資源耗盡。我們無法完全杜絕雪崩源頭的發(fā)生，只有做好足夠的容錯，保證在一個服務(wù)發(fā)生問題，不會影響到其它服務(wù)的正常運行。也就是＂雪落而不雪崩＂。

3 常見容錯方案

要防止雪崩的擴散，我們就要做好服務(wù)的容錯，容錯說白了就是保護自己不被豬隊友拖垮的一些措
施, 下面介紹常見的服務(wù)容錯思路和組件。
常見的容錯思路
常見的容錯思路有隔離、超時、限流、熔斷、降級這幾種，下面分別介紹一下。

（1）隔離

它是指將系統(tǒng)按照一定的原則劃分為若干個服務(wù)模塊，各個模塊之間相對獨立，無強依賴。當有故
障發(fā)生時，能將問題和影響隔離在某個模塊內(nèi)部，而不擴散風(fēng)險，不波及其它模塊，不影響整體的
系統(tǒng)服務(wù)。常見的隔離方式有：線程池隔離和信號量隔離．

（2）超時

在上游服務(wù)調(diào)用下游服務(wù)的時候，設(shè)置一個最大響應(yīng)時間，如果超過這個時間，下游未作出反應(yīng)，
就斷開請求，釋放掉線程。

（3） 限流

限流就是限制系統(tǒng)的輸入和輸出流量已達到保護系統(tǒng)的目的。為了保證系統(tǒng)的穩(wěn)固運行,一旦達到
的需要限制的閾值,就需要限制流量并采取少量措施以完成限制流量的目的。

（4）熔斷

在互聯(lián)網(wǎng)系統(tǒng)中，當下游服務(wù)因訪問壓力過大而響應(yīng)變慢或失敗，上游服務(wù)為了保護系統(tǒng)整
體的可用性，可以暫時切斷對下游服務(wù)的調(diào)用。這種犧牲局部，保全整體的措施就叫做熔斷。

?服務(wù)熔斷一般有三種狀態(tài)：

• 熔斷關(guān)閉狀態(tài)（Closed）

服務(wù)沒有故障時，熔斷器所處的狀態(tài)，對調(diào)用方的調(diào)用不做任何限制

• 熔斷開啟狀態(tài)（Open）

后續(xù)對該服務(wù)接口的調(diào)用不再經(jīng)過網(wǎng)絡(luò)，直接執(zhí)行本地的fallback方法

• 半熔斷狀態(tài)（Half-Open）

嘗試恢復(fù)服務(wù)調(diào)用，允許有限的流量調(diào)用該服務(wù)，并監(jiān)控調(diào)用成功率。如果成功率達到預(yù)
期，則說明服務(wù)已恢復(fù)，進入熔斷關(guān)閉狀態(tài)；如果成功率仍舊很低，則重新進入熔斷關(guān)閉狀
態(tài)。

（5）降級

降級其實就是為服務(wù)提供一個托底方案，一旦服務(wù)無法正常調(diào)用，就使用托底方案。

?常見的容錯組件

• Hystrix

Hystrix是由Netflix開源的一個延遲和容錯庫，用于隔離訪問遠程系統(tǒng)、服務(wù)或者第三方庫，防止
級聯(lián)失敗，從而提升系統(tǒng)的可用性與容錯性。

• Resilience4J

Resilicence4J一款非常輕量、簡單，并且文檔非常清晰、豐富的熔斷工具，這也是Hystrix官方推
薦的替代產(chǎn)品。不僅如此，Resilicence4j還原生支持Spring Boot 1.x/2.x，而且監(jiān)控也支持和
prometheus等多款主流產(chǎn)品進行整合。

• Sentinel

Sentinel 是阿里巴巴開源的一款斷路器實現(xiàn)，本身在阿里內(nèi)部已經(jīng)被大規(guī)模采用，非常穩(wěn)定。
下面是三個組件在各方面的對比：

?