微服務(wù)架構(gòu)通過定義明確的服務(wù)邊界，能有效地隔離故障。 和其他分布式系統(tǒng)一樣，微服務(wù)在網(wǎng)絡(luò)、硬件和應(yīng)用層上都會存在更多的問題。*由于服務(wù)之間是互相依賴，因此任何組件都可能出錯導(dǎo)致用戶不能訪問。為盡可能減少部分中斷帶來的影響，我們需要構(gòu)建容錯能力強的服務(wù)，以從容*應(yīng)對發(fā)生的某些中斷。

　　本文在RisingStack’s Node.js Consulting & Development experience一文基礎(chǔ)上，介紹了構(gòu)建和運維高可用的微服務(wù)架構(gòu)系統(tǒng)中最常用的技術(shù)和架構(gòu)模式。

　　如果讀者不熟悉上文中的模式，那并沒什么大礙。構(gòu)建可靠的系統(tǒng)不是一踞而就的。

　　微服務(wù)架構(gòu)的風(fēng)險

　　微服務(wù)架構(gòu)將應(yīng)用邏輯拆分成服務(wù)，服務(wù)之間通過網(wǎng)絡(luò)交互。由于是通過網(wǎng)絡(luò)調(diào)用，而不是在進程中調(diào)用，因此這給需要在多個物理和邏輯組件間進行協(xié)作的系統(tǒng)帶來了潛在的問題和復(fù)雜性。分布式系統(tǒng)變得越來越復(fù)雜，也導(dǎo)致網(wǎng)絡(luò)特定故障發(fā)生的可能性增大。

　　相比傳統(tǒng)應(yīng)用龐大的結(jié)構(gòu)，微服務(wù)架構(gòu)最大的一個優(yōu)點是團隊能獨立地設(shè)計、開發(fā)和部署各自的服務(wù)。團隊能掌控各自服務(wù)的整個生命周期。這也意味者團隊無法控制服務(wù)的依賴關(guān)系，因為這些依賴的服務(wù)可能是由其他團隊管理。在微服務(wù)架構(gòu)體系下，我們要牢記提供的服務(wù)由于是其他人控制，因此可能會由于發(fā)布、配置、和其他變更等原因，從而導(dǎo)致服務(wù)暫時不可用，而且組件之間互相獨立。

　　優(yōu)雅的服務(wù)降級

　　微服務(wù)架構(gòu)最大的優(yōu)點之一就是當(dāng)組件出現(xiàn)故障時，能隔離這些故障并且能做到優(yōu)雅地服務(wù)降級。比如，在圖片分享應(yīng)用中，當(dāng)出現(xiàn)故障時，用戶可能無法上傳圖片，但他們依然能瀏覽、編輯和分享已上傳的圖片。

　　微服務(wù)故障獨立（理論上）

　　在大多數(shù)情況下，是很難實現(xiàn)上圖這種優(yōu)雅地服務(wù)降級的，因為在分布式環(huán)境下，應(yīng)用都是互相依賴的，開發(fā)者需要實現(xiàn)若干錯誤處理的邏輯（該部分在本文稍后部分討論）去應(yīng)對短暫的故障和中斷。

　　服務(wù)互相依賴，如果無故障轉(zhuǎn)移的邏輯，則會同時失效

　　變更管理

　　Google的網(wǎng)站可靠性團隊發(fā)現(xiàn)大概70%的故障都是由于變更而引起的。當(dāng)對服務(wù)進行修改時—例如發(fā)布代碼的新版本或者改變一些配置，則總會有可能引起故障或者引入新的錯誤。

　　在微服務(wù)架構(gòu)中，服務(wù)是互相依賴的。這就是為什么你需要減少故障并且盡可能降低它們的負(fù)面影響。為了應(yīng)對變更帶來的問題，你可以實施變更策略管理并且實現(xiàn)其自動回滾。

　　比如，當(dāng)部署新的代碼或者修改配置時，應(yīng)該分步將這些變更部署到服務(wù)實例群中的部分實例中，并且進行監(jiān)控，如果發(fā)現(xiàn)關(guān)鍵指標(biāo)出現(xiàn)問題則能自動進行回滾。

　　變更管理－回滾部署

　　另一個解決方案是運行兩套生產(chǎn)環(huán)境。部署的時候只部署變更的應(yīng)用到其中一套環(huán)境中，并且在驗證了新發(fā)布的版本符合預(yù)期后，才將負(fù)責(zé)均衡的流量指向新的應(yīng)用，這種方法稱為“藍-綠發(fā)布”或者“紅-黑發(fā)布”。

　　回退代碼并不是壞事情。你不應(yīng)該在生產(chǎn)環(huán)境中部署有問題的代碼，并且應(yīng)該琢磨哪里出錯了。當(dāng)必要時候應(yīng)該果斷回退代碼，這越早越好。

