小说排行榜完结版,好看的玄幻小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

服務(wù)容錯(cuò)：服務(wù)雪崩與容錯(cuò)方案

并發(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)用的過程中，就會(huì)涉及到網(wǎng)路的問題，再加上微服務(wù)自身的原因，例如很難做到100%的高可用等。

如果眾多微服務(wù)當(dāng)中的某個(gè)或某些微服務(wù)出現(xiàn)問題，不可用或者宕機(jī)了，那么其他微服務(wù)調(diào)用這些微服務(wù)的接口時(shí)就會(huì)出現(xiàn)延遲。如果此時(shí)有大量請(qǐng)求進(jìn)入系統(tǒng)，就會(huì)造成請(qǐng)求任務(wù)的大量堆積，甚至?xí)斐烧w服務(wù)的癱瘓。

壓測說明

為了更加直觀的說明當(dāng)系統(tǒng)沒有容錯(cuò)能力時(shí)，高并發(fā)、大流量場景對(duì)于系統(tǒng)的影響，我們?cè)谶@里模擬一個(gè)并發(fā)的場景。在訂單微服務(wù)shop-order的io.binghe.shop.order.controller.OrderController類中新增一個(gè)concurrentRequest()方法，源碼如下所示。

@GetMapping(value = "/concurrent_request")
public String concurrentRequest(){
    log.info("測試業(yè)務(wù)在高并發(fā)場景下是否存在問題");
    return "binghe";
}

接下來，為了更好的演示效果，我們限制下Tomcat處理請(qǐng)求的最大并發(fā)數(shù)，在訂單微服務(wù)shop-order的resources目錄下的application.yml文件中添加如下配置。


server:
  port: 8080
  tomcat:
    max-threads: 20

限制Tomcat一次最多只能處理20個(gè)請(qǐng)求。接下來，我們就使用JMeter對(duì) http://localhost:8080/order/submit_order 接口進(jìn)行壓測，由于訂單微服務(wù)中沒有做任何的容錯(cuò)處理，當(dāng)對(duì) http://localhost:8080/order/submit_order 接口的請(qǐng)求壓力過大時(shí)，我們?cè)僭L問http://localhost:8080/order/concurrent_request 接口時(shí)，會(huì)發(fā)現(xiàn)http://localhost:8080/order/concurrent_request 接口會(huì)受到并發(fā)請(qǐng)求的影響，訪問很慢甚至根本訪問不到。

壓測實(shí)戰(zhàn)

使用JMeter對(duì) http://localhost:8080/order/submit_order 接口進(jìn)行壓測，JMeter的配置過程如下所示。

(1)打開JMeter的主界面，如下所示。

(2)在JMeter中右鍵測試計(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上的綠色小三角開始?jí)簻y，如下所示。

點(diǎn)擊后會(huì)彈出需要保存JMeter腳本的彈出框，根據(jù)實(shí)際需要點(diǎn)擊保存即可。

點(diǎn)擊保存后，開始對(duì) http://localhost:8080/order/submit_order 接口進(jìn)行壓測，在壓測的過程中會(huì)發(fā)現(xiàn)訂單微服務(wù)打印日志時(shí)，會(huì)比較卡頓，同時(shí)在瀏覽器或其他工具中訪問http://localhost:8080/order/concurrent_request 接口會(huì)卡頓，甚至根本訪問不到。

說明訂單微服務(wù)中的某個(gè)接口一旦訪問的并發(fā)量過高，其他接口也會(huì)受到影響，進(jìn)而導(dǎo)致訂單微服務(wù)整體不可用。為了說明這個(gè)問題，我們?cè)賮砜纯捶?wù)雪崩是個(gè)什么鬼。

服務(wù)雪崩

