怎么提高微服務(wù)架構(gòu)的可用性

怎么提高微服務(wù)架構(gòu)的可用性，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

10多年的興山網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營(yíng)銷的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整興山建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)建站從事“興山網(wǎng)站設(shè)計(jì)”,“興山網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

業(yè)界通常用多少個(gè)9來衡量系統(tǒng)的可用性，如99.99%表示一年中有1小時(shí)左右的不可用時(shí)間。任何一個(gè)服務(wù)的可用性都不會(huì)是100%，意味著在服務(wù)運(yùn)行時(shí)間里還是有可能發(fā)生故障。當(dāng)把功能集中且運(yùn)行在同一個(gè)應(yīng)用中的單體架構(gòu)拆分成多個(gè)相互獨(dú)立的微服務(wù)架構(gòu)后，雖然可以降低一損俱損的全局性故障風(fēng)險(xiǎn)，但由于微服務(wù)之間存在大量的依賴關(guān)系， 隨著微服務(wù)個(gè)數(shù)的增多，依賴關(guān)系也將會(huì)變得越來越復(fù)雜，而且每個(gè)微服務(wù)都有可能發(fā)生故障，如果不能做好相互依賴的隔離，避免故障的連鎖反應(yīng)，結(jié)果可能比單體更糟糕。

假設(shè)有100個(gè)微服務(wù)，并且每個(gè)微服務(wù)只會(huì)發(fā)生1種故障，那么總共會(huì)有 2100 種不同的故障場(chǎng)景，而每個(gè)微服務(wù)自身可能不止1種故障。當(dāng)某個(gè)微服務(wù)發(fā)生故障時(shí)，如何確保不會(huì)導(dǎo)致其他依賴的微服務(wù)不可用， 如何確保系統(tǒng)自動(dòng)降級(jí)把發(fā)生故障的微服務(wù)排除出去，如何確保故障不會(huì)擴(kuò)展到整個(gè)系統(tǒng)？ 那么如何有效確保微服務(wù)架構(gòu)的可用性將會(huì)成為挑戰(zhàn)。
設(shè)定一個(gè)用戶請(qǐng)求依賴5個(gè)微服務(wù)的協(xié)作完成（pod為K8S容器框架中的定義，為一組相同功能的容器）。

在一開始每個(gè)依賴的Service都是正常的，現(xiàn)假設(shè)有一個(gè)Service異常了，這時(shí)可能會(huì)有三種情況：

這個(gè)請(qǐng)求成功，假設(shè)因網(wǎng)絡(luò)異常或宕機(jī)導(dǎo)致Service C某個(gè)節(jié)點(diǎn)不可用，但有高可用節(jié)點(diǎn)取代了這個(gè)失敗節(jié)點(diǎn)，這時(shí)Service C不受影響，依然可用。

這個(gè)請(qǐng)求是成功的，假設(shè)是Service D故障，而這個(gè)Service不是關(guān)鍵性的,運(yùn)行失敗也可以繼續(xù)進(jìn)行，比如注冊(cè)用戶需要調(diào)用一個(gè)服務(wù)發(fā)送注冊(cè)成功的郵件給用戶，如果發(fā)郵件的這個(gè)Service不可用，但不會(huì)影響用戶的注冊(cè)，所以用戶注冊(cè)還是會(huì)成功，郵件可以等服務(wù)恢復(fù)后再發(fā)送，只有時(shí)間上的延遲。這時(shí)Service A不受影響，依然可用，如下圖所示：

這個(gè)請(qǐng)求失敗，比如異常的節(jié)點(diǎn)是Service E，而Service E是代碼級(jí)邏輯異常，所有高可用節(jié)點(diǎn)都不可用，這時(shí)需要將Service E進(jìn)行依賴隔離，否則ServiceA可能會(huì)受到ServiceE的影響而不可用。需要做一些措施確保Service A不會(huì)受影響，依然可用。

可以從以下幾個(gè)策略可以提高微服務(wù)架構(gòu)的可用性：

