并發(fā)對系統(tǒng)的影響

當(dāng)一個系統(tǒng)的架構(gòu)設(shè)計(jì)采用微服務(wù)架構(gòu)模式時，會將龐大而復(fù)雜的業(yè)務(wù)拆分成一個個小的微服務(wù)，各個微服務(wù)之間以接口或者RPC的形式進(jìn)行互相調(diào)用。在調(diào)用的過程中，就會涉及到網(wǎng)路的問題，再加上微服務(wù)自身的原因，例如很難做到100%的高可用等。

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

壓測說明

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

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

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

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

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

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

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

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

(2)在JMeter中右鍵測試計(jì)劃添加線程組，如下所示。

(3)在JMeter中的線程組中配置并發(fā)線程數(shù)，如下所示。

如上圖所示，將線程數(shù)配置成50，Ramp-Up時間配置成0，循環(huán)次數(shù)為100。表示JMeter每次會在同一時刻向系統(tǒng)發(fā)送50個請求，發(fā)送100次為止。

(4)在JMeter中右鍵線程組添加HTTP請求，如下所示。

(5)在JMeter中配置HTTP請求，如下所示。

具體配置如下所示。

• 協(xié)議：http
• 服務(wù)器名稱或IP：localhost
• 端口號：8080
• 方法：GET
• 路徑：/order/submit_order?userId=1001&productId=1001&count=1
• 內(nèi)容編碼：UTF-8

(6)配置好JMeter后，點(diǎn)擊JMeter上的綠色小三角開始壓測，如下所示。

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

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

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

服務(wù)雪崩

系統(tǒng)采用分布式或微服務(wù)的架構(gòu)模式后，由于網(wǎng)絡(luò)或者服務(wù)自身的問題，一般服務(wù)是很難做到100%高可用的。如果一個服務(wù)出現(xiàn)問題，就可能會導(dǎo)致其他的服務(wù)級聯(lián)出現(xiàn)問題，這種故障性問題會在整個系統(tǒng)中不斷擴(kuò)散，進(jìn)而導(dǎo)致服務(wù)不可用，甚至宕機(jī)，最終會對整個系統(tǒng)造成災(zāi)難性后果。

為了最大程度的預(yù)防服務(wù)雪崩，組成整體系統(tǒng)的各個微服務(wù)需要支持服務(wù)容錯的功能。

服務(wù)容錯方案

服務(wù)容錯在一定程度上就是盡最大努力來兼容錯誤情況的發(fā)生，因?yàn)樵诜植际胶臀⒎?wù)環(huán)境中，不可避免的會出現(xiàn)一些異常情況，我們在設(shè)計(jì)分布式和微服務(wù)系統(tǒng)時，就要考慮到這些異常情況的發(fā)生，使得系統(tǒng)具備服務(wù)容錯能力。

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

服務(wù)限流

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

限流算法有兩種，一種就是簡單的請求總量計(jì)數(shù)，一種就是時間窗口限流(一般為1s)，如令牌桶算法和漏牌桶算法就是時間窗口的限流算法。

服務(wù)隔離

服務(wù)隔離有點(diǎn)類似于系統(tǒng)的垂直拆分，就按照一定的規(guī)則將系統(tǒng)劃分成多個服務(wù)模塊，并且每個服務(wù)模塊之間是互相獨(dú)立的，不會存在強(qiáng)依賴的關(guān)系。如果某個拆分后的服務(wù)發(fā)生故障后，能夠?qū)⒐收袭a(chǎn)生的影響限制在某個具體的服務(wù)內(nèi)，不會向其他服務(wù)擴(kuò)散，自然也就不會對整體服務(wù)產(chǎn)生致命的影響。

互聯(lián)網(wǎng)行業(yè)常用的服務(wù)隔離方式有：線程池隔離和信號量隔離。

服務(wù)超時

整個系統(tǒng)采用分布式和微服務(wù)架構(gòu)后，系統(tǒng)被拆分成一個個小服務(wù)，就會存在服務(wù)與服務(wù)之間互相調(diào)用的現(xiàn)象，從而形成一個個調(diào)用鏈。形成調(diào)用鏈關(guān)系的兩個服務(wù)中，主動調(diào)用其他服務(wù)接口的服務(wù)處于調(diào)用鏈的上游，提供接口供其他服務(wù)調(diào)用的服務(wù)處于調(diào)用鏈的下游。

服務(wù)超時就是在上游服務(wù)調(diào)用下游服務(wù)時，設(shè)置一個最大響應(yīng)時間，如果超過這個最大響應(yīng)時間下游服務(wù)還未返回結(jié)果，則斷開上游服務(wù)與下游服務(wù)之間的請求連接，釋放資源。

服務(wù)熔斷

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

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

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

服務(wù)降級

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