　　健康檢查和負(fù)載均衡

　　因為故障或部署、自動擴展等原因，服務(wù)實例會不停啟動，重新啟動及停止。這使得服務(wù)暫時或一直停用。為了避免發(fā)生這些問題，在負(fù)載均衡中應(yīng)該在路由中設(shè)置忽略這些實例，因為它們無法為子系統(tǒng)或用戶提供服務(wù)。

　　我們可以通過外部觀察去判斷應(yīng)用實例是否健康。你可以多次調(diào)用

　　Get /health的端點（endpoint）或者通過自身服務(wù)的報告獲得相關(guān)信息?，F(xiàn)在的

　　服務(wù)發(fā)現(xiàn)解決方案會持續(xù)從實例中收集健康信息，并且設(shè)置負(fù)載均衡的路由，讓其只指向健康的實例組件。

　　自我修復(fù)

　　自我修復(fù)能幫助恢復(fù)應(yīng)用。我們討論下當(dāng)應(yīng)用遇到崩潰狀態(tài)后，如何通過相關(guān)的步驟去自我修復(fù)。在大多數(shù)情況下，是通過外部系統(tǒng)監(jiān)控實例的狀態(tài)，當(dāng)服務(wù)出現(xiàn)故障一段時間后則會重啟服務(wù)。在大多數(shù)情況下，自我修復(fù)的功能是相當(dāng)有用的，然而，在某些情況下由于不斷地重啟服務(wù)會帶來相關(guān)的問題。例如當(dāng)服務(wù)過載或者數(shù)據(jù)庫連接超時，則會導(dǎo)致應(yīng)用不能反饋正確的服務(wù)健康狀態(tài)。

　　對于一些場景-比如數(shù)據(jù)庫鏈接丟失，這個時候?qū)崿F(xiàn)高級的自我修復(fù)功能是頗為棘手的。在這種情況下，需要為應(yīng)用添加額外的邏輯去處理這些特例，并且讓外部系統(tǒng)知道服務(wù)的實例不需要立即重新啟動。

　　故障轉(zhuǎn)移緩存（Failover Caching）

　　因為網(wǎng)絡(luò)問題和系統(tǒng)中的變更，服務(wù)通常會出現(xiàn)故障。然而，這些故障中斷大多是暫時的，這要歸功于自我修復(fù)和高級負(fù)載平衡的功能，我們應(yīng)該找到一個解決方案，能使服務(wù)即使在出現(xiàn)故障的時候也能工作。這就是故障轉(zhuǎn)移緩存（Failover Caching），它能幫助為我們的應(yīng)用提供必需的數(shù)據(jù)。

　　失效轉(zhuǎn)移緩存通常使用兩個不同的過期日期：其中更短的日期指示在正常情況下能使用緩存的時間，而更長的一個日期則指示在故障失效的時候，能使用緩存中的數(shù)據(jù)時長。

　　故障轉(zhuǎn)移緩存

　　特別需要提醒的是，只有當(dāng)提供過時的數(shù)據(jù)比沒有數(shù)據(jù)更好的情況下，才能使用故障轉(zhuǎn)移緩存。

　　要設(shè)置緩存和故障轉(zhuǎn)移緩存，可以在HTTP中使用標(biāo)準(zhǔn)響應(yīng)頭。

　　例如，使用max-age頭可以指定某個資源為新資源的最大時間（譯者注：意即設(shè)定max-age后，瀏覽器不再發(fā)送請求到服務(wù)器）?？梢允褂胹tale-if-error 頭去確定在出現(xiàn)故障的情況下，從緩存獲取資源的時間長短。

　　現(xiàn)在的CDN和負(fù)載均衡器提供了各種緩存和故障轉(zhuǎn)移的解決方案，但是你也可以在你的公司中建立一個共享庫，其中包括這些標(biāo)準(zhǔn)的可靠性解決方案。

　　重試邏輯（Retry Logic）

　　在某些情況下，我們可能無法緩存數(shù)據(jù)，或者想對數(shù)據(jù)進行變更，但是操作最終失敗了。在這種情況下，我們就可以選擇重試操作，因為我們可以預(yù)期資源將在一段時間后恢復(fù)，或者負(fù)載均衡會將請求發(fā)送到健康的實例上。

　　你應(yīng)該小心地為應(yīng)用程序和客戶端添加重試邏輯，因為更大量的重試操作可能會使事情變得更糟，甚至阻止應(yīng)用程序恢復(fù)。

　　在分布式系統(tǒng)中，微服務(wù)系統(tǒng)重試可能會觸發(fā)多個其他請求或重試操作，并導(dǎo)致級聯(lián)效應(yīng)。為減少重試帶來的影響，你應(yīng)該減少重試的數(shù)量，并使用指數(shù)退避算法（exponential backoff algorithm）來持續(xù)增加重試之間的延遲時間，直到達到最大限制。