1) 失效轉(zhuǎn)移
提高服務(wù)的高可用性，最基本的原則就是消除單點(diǎn)，通過負(fù)載均衡技術(shù)構(gòu)建集群，所有的集群節(jié)點(diǎn)都是無狀態(tài)且完全對(duì)等的。如上面講的第1種情況。當(dāng)一個(gè)節(jié)點(diǎn)異常時(shí)，負(fù)載均衡服務(wù)器會(huì)把用戶發(fā)送的訪問請(qǐng)求發(fā)送到可用的節(jié)點(diǎn)上。對(duì)用戶來說，某個(gè)節(jié)點(diǎn)異常是無感的，用戶請(qǐng)求會(huì)透明的轉(zhuǎn)移到了可用的節(jié)點(diǎn)上執(zhí)行。 

2) 異步調(diào)用
避免一個(gè)服務(wù)失敗導(dǎo)致整個(gè)應(yīng)用請(qǐng)求失敗很重要的是使用異步調(diào)用。如上面講的第2種情況。如果采用的是同步調(diào)用，當(dāng)郵件服務(wù)異常時(shí)，會(huì)導(dǎo)致其他兩個(gè)服務(wù)也無法執(zhí)行，最終導(dǎo)致用戶注冊(cè)失敗。如果采用異步調(diào)用，Service A把用戶注冊(cè)信息發(fā)送給消息隊(duì)列后立即返回用戶注冊(cè)成功的響應(yīng)，雖然郵件服務(wù)不能用，但是寫數(shù)據(jù)庫的服務(wù)，權(quán)限開通等服務(wù)都能正常執(zhí)行。所以即使郵件不能發(fā)送成功，也不會(huì)影響其他服務(wù)的執(zhí)行，用戶注冊(cè)可順利完成。

3) 依賴隔離
用戶請(qǐng)求發(fā)送給Service A，Service A分配線程資源通過網(wǎng)絡(luò)遠(yuǎn)程調(diào)用其他的Service，假設(shè)調(diào)用Service E發(fā)生異常時(shí)，Service A中對(duì)Service E調(diào)用的線程就可能會(huì)響應(yīng)慢或僵死，而線程是系統(tǒng)的資源，如果短時(shí)間內(nèi)得不到釋放，在高并發(fā)的情況下資源就會(huì)被耗盡，結(jié)果會(huì)導(dǎo)致Service A也不可用，雖然其他的服務(wù)依然可用。

Service A的資源是有限的，比如Service A啟動(dòng)時(shí)分配了400個(gè)線程，當(dāng)400個(gè)線程都因調(diào)用Service E時(shí)異常不能及時(shí)正常的釋放，如線程死鎖，響應(yīng)時(shí)間慢，導(dǎo)致 400個(gè)線程全部僵死在調(diào)用Service E上，這里Service A就沒有空閑的線程來接收新的用戶請(qǐng)求，這時(shí)就會(huì)導(dǎo)致Service A掛起或僵死。所以避免Service A被依賴的服務(wù)拖垮就是要確保Service A的線程資源不會(huì)被調(diào)用的依賴服務(wù)耗盡，在《Release It!》一書中總結(jié)了非常重要的兩條方法： 設(shè)置超時(shí)和使用斷路器。

