建站
咨詢
售后
建站咨詢
新聞中心
并發(fā)對(duì)系統(tǒng)的影響
當(dāng)一個(gè)系統(tǒng)的架構(gòu)設(shè)計(jì)采用微服務(wù)架構(gòu)模式時(shí)，會(huì)將龐大而復(fù)雜的業(yè)務(wù)拆分成一個(gè)個(gè)小的微服務(wù)，各個(gè)微服務(wù)之間以接口或者RPC的形式進(jìn)行互相調(diào)用。在調(diào)用的過(guò)程中，就會(huì)涉及到網(wǎng)路的問(wèn)題，再加上微服務(wù)自身的原因，例如很難做到100%的高可用等。
如果眾多微服務(wù)當(dāng)中的某個(gè)或某些微服務(wù)出現(xiàn)問(wèn)題，不可用或者宕機(jī)了，那么其他微服務(wù)調(diào)用這些微服務(wù)的接口時(shí)就會(huì)出現(xiàn)延遲。如果此時(shí)有大量請(qǐng)求進(jìn)入系統(tǒng)，就會(huì)造成請(qǐng)求任務(wù)的大量堆積，甚至?xí)斐烧w服務(wù)的癱瘓。
壓測(cè)說(shuō)明
為了更加直觀的說(shuō)明當(dāng)系統(tǒng)沒(méi)有容錯(cuò)能力時(shí)，高并發(fā)、大流量場(chǎng)景對(duì)于系統(tǒng)的影響，我們?cè)谶@里模擬一個(gè)并發(fā)的場(chǎng)景。在訂單微服務(wù)shop-order的io.binghe.shop.order.controller.OrderController類中新增一個(gè)concurrentRequest()方法，源碼如下所示。
@GetMapping(value = "/concurrent_request")
public String concurrentRequest(){
log.info("測(cè)試業(yè)務(wù)在高并發(fā)場(chǎng)景下是否存在問(wèn)題");
return "binghe";
}
接下來(lái)，為了更好的演示效果，我們限制下Tomcat處理請(qǐng)求的最大并發(fā)數(shù)，在訂單微服務(wù)shop-order的resources目錄下的application.yml文件中添加如下配置。
server:
port: 8080
tomcat:
max-threads: 20
限制Tomcat一次最多只能處理20個(gè)請(qǐng)求。接下來(lái)，我們就使用JMeter對(duì) http://localhost:8080/order/submit_order 接口進(jìn)行壓測(cè)，由于訂單微服務(wù)中沒(méi)有做任何的容錯(cuò)處理，當(dāng)對(duì) http://localhost:8080/order/submit_order 接口的請(qǐng)求壓力過(guò)大時(shí)，我們?cè)僭L問(wèn)http://localhost:8080/order/concurrent_request 接口時(shí)，會(huì)發(fā)現(xiàn)http://localhost:8080/order/concurrent_request 接口會(huì)受到并發(fā)請(qǐng)求的影響，訪問(wèn)很慢甚至根本訪問(wèn)不到。
壓測(cè)實(shí)戰(zhàn)
使用JMeter對(duì) http://localhost:8080/order/submit_order 接口進(jìn)行壓測(cè)，JMeter的配置過(guò)程如下所示。
(1)打開(kāi)JMeter的主界面，如下所示。
(2)在JMeter中右鍵測(cè)試計(jì)劃添加線程組，如下所示。
(3)在JMeter中的線程組中配置并發(fā)線程數(shù)，如下所示。
如上圖所示，將線程數(shù)配置成50，Ramp-Up時(shí)間配置成0，循環(huán)次數(shù)為100。表示JMeter每次會(huì)在同一時(shí)刻向系統(tǒng)發(fā)送50個(gè)請(qǐng)求，發(fā)送100次為止。
(4)在JMeter中右鍵線程組添加HTTP請(qǐng)求，如下所示。
(5)在JMeter中配置HTTP請(qǐng)求，如下所示。
具體配置如下所示。
- 協(xié)議：http
- 服務(wù)器名稱或IP：localhost
- 端口號(hào)：8080
- 方法：GET
- 路徑：/order/submit_order?userId=1001&productId=1001&count=1
- 內(nèi)容編碼：UTF-8
(6)配置好JMeter后，點(diǎn)擊JMeter上的綠色小三角開(kāi)始?jí)簻y(cè)，如下所示。
點(diǎn)擊后會(huì)彈出需要保存JMeter腳本的彈出框，根據(jù)實(shí)際需要點(diǎn)擊保存即可。
點(diǎn)擊保存后，開(kāi)始對(duì) http://localhost:8080/order/submit_order 接口進(jìn)行壓測(cè)，在壓測(cè)的過(guò)程中會(huì)發(fā)現(xiàn)訂單微服務(wù)打印日志時(shí)，會(huì)比較卡頓，同時(shí)在瀏覽器或其他工具中訪問(wèn)http://localhost:8080/order/concurrent_request 接口會(huì)卡頓，甚至根本訪問(wèn)不到。
說(shuō)明訂單微服務(wù)中的某個(gè)接口一旦訪問(wèn)的并發(fā)量過(guò)高，其他接口也會(huì)受到影響，進(jìn)而導(dǎo)致訂單微服務(wù)整體不可用。為了說(shuō)明這個(gè)問(wèn)題，我們?cè)賮?lái)看看服務(wù)雪崩是個(gè)什么鬼。
服務(wù)雪崩
系統(tǒng)采用分布式或微服務(wù)的架構(gòu)模式后，由于網(wǎng)絡(luò)或者服務(wù)自身的問(wèn)題，一般服務(wù)是很難做到100%高可用的。如果一個(gè)服務(wù)出現(xiàn)問(wèn)題，就可能會(huì)導(dǎo)致其他的服務(wù)級(jí)聯(lián)出現(xiàn)問(wèn)題，這種故障性問(wèn)題會(huì)在整個(gè)系統(tǒng)中不斷擴(kuò)散，進(jìn)而導(dǎo)致服務(wù)不可用，甚至宕機(jī)，最終會(huì)對(duì)整個(gè)系統(tǒng)造成災(zāi)難性后果。
為了最大程度的預(yù)防服務(wù)雪崩，組成整體系統(tǒng)的各個(gè)微服務(wù)需要支持服務(wù)容錯(cuò)的功能。
服務(wù)容錯(cuò)方案
服務(wù)容錯(cuò)在一定程度上就是盡最大努力來(lái)兼容錯(cuò)誤情況的發(fā)生，因?yàn)樵诜植际胶臀⒎?wù)環(huán)境中，不可避免的會(huì)出現(xiàn)一些異常情況，我們?cè)谠O(shè)計(jì)分布式和微服務(wù)系統(tǒng)時(shí)，就要考慮到這些異常情況的發(fā)生，使得系統(tǒng)具備服務(wù)容錯(cuò)能力。
常見(jiàn)的服務(wù)錯(cuò)誤方案包含：服務(wù)限流、服務(wù)隔離、服務(wù)超時(shí)、服務(wù)熔斷和服務(wù)降級(jí)等。
服務(wù)限流
服務(wù)限流就是限制進(jìn)入系統(tǒng)的流量，以防止進(jìn)入系統(tǒng)的流量過(guò)大而壓垮系統(tǒng)。其主要的作用就是保護(hù)服務(wù)節(jié)點(diǎn)或者集群后面的數(shù)據(jù)節(jié)點(diǎn)，防止瞬時(shí)流量過(guò)大使服務(wù)和數(shù)據(jù)崩潰(如前端緩存大量實(shí)效)，造成不可用;還可用于平滑請(qǐng)求。
限流算法有兩種，一種就是簡(jiǎn)單的請(qǐng)求總量計(jì)數(shù)，一種就是時(shí)間窗口限流(一般為1s)，如令牌桶算法和漏牌桶算法就是時(shí)間窗口的限流算法。
服務(wù)隔離
服務(wù)隔離有點(diǎn)類似于系統(tǒng)的垂直拆分，就按照一定的規(guī)則將系統(tǒng)劃分成多個(gè)服務(wù)模塊，并且每個(gè)服務(wù)模塊之間是互相獨(dú)立的，不會(huì)存在強(qiáng)依賴的關(guān)系。如果某個(gè)拆分后的服務(wù)發(fā)生故障后，能夠?qū)⒐收袭a(chǎn)生的影響限制在某個(gè)具體的服務(wù)內(nèi)，不會(huì)向其他服務(wù)擴(kuò)散，自然也就不會(huì)對(duì)整體服務(wù)產(chǎn)生致命的影響。
互聯(lián)網(wǎng)行業(yè)常用的服務(wù)隔離方式有：線程池隔離和信號(hào)量隔離。
服務(wù)超時(shí)
整個(gè)系統(tǒng)采用分布式和微服務(wù)架構(gòu)后，系統(tǒng)被拆分成一個(gè)個(gè)小服務(wù)，就會(huì)存在服務(wù)與服務(wù)之間互相調(diào)用的現(xiàn)象，從而形成一個(gè)個(gè)調(diào)用鏈。形成調(diào)用鏈關(guān)系的兩個(gè)服務(wù)中，主動(dòng)調(diào)用其他服務(wù)接口的服務(wù)處于調(diào)用鏈的上游，提供接口供其他服務(wù)調(diào)用的服務(wù)處于調(diào)用鏈的下游。
服務(wù)超時(shí)就是在上游服務(wù)調(diào)用下游服務(wù)時(shí)，設(shè)置一個(gè)最大響應(yīng)時(shí)間，如果超過(guò)這個(gè)最大響應(yīng)時(shí)間下游服務(wù)還未返回結(jié)果，則斷開(kāi)上游服務(wù)與下游服務(wù)之間的請(qǐng)求連接，釋放資源。
服務(wù)熔斷
在分布式與微服務(wù)系統(tǒng)中，如果下游服務(wù)因?yàn)樵L問(wèn)壓力過(guò)大導(dǎo)致響應(yīng)很慢或者一直調(diào)用失敗時(shí)，上游服務(wù)為了保證系統(tǒng)的整體可用性，會(huì)暫時(shí)斷開(kāi)與下游服務(wù)的調(diào)用連接。這種方式就是熔斷。
服務(wù)熔斷一般情況下會(huì)有三種狀態(tài)：關(guān)閉、開(kāi)啟和半熔斷。
- 關(guān)閉狀態(tài)：服務(wù)一切正常，沒(méi)有故障時(shí)，上游服務(wù)調(diào)用下游服務(wù)時(shí)，不會(huì)有任何限制。
- 開(kāi)啟狀態(tài)：上游服務(wù)不再調(diào)用下游服務(wù)的接口，會(huì)直接返回上游服務(wù)中預(yù)定的方法。
- 半熔斷狀態(tài)：處于開(kāi)啟狀態(tài)時(shí)，上游服務(wù)會(huì)根據(jù)一定的規(guī)則，嘗試恢復(fù)對(duì)下游服務(wù)的調(diào)用。此時(shí)，上游服務(wù)會(huì)以有限的流量來(lái)調(diào)用下游服務(wù)，同時(shí)，會(huì)監(jiān)控調(diào)用的成功率。如果成功率達(dá)到預(yù)期，則進(jìn)入關(guān)閉狀態(tài)。如果未達(dá)到預(yù)期，會(huì)重新進(jìn)入開(kāi)啟狀態(tài)。
服務(wù)降級(jí)
服務(wù)降級(jí)，說(shuō)白了就是一種服務(wù)托底方案，如果服務(wù)無(wú)法完成正常的調(diào)用流程，就使用默認(rèn)的托底方案來(lái)返回?cái)?shù)據(jù)。例如，在商品詳情頁(yè)一般都會(huì)展示商品的介紹信息，一旦商品詳情頁(yè)系統(tǒng)出現(xiàn)故障無(wú)法調(diào)用時(shí)，會(huì)直接獲取緩存中的商品介紹信息返回給前端頁(yè)面。
新聞名稱：服務(wù)容錯(cuò)：服務(wù)雪崩與容錯(cuò)方案
網(wǎng)站鏈接：http://m.5511xx.com/article/coeposg.html
