網(wǎng)站雪崩根本原因
在大型互聯(lián)網(wǎng)站建設(shè)過程中，網(wǎng)站的性能都是受服務(wù)器主機(jī)性能約束的，比如CPU、GPU、RAM等硬件設(shè)備。由于當(dāng)前計(jì)算機(jī)硬件技術(shù)的支持有限，高性能服務(wù)器的成本巨大，我們?cè)诰W(wǎng)站搭建過程中，需要通過軟件手段來控制網(wǎng)站雪崩效應(yīng)，Hystrix可以幫我們保護(hù)服務(wù)，實(shí)現(xiàn)網(wǎng)站的高可用性。
高并發(fā)場(chǎng)景示例
比如同時(shí)有10000個(gè)用戶提交訂單，由訂單服務(wù)order的submitOrder()去處理，訂單服務(wù)order所在的服務(wù)器主機(jī)配置很低，tomcat線程池最大數(shù)設(shè)置為20。每個(gè)請(qǐng)求占用一個(gè)線程，使用完畢后才會(huì)釋放，那么線程池的線程會(huì)被全部占用，剩下的請(qǐng)求進(jìn)入緩存隊(duì)列，排隊(duì)等待線程分配。如果這種等待時(shí)間過長(zhǎng)，會(huì)產(chǎn)生如下可能問題：
- 訂單服務(wù)order的submitOrder()如果調(diào)用了其他服務(wù)會(huì)員服務(wù)、商品服務(wù)等，也可能會(huì)導(dǎo)致其他服務(wù)的線程池用盡，導(dǎo)致整個(gè)相關(guān)聯(lián)的服務(wù)都不可使用
-
服務(wù)器主機(jī)的CPU會(huì)長(zhǎng)時(shí)間的高負(fù)載運(yùn)行，產(chǎn)生物理發(fā)熱，最后操作系統(tǒng)可能會(huì)為了保護(hù)主機(jī)硬件，殺掉服務(wù)進(jìn)程或者操作系統(tǒng)自身運(yùn)行也會(huì)處于等待過程而發(fā)生卡死現(xiàn)象，導(dǎo)致訂單服務(wù)order無法運(yùn)行，從而發(fā)生服務(wù)宕機(jī)
高并發(fā)場(chǎng)景示例圖.png
高并發(fā)雪崩效應(yīng)解決方案
我們一定要明白，服務(wù)性能的瓶頸在于硬件設(shè)備，所有軟件手段，只能幫助我們盡可能的高效的使用服務(wù)器主機(jī)資源，比如提升CPU使用率等。
我們知道能量守恒定律，軟件手段不可能完美的解決高并發(fā)問題，肯定伴隨了一些其他的犧牲。比如下面的解決方案，總會(huì)伴隨著一些其他的犧牲，以少換多，以少換穩(wěn)，符合道德標(biāo)準(zhǔn)，是人們可以接受的方案。
- 服務(wù)隔離
現(xiàn)在我們了解了服務(wù)等待的直接原因是因?yàn)橐粋€(gè)tomcat線程被占用完后，其他請(qǐng)求需要進(jìn)入隊(duì)列排隊(duì)等候。在不考慮服務(wù)器主機(jī)性能瓶頸的情況下，我們可以給訂單服務(wù)order的submitOrder服務(wù)和otherServer單獨(dú)創(chuàng)建線程池，當(dāng)submitOrder出現(xiàn)高并發(fā)時(shí)，otherServer擁有自己對(duì)立的線程池，不受submitOrder線程用盡的影響。
方式：創(chuàng)建獨(dú)立線程池是最常用的服務(wù)隔離技術(shù)，另一種信號(hào)量的方式用的較少
注意：創(chuàng)建獨(dú)立線程池，必須在部署服務(wù)啟動(dòng)時(shí)創(chuàng)建出來 - 服務(wù)熔斷
當(dāng)服務(wù)出現(xiàn)高并發(fā)時(shí)，為了保護(hù)服務(wù)，避免雪崩，服務(wù)會(huì)拒絕請(qǐng)求訪問 - 服務(wù)降級(jí)
當(dāng)服務(wù)熔斷后，為了提升用戶體驗(yàn)，走降級(jí)fallback方法，給用戶一個(gè)友好提示，如：xx走神了，請(qǐng)稍后再試 - 服務(wù)限流
大量請(qǐng)求同時(shí)請(qǐng)求一個(gè)服務(wù)時(shí)，需要做服務(wù)限流，滿足規(guī)則的允許訪問，否則走服務(wù)熔斷降級(jí)。使用場(chǎng)景比如秒殺系統(tǒng)（系統(tǒng)主動(dòng)提供的高并發(fā)訪問服務(wù)），網(wǎng)站攻擊（被動(dòng)接收大量請(qǐng)求）。
常用的限流解決方案有兩種：
1 代碼層面：算法有計(jì)數(shù)器、令牌桶、漏桶
2 應(yīng)用層nginx解決限流