1. 設(shè)置超時(shí)
   在應(yīng)用中設(shè)置服務(wù)調(diào)用的超時(shí)時(shí)間后，一旦線程的執(zhí)行時(shí)間超過了所設(shè)置的時(shí)間，就拋出異常信息，自動(dòng)斷開連接，這樣服務(wù)的線程就不會(huì)都長(zhǎng)時(shí)間僵死在調(diào)用異常的服務(wù)上，導(dǎo)致沒有空閑線程接收新的用戶請(qǐng)求，可以避免Service A因?yàn)檎{(diào)用Server E 異常而被拖垮，自身不可用。所以通過網(wǎng)絡(luò)調(diào)用外部依賴服務(wù)時(shí)，都必須設(shè)置超時(shí)。

2. 使用斷路器
   斷路器大家都不陌生，家里電表在電流過載或者短路時(shí)就會(huì)跳閘，如果不跳閘，電路就不斷開，電線就會(huì)升溫，造成火災(zāi)。有了斷路器之后，電流過載時(shí)就會(huì)自動(dòng)跳閘斷開電路，避免引起更大的災(zāi)難。在程序中也是如此，當(dāng)知道服務(wù)調(diào)用某個(gè)依賴服務(wù)有大量超時(shí)的時(shí)候，再讓新的請(qǐng)求去訪問也只會(huì)超時(shí)，并不能得到想到的結(jié)果，還會(huì)消耗現(xiàn)有資源，增加負(fù)載，導(dǎo)致服務(wù)不可用。

這個(gè)時(shí)候使用斷路器就能避免這種資源浪費(fèi)，在自身服務(wù)和依賴服務(wù)之間放一個(gè)斷路器，通過斷路器的監(jiān)控實(shí)時(shí)統(tǒng)計(jì)訪問的狀態(tài)，當(dāng)訪問超時(shí)或者失敗達(dá)到某個(gè)閾值的時(shí)候（如50%請(qǐng)求超時(shí)，或者連續(xù)20次請(qǐng)失敗），就打開斷路器，那么后續(xù)的請(qǐng)求就直接返回失敗，而不是一個(gè)長(zhǎng)時(shí)間的等待，再根據(jù)一個(gè)時(shí)間間隔（如30秒）或請(qǐng)求超時(shí)的情況（如0%的超時(shí)）嘗試關(guān)閉斷路器（或者更換保險(xiǎn)絲），看依賴是否恢復(fù)服務(wù)了。

一個(gè)服務(wù)依賴多個(gè)服務(wù)時(shí)，如果其中一個(gè)非核心的依賴不可用，通過設(shè)置超時(shí)和使用斷路器，可以確保Service A在調(diào)用異常的Service E并不會(huì)導(dǎo)致自身的異常，在大部分情況下服務(wù)還能健康運(yùn)轉(zhuǎn)，可以很好的做到依賴隔離。

4)設(shè)置限流
在服務(wù)訪問的高峰期可能因?yàn)榇罅康牟l(fā)導(dǎo)致性能下降，嚴(yán)重時(shí)將會(huì)有大量的請(qǐng)求排隊(duì)，可能會(huì)導(dǎo)致服務(wù)宕機(jī)。為了保證應(yīng)用的可用性，可拒絕低優(yōu)先級(jí)的調(diào)用，讓高優(yōu)先級(jí)的請(qǐng)求成功，避免所有調(diào)用都失敗的情況，并且為每個(gè)依賴服務(wù)提供一個(gè)小的線程池，如果線程池已滿調(diào)用將被立即拒絕，默認(rèn)不采用排隊(duì)，可以加速失敗判定時(shí)間。這樣的結(jié)果是有些用戶可以訪問，而有些用戶失敗，但失敗的用戶重新訪問又可以是正常的訪問。這樣能確保服務(wù)的可用性，而不是完全不可用。

雖然有了上面的一些可提高系統(tǒng)可用性的措施，但系統(tǒng)是復(fù)雜的，一個(gè)簡(jiǎn)單的修復(fù)都有可能造成不可想像的后果，且系統(tǒng)又是動(dòng)態(tài)的，有些系統(tǒng)可能一天都發(fā)布幾次，幾十次。在這種情況下 故障依然是不可避免的。比起半夜深睡或正在享受節(jié)假日的美好時(shí)光時(shí)系統(tǒng)故障來當(dāng)救火隊(duì)員，會(huì)做更多的措施來提高系統(tǒng)的可用性。比如在某些企業(yè)里會(huì)定期舉行生產(chǎn)環(huán)境的故障應(yīng)急演練。