　　由于重試是由客戶端（瀏覽器，其他微服務(wù)等）發(fā)起的，并且客戶端在處理請求前后是不知道草走失敗的，你應(yīng)該為你的應(yīng)用程序提供冪等處理能力。例如，當(dāng)你重試購買操作時，不應(yīng)該向客戶收兩次錢。給每個事務(wù)使用唯一的冪等鍵（idempotency-key）是解決重試問題的方法。

　　限流器和負(fù)載開關(guān)（Rate Limiters and Load Shedders）

　　限流是指在一段時間內(nèi)，定義某個客戶或應(yīng)用可以接收或處理多少個請求的技術(shù)。例如，通過限流，你可以過濾掉產(chǎn)生流量峰值的客戶和微服務(wù)，或者可以確保你的應(yīng)用程序在自動擴展（Auto Scaling）失效前都不會出現(xiàn)過載的情況。

　　你還可以阻止較低優(yōu)先級的流量，以便為關(guān)鍵事務(wù)提供足夠的資源。

　　限流器可以阻止流量峰值

　　另外有一種限流器，稱為 “并發(fā)請求限流器（concurrent request limiter）”。當(dāng)你有一些比較昂貴和重要的端點（endpoint），希望它不應(yīng)該被調(diào)用超過指定的次數(shù)，但仍然想要提供流量服務(wù)時，這個限流器就十分有用了。

　　使用負(fù)載開關(guān)可以確保對于關(guān)鍵的事務(wù)總能提供足夠的資源保障。它為高優(yōu)先級的請求保留一些資源，并且不允許低優(yōu)先級的事務(wù)去占用這些資源。負(fù)載開關(guān)會根據(jù)系統(tǒng)的整體狀態(tài)做出決定，而不是基于單個用戶的請求桶（request bucket）大小。負(fù)載設(shè)備有助于你的系統(tǒng)恢復(fù)，因為它們在持續(xù)發(fā)生故障事件時，依然能保持核心功能正常工作。

　　關(guān)于更多限流器和負(fù)載開關(guān)的知識，建議讀者參考Stripe

　　快速且單獨失效（Fail Fast and Independently）

　　在微服務(wù)體系架構(gòu)中，我們希望服務(wù)可以快速、單獨地失效。為了在服務(wù)層面隔離故障，我們可以使用隔板模式（bulkhead pattern）。可以在本文稍后看到相關(guān)介紹。

　　我們也希望我們的組件能夠快速失效（fail fast），因為我們不希望等到斷開的實例直到超時。沒有什么比掛起的請求和無響應(yīng)的界面更令人失望。這不僅浪費資源，而且還會讓用戶體驗變得更差。我們的服務(wù)是互相調(diào)用的，所以在這些延遲疊加前，應(yīng)該特別注意防止那些超時的操作。

　　你想到的第一個辦法，可能是對每個服務(wù)的調(diào)用都定義超時的級別。這種做法的問題是，你不能真正知道到底什么是恰當(dāng)?shù)某瑫r值，因為當(dāng)網(wǎng)絡(luò)故障和其他問題發(fā)生時，某些情況下只會影響一兩次操作。在這種情況下，如果只有其中一些發(fā)生超時，你可能不想拒絕所有這些請求。

　　我們可以說，通過使用超時（timeout）來實現(xiàn)微服務(wù)中的快速失敗是一種反模式，這是應(yīng)該避免的?？梢允褂没诓僮鞯某晒?失敗統(tǒng)計次數(shù)的熔斷模式，而不是使用超時。

　　艙壁模式（Bulkheads）

　　在工業(yè)領(lǐng)域中，常使用艙壁將船劃分為幾個部分，以便在有某部分船體發(fā)生破裂時，其他部分依然能密封安然無恙。

　　艙壁的概念也可以在軟件開發(fā)中用于隔離資源。

　　通過使用艙壁模式，我們可以保護有限的資源不被用盡。例如，如果我們有兩種類型的操作的話，它們都是和同一個數(shù)據(jù)庫實例進行通信，并且數(shù)據(jù)據(jù)庫限制連接數(shù)，這時我們可以使用兩個連接池而不是使用一個共享的連接池。由于這種客戶端和資源分離，超時或過度使用池的操作不會令所有其他操作失效。

　　泰坦尼克號沉沒的主要原因之一是其艙壁設(shè)計失敗，水可以通過上面的甲板倒在艙壁的頂部，最后整個船淹沒。

　　泰坦尼克號故障的艙壁

　　斷路器（Circuit Breakers）