系統(tǒng)采用分布式或微服務(wù)的架構(gòu)模式后，由于網(wǎng)絡(luò)或者服務(wù)自身的問題，一般服務(wù)是很難做到100%高可用的。如果一個(gè)服務(wù)出現(xiàn)問題，就可能會(huì)導(dǎo)致其他的服務(wù)級(jí)聯(lián)出現(xià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ò)在一定程度上就是盡最大努力來兼容錯(cuò)誤情況的發(fā)生，因?yàn)樵诜植际胶臀⒎?wù)環(huán)境中，不可避免的會(huì)出現(xiàn)一些異常情況，我們?cè)谠O(shè)計(jì)分布式和微服務(wù)系統(tǒng)時(shí)，就要考慮到這些異常情況的發(fā)生，使得系統(tǒng)具備服務(wù)容錯(cuò)能力。

常見的服務(wù)錯(cuò)誤方案包含：服務(wù)限流、服務(wù)隔離、服務(wù)超時(shí)、服務(wù)熔斷和服務(wù)降級(jí)等。

服務(wù)限流

服務(wù)限流就是限制進(jìn)入系統(tǒng)的流量，以防止進(jìn)入系統(tǒng)的流量過大而壓垮系統(tǒng)。其主要的作用就是保護(hù)服務(wù)節(jié)點(diǎn)或者集群后面的數(shù)據(jù)節(jié)點(diǎn)，防止瞬時(shí)流量過大使服務(wù)和數(shù)據(jù)崩潰(如前端緩存大量實(shí)效)，造成不可用;還可用于平滑請(qǐng)求。

限流算法有兩種，一種就是簡單的請(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í)間，如果超過這個(gè)最大響應(yīng)時(shí)間下游服務(wù)還未返回結(jié)果，則斷開上游服務(wù)與下游服務(wù)之間的請(qǐng)求連接，釋放資源。

服務(wù)熔斷

在分布式與微服務(wù)系統(tǒng)中，如果下游服務(wù)因?yàn)樵L問壓力過大導(dǎo)致響應(yīng)很慢或者一直調(diào)用失敗時(shí)，上游服務(wù)為了保證系統(tǒng)的整體可用性，會(huì)暫時(shí)斷開與下游服務(wù)的調(diào)用連接。這種方式就是熔斷。

服務(wù)熔斷一般情況下會(huì)有三種狀態(tài)：關(guān)閉、開啟和半熔斷。

關(guān)閉狀態(tài)：服務(wù)一切正常，沒有故障時(shí)，上游服務(wù)調(diào)用下游服務(wù)時(shí)，不會(huì)有任何限制。
開啟狀態(tài)：上游服務(wù)不再調(diào)用下游服務(wù)的接口，會(huì)直接返回上游服務(wù)中預(yù)定的方法。
半熔斷狀態(tài)：處于開啟狀態(tài)時(shí)，上游服務(wù)會(huì)根據(jù)一定的規(guī)則，嘗試恢復(fù)對(duì)下游服務(wù)的調(diào)用。此時(shí)，上游服務(wù)會(huì)以有限的流量來調(diào)用下游服務(wù)，同時(shí)，會(huì)監(jiān)控調(diào)用的成功率。如果成功率達(dá)到預(yù)期，則進(jìn)入關(guān)閉狀態(tài)。如果未達(dá)到預(yù)期，會(huì)重新進(jìn)入開啟狀態(tài)。

服務(wù)降級(jí)

服務(wù)降級(jí)，說白了就是一種服務(wù)托底方案，如果服務(wù)無法完成正常的調(diào)用流程，就使用默認(rèn)的托底方案來返回?cái)?shù)據(jù)。例如，在商品詳情頁一般都會(huì)展示商品的介紹信息，一旦商品詳情頁系統(tǒng)出現(xiàn)故障無法調(diào)用時(shí)，會(huì)直接獲取緩存中的商品介紹信息返回給前端頁面。

當(dāng)前文章：服務(wù)容錯(cuò)：服務(wù)雪崩與容錯(cuò)方案
URL分享：http://fisionsoft.com.cn/article/coeposg.html