過去都是在業(yè)務(wù)低峰時(shí)進(jìn)行人為故障測(cè)試高可用方案是否生效，包括主機(jī)，網(wǎng)絡(luò)，應(yīng)用，存儲(chǔ)等每一層架構(gòu)都進(jìn)行演練，而現(xiàn)在也逐漸的在正常的生產(chǎn)時(shí)間進(jìn)行故障應(yīng)急演練，檢查系統(tǒng)的高可用性。問題在于可能在演練時(shí)能夠立即恢復(fù)，但真實(shí)故障發(fā)生時(shí)還是會(huì)出現(xiàn)長(zhǎng)時(shí)間故障得不到恢復(fù)的情況。一個(gè)是演練是按照已知的場(chǎng)景制定的方案實(shí)施，二是演練的范圍基本是高可用節(jié)點(diǎn)的切換或?yàn)?zāi)備系統(tǒng)的切換，第三個(gè)問題是這個(gè)演練是人為操作，需要全員的參與，并不會(huì)頻繁的舉行。但系統(tǒng)是動(dòng)態(tài)的，這次是高可用的，不代表下周，或下個(gè)月還是高可用的。

當(dāng)單體架構(gòu)變成微服務(wù)架構(gòu)后，應(yīng)用層的演練就會(huì)變得復(fù)雜，就像前面提到的，如果每個(gè)服務(wù)只有一個(gè)故障可能都會(huì)有 2100種不同。因此需要有一種自動(dòng)的故障測(cè)試方式來回避微服務(wù)化后演練實(shí)施的可操作性。

Netflix公司提出了一種自動(dòng)故障測(cè)試的方案來提高微服務(wù)架構(gòu)的可用性。這個(gè)測(cè)試方案也是在生產(chǎn)環(huán)境中進(jìn)行，而故障測(cè)試的最終目的，是為了當(dāng)真的有故障發(fā)生時(shí)，生產(chǎn)環(huán)境不會(huì)停止服務(wù)，并且整套系統(tǒng)可以在沒有人為干預(yù)的情況下，非常優(yōu)雅地通過降級(jí)將發(fā)生故障的部分組件排除出去。他們認(rèn)為如果只在測(cè)試環(huán)境中測(cè)試，而真實(shí)生產(chǎn)環(huán)境的業(yè)務(wù)壓力，業(yè)務(wù)場(chǎng)景，環(huán)境配置、網(wǎng)絡(luò)性能和硬件性能都沒有測(cè)試過，當(dāng)故障在生產(chǎn)環(huán)境中真實(shí)發(fā)生時(shí)發(fā)現(xiàn)緩解問題的方案可能會(huì)失效。而且這個(gè)測(cè)試只在工作時(shí)間運(yùn)行，這樣工程師可以得到告警并及時(shí)響應(yīng)。

Netflix通過Peter Alvaro在論文《路徑驅(qū)動(dòng)的故障注入（Lineage-driven fault injection）》中提到了一套名為“Molly”的算法和自身的故障注入測(cè)試FIT（failure injection testing）實(shí)現(xiàn)了這套安全地自動(dòng)化故障注入測(cè)試。Molly是從一套系統(tǒng)的無故障狀態(tài)出發(fā)，然后試圖去回答說“系統(tǒng)是如何達(dá)到目前這種無故障的狀態(tài)的？”簡(jiǎn)單舉例介紹一下這個(gè)算法的原理。先利用自身的追蹤系統(tǒng)繪制一個(gè)樹來表示每個(gè)請(qǐng)求經(jīng)過的所有的微服務(wù)。

(A or R or P or B) 

在最開始，上圖中的四個(gè)節(jié)點(diǎn)都是必須的，且正常的。然后從這個(gè)正確輸出反推，隨機(jī)選擇一個(gè)節(jié)點(diǎn)注入故障，找到并構(gòu)建支持其正確性的邏輯鏈條圖 。當(dāng)節(jié)點(diǎn)注入故障后，這時(shí)可能有三種情況：