　　為了限制操作的持續(xù)時間，我們可以使用超時。超時可以防止掛起操作并保證系統(tǒng)可以響應(yīng)。然而，在微服務(wù)架構(gòu)通信中使用靜態(tài)、微調(diào)的超時是一種反模式，因為我們處于高度動態(tài)的環(huán)境中，幾乎不可能確定在每種情況下都能正常工作的準(zhǔn)確的時間限制。

　　我們可以使用斷路器來處理錯誤，而不是使用小型和特定基于事務(wù)的靜態(tài)超時機制。斷路器以現(xiàn)實世界的電子元件命名，因為它們的行為是都是相同的。你可以保護資源，并通過使用斷路器協(xié)助它們進行恢復(fù)。斷路器在分布式系統(tǒng)中非常有用，因為重復(fù)的故障可能會導(dǎo)致雪球效應(yīng)，并使整個系統(tǒng)崩潰。

　　當(dāng)在短時間內(nèi)多次發(fā)生指定類型的錯誤時，斷路器會開啟。開啟的斷路器可以拒絕接下來更多的請求 – 就像防止真實的電子流動一樣。斷路器通常在一定時間后關(guān)閉，以便為底層服務(wù)提供足夠的空間來恢復(fù)。

　　請記住，并不是所有的錯誤都應(yīng)該觸發(fā)斷路器。例如，你可能希望忽略客戶端問題，比如4xx響應(yīng)代碼的請求，但要包括5xx服務(wù)器端故障。一些斷路器還可以有半開關(guān)狀態(tài)。在這種狀態(tài)下，服務(wù)發(fā)送第一個請求以檢查系統(tǒng)的可用性，同時讓其他請求失敗。如果這個第一個請求成功，則將斷路器恢復(fù)到關(guān)閉狀態(tài)并繼續(xù)接受流量。否則，保持打開狀態(tài)。

　　斷路器

　　故障測試（Testing for Failures）

　　你應(yīng)該持續(xù)地測試系統(tǒng)的常見問題，以確保你的服務(wù)可在各類故障環(huán)境下運行。你應(yīng)經(jīng)常測試故障，以讓你的團隊對可能發(fā)生的事故有所準(zhǔn)備。

　　關(guān)于測試，你可以使用外部服務(wù)來識別服務(wù)實例組，并隨機終止運行組中的一個實例。通過使用這個方法，可以針對單個實例故障進行測試，你甚至可以關(guān)閉整個服務(wù)組來模擬云提供商層面的故障中斷。

　　最流行的測試解決方案之一是Netflix的ChaosMonkey工具。

　　總結(jié) 實施和運維可靠的服務(wù)并不容易。這需要你付出很多努力，還要花費公司更多的成本。

　　可靠性有很多層次和方面，因此針對你的團隊找出合適的解決方案是相當(dāng)重要的。你應(yīng)該將可靠性成為業(yè)務(wù)決策流程中的一個因素，并為此分配足夠的預(yù)算和時間。

　　要點

　　動態(tài)環(huán)境和分布式系統(tǒng)-如微服務(wù)將導(dǎo)致更高的故障機會。

　　服務(wù)應(yīng)單獨失效，實現(xiàn)優(yōu)雅的服務(wù)降級以提升用戶體驗。

　　70％的問題是由變更引起的，恢復(fù)可用代碼并不總是壞事。

　　快速，單獨地失敗。團隊無法控制其服務(wù)依賴關(guān)系。

　　架構(gòu)模式和技術(shù)，如緩存、隔離技術(shù)、斷路器和限流器有助于構(gòu)建可靠的微服務(wù)。

相關(guān)電子資料下載

• SpringCloud微服務(wù)架構(gòu)：實現(xiàn)分布式系統(tǒng)的無縫協(xié)作 62
• 微服務(wù)架構(gòu)組件分析,看這篇就夠了 285
• 【Spring Cloud 】基于微服務(wù)架構(gòu)的智慧工地監(jiān)管平臺源碼帶APP 150
• 微服務(wù)架構(gòu)必讀篇-網(wǎng)關(guān) 149
• 潤和軟件HopeStage操作系統(tǒng)與聯(lián)奕科技微服務(wù)架構(gòu)統(tǒng)一權(quán)限管理軟件完成產(chǎn)品兼容 297
• 釋放微服務(wù)架構(gòu)全部潛力的關(guān)鍵 158
• 微服務(wù)架構(gòu)中的數(shù)據(jù)一致性解決方案與實踐 123
• 微服務(wù)架構(gòu)面臨的各服務(wù)間的通信問題如何解決 156
• 開源賦能 普惠未來｜UBSICE誠邀您參與2023開放原子全球開源峰會 96
• 微服務(wù)架構(gòu)下網(wǎng)關(guān)的技術(shù)選型 204