這個(gè)請(qǐng)求失敗，我們已經(jīng)找到一個(gè)節(jié)點(diǎn)會(huì)故障，從而我們可以刪除未來的實(shí)驗(yàn)中包含這個(gè)故障。
這個(gè)請(qǐng)示是成功的－但這個(gè)失敗的節(jié)點(diǎn)不是關(guān)鍵性的
這個(gè)請(qǐng)求成功，有高可用節(jié)點(diǎn)取代了這個(gè)失敗

在這個(gè)例子中，首先在Ratings中注入失敗，但請(qǐng)求是成功的。說明Rating失敗并不會(huì)影響服務(wù)的使用，那就先把這個(gè)節(jié)點(diǎn)排除，重新繪制請(qǐng)求樹。
 

(A or P or B) and (A or P or B or R)

這時(shí)可以看到，請(qǐng)求可以通過(A or P or B)的方式實(shí)現(xiàn)，也可以通過 (A or P or B or R)的方式實(shí)現(xiàn)。接下來再在Playlist中注入故障，這時(shí)請(qǐng)求還是成功的，因?yàn)檎?qǐng)求轉(zhuǎn)發(fā)到備用節(jié)點(diǎn)上執(zhí)行，這里將會(huì)有一個(gè)新的節(jié)點(diǎn)可以訪問。
 

(A or PF or B) and (A or P or B) and (A or P or B or R)

這時(shí)可以更新公式，說明可以通過(A or PF or B) and (A or P or B) and (A or P or B or R)三種方式請(qǐng)求服務(wù)。然后通過這樣不停的測(cè)試直到遍歷完所有正確輸出，沒有失敗的節(jié)點(diǎn)可以找到。

Ｍolly沒有規(guī)定怎么搜索空間，所以實(shí)現(xiàn)時(shí)會(huì)估算所有的方案，然后隨機(jī)選擇最小的方案的集合。比如，最后的方案可能是[{A}, {PF}, {B}, {P,PF}, {R,A}, {R,B} …]。先選擇所有的單節(jié)點(diǎn)注入失敗，再選擇所的有雙節(jié)點(diǎn)的組合注入失敗，依此類推。

這個(gè)測(cè)試的目的是在影響大量成員前找到和修復(fù)故障，在生產(chǎn)環(huán)境上進(jìn)行故障測(cè)試時(shí)，不能接受引起大量的問題節(jié)點(diǎn)。為了避免這個(gè)風(fēng)險(xiǎn)，只能在指定的范圍構(gòu)建測(cè)試，指定的范圍包含兩個(gè)關(guān)鍵的概念：故障范圍（failure scope）和注入點(diǎn)（injection points）。故障范圍指的是，把一次故障測(cè)試可能產(chǎn)生的影響，限制在一個(gè)可控的范圍內(nèi)，這個(gè)范圍可以小到某個(gè)特定的用戶或者設(shè)備，也可以大到所有用戶的1%。而注入點(diǎn)指的是系統(tǒng)內(nèi)計(jì)劃會(huì)發(fā)生故障的組件，比如RPC層，緩存層，或者持久層。
  

故障模擬測(cè)試從FIT服務(wù)把故障模擬元數(shù)據(jù)注入到Zuul（緣邊網(wǎng)關(guān)服務(wù)）開始，如果請(qǐng)求符合故障范圍（failure scope）則注入失敗。這個(gè)故障可能是延遲服務(wù)調(diào)用,或達(dá)到持久層失敗。每個(gè)被接觸到的注入點(diǎn)（injection points）檢查這個(gè)請(qǐng)求的上下文是否為指定要被注入故障的組件，如果是，在這個(gè)注入點(diǎn)模擬故障。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。

分享文章：怎么提高微服務(wù)架構(gòu)的可用性
分享網(wǎng)址：http://bm7419.com/article44/pcoghe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、域名注冊(cè)、營(yíng)銷型網(wǎng)站建設(shè)、ChatGPT、App設(shè)計(jì)、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)