[譯] 設計一個容錯的微服務架構

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

[譯] 設計一個容錯的微服務架構

摘要：本文屬於原創，歡迎轉載，轉載請保留出處：https://github.com/jasonGeng88/blog

原文地址

https://blog.risingstack.com/designing-microservices-architecture-for-failure/

微服務架構使得可以通過明確定義的服務邊界來隔離故障。但是像在每個分布式系統中一樣，發生網路、硬體、應用層級的錯誤都是很常見的。由於服務依賴關係，任何組件可能暫時無法提供服務。為了盡量減少部分中斷的影響，我們需要構建容錯服務，來優雅地處理這些中斷的響應結果。

本文介紹了基於RisingStack 的 Node.js 諮詢和開發經驗構建和操作高可用性微服務系統的最常見技術和架構模式。

如果你不熟悉本文中的模式，那並不一定意味著你做錯了。建立可靠的系統總是會帶來額外的成本。

微服務架構的風險

微服務架構將應用程式邏輯移動到服務，並使用網路層在它們之間進行通訊。這種通過網路間通訊代替單應用程式內調用的做法，會帶來額外的延遲，以及需要協調多個物理和邏輯組件的系統複雜度。分布式系統的複雜性增加也將導致更高的網路故障率。

微服務體繫結構的最大優勢之一是，團隊可以獨立設計，開發和部署他們的服務。他們對服務的生命週期擁有完全的所有權。這也意味著團隊無法控制他們依賴的服務，因為它更有可能由不同的團隊管理。使用微服務架構，我們需要記住，提供者服務可能會臨時不可用，由於其他人員發行的錯誤版本，配置以及其他更改等。

優雅的服務降級

微服務架構的最大優點之一是您可以隔離故障，並在當組件單獨故障時，進行優雅的服務降級。 例如，在中斷期間，照片分享應用程式中的客戶可能無法上傳新圖片，但仍可以瀏覽，編輯和共用其現有照片。

微服務容錯隔離

在大多數情況下，由於分布式系統中的應用程式相互依賴，因此很難實現這種優雅的服務降級，您需要應用幾種容錯移轉的邏輯（其中一些將在本文後面介紹），以為暫時的故障和中斷做準備。

服務間彼此依賴，再沒有容錯移轉邏輯下，服務全部失敗。

變更管理

Google的網站可靠性小組發現，大約70％的中斷是由現有系統的變化引起的。當您更改服務中的某些內容時，您將部署新版本的代碼或更改某些配置 - 這總有可能會造成故障，或者引入新的bug。

在微服務架構中，服務依賴於彼此。這就是為什麼你應該盡量減少故障並限制它的負面影響。要處理變更中的問題，您可以實施變更管理策略和自動復原機制。

例如，當您部署新代碼或更改某些配置時，您應該先小範圍的進行部分的替換，以漸進式的方式替換服務的全部執行個體。在這期間，需要監視它們，如果您發現它們對您的關鍵計量有負面影響，應立即進行服務復原，這稱為“金絲雀部署”。

變更管理 - 復原部署

另一個解決方案可能是您運行兩個生產環境。您始終只能部署其中一個，並且在驗證新版本是否符合預期之後才，將負載平衡器指向新的。這稱為藍綠或紅黑部署。

復原代碼不是壞事。你不應該在生產中遺留錯誤的代碼，然後考慮出了什麼問題。如果必要，越早復原你的代碼越好。

健全狀態檢查與負載平衡

執行個體由於出現故障、部署或自動縮放的情況，會進行持續啟動、重新啟動或停止操作。它可能導致它們暫時或永久不可用。為避免問題，您的負載平衡器應該從路由中跳過不健康的執行個體，因為它們當前無法為客戶或子系統提供服務。

應用執行個體健康情況可以通過外部觀察來確定。您可以通過重複調用GET /health端點或通過自我報告來實現。現在主流的服務發現解決方案，會持續從執行個體中收集健康資訊，並配置負載平衡器，將流量僅路由到健康的組件上。

自我修複

自我修複可以輔助應用程式從錯誤中恢複過來。當應用程式可以採取必要步驟從故障狀態恢複時，我們就可以說它是可以實現自我修複的。在大多數情況下，它由外部系統實現，該系統會監視執行個體健全狀態，並在較長時間內處於故障狀態時重新啟動它們。自我修複在大多數情況下是非常有用的。但是在某些情況下，持續地重啟應用程式可能會導致麻煩。 當您的應用程式由於超負荷或其資料庫連接逾時而無法給出健康的健全狀態時，這種情況下的頻繁的重啟就可能就不太合適了。

對於這種特殊的情境（如丟失的資料庫連接），要實現滿足它的進階自我修複的解決方案可能很棘手。在這種情況下，您需要為應用程式添加額外的邏輯來處理邊緣情況，並讓外部系統知道執行個體不需要立即重新啟動。

容錯移轉緩衝

由於網路問題和我們系統的變化，服務經常會失敗。然而，由於自我修複和負載平衡的保障，它們中的大多數中斷是臨時的，我們應該找到一個解決方案，使我們的服務在這些故障時服務仍就可以工作。這就是容錯移轉緩衝的作用，它可以協助並為我們的應用程式在服務故障時提供必要的資料。

容錯移轉緩衝通常使用兩個不同的到期日; 較短的時間告訴您在正常情況下緩衝可以使用的到期時間，而較長的時間可以在服務故障時緩衝依舊可用的到期時間。

容錯移轉緩衝

請務必提及，只有當服務使用過時的資料比沒有資料更好時，才能使用容錯移轉緩衝。

要設定緩衝和容錯移轉緩衝，可以在 HTTP 中使用標準回應標頭。

例如，使用 max-age 屬性可以指定資源被視為有效最大時間。使用 stale-if-error 屬性，您可以明確在出現故障的情況下，依舊可以從緩衝中擷取資源的最大時間。

現代的 CDN 和負載平衡器都提供各種緩衝和容錯移轉行為，但您也可以為擁有標準可靠性解決方案的公司建立一個共用庫。

重試邏輯

在某些情況下，我們無法快取資料，或者我們想對其變更，但是我們的操作最終都失敗了。對於此，我們可以重試我們的操作，因為我們可以預期資源將在一段時間後恢複，或者我們的負載平衡器將請求發送到了健康的執行個體上。

您應該小心地為您的應用程式和用戶端添加重試邏輯，因為大量的重試可能會使事情更糟，甚至阻止應用程式恢複，如當服務超載時，大量的重試只能使狀況更糟。

在分布式系統中，微服務系統重試可以觸發多個其他請求或重試，並啟動級聯效應。為了最小化重試的影響，您應該限制它們的數量，並使用指數退避演算法來持續增加重試之間的延遲，直到達到最大限制。

當用戶端（瀏覽器，其他微服務等）發起重試，並且用戶端不知道在處理請求之前或之後操作失敗時，您應該為你的應用程式做好等冪處理的準備。例如，當您重試購買操作時，您不應該再次向客戶收取費用。為每個交易使用唯一的等冪值鍵可以協助處理重試。

限流器和負載降級

流量限制是在一段時間內定義特定客戶或應用程式可以接收或處理多少個請求的技術。例如，通過流量限制，您可以過濾掉造成流量峰值的客戶和服務，或者您可以確保您的應用程式在自動縮放無法滿足時，依然不會超載。

您還可以阻止較低優先順序的流量，為關鍵事務提供足夠的資源。

限流器可以阻止流量峰值產生

有一個不同類型的限流器，叫做並發要求節流器。當您有重要的端點，您不應該被調用超過指定的次數，而您仍然想要能提供服務時，這將是有用的。

負載降級的一系列使用，可以確保總是有足夠的資源來提供關鍵交易。它為高優先順序請求保留一些資源，不允許低優先順序的事務使用它們。負載降級開關是根據系統的整體狀態做出決定，而不是基於單個使用者的請求量大小。負載降級有助於您的系統復原，因為當你有一個輕負荷事件時（可能是一個熱時間點事件），您仍能保持核心功能的正常工作。

要瞭解有關限流器和負載降級的更多資訊，我建議查看這篇Stripe的文章。

快速失敗原則與獨立性

在微服務架構中，我們想要做到讓我們的服務具備快速失敗與相互獨立的能力。為了在服務等級上進行故障隔離，我們可以使用艙壁模式。你可以在本文的後面閱讀更多有關艙壁的內容。

我們也希望我們的組件能夠快速失敗，因為我們不希望對於有故障的服務，在請求逾時後才斷開。沒有什麼比掛起的請求和無響應的 UI 更令人失望。這不僅浪費資源，而且還會影響使用者體驗。我們的服務在調用鏈中是相互調用的，所以在這些延遲累加之前，我們應該特別注意防止掛起操作。

你想到的第一個想法是對每個服務調用都設定明確的逾時等級。這種方法的問題是，您不能知道真正合理的逾時值是多少，因為網路故障和其他問題發生的某些情況只會影響一兩次操作。在這種情況下，如果只有其中一些逾時，您可能不想拒絕這些請求。

我們可以說，在微服務種通過使用逾時來達到快速失敗的效果是一種反模式的，你應該避免使用它。取而代之，您可以應用斷路器模式，依據操作的成功與失敗統計資料決定。

艙壁模式

工業中使用艙壁將船舶劃分為幾個部分，以便在船體破壞的情況下，可以將船舶各個組件密封起來。

艙壁的概念在軟體開發中可以被應用在隔離資源上。

通過應用艙壁模式，我們可以保護有限的資源不被耗盡。例如，對於一個有串連數限制的資料庫執行個體來說，如果我們有兩種串連它的操作，我們採用可以採用兩個串連池的方式進行串連，來代替僅採用一個共用串連池的方式。由於這種用戶端與資源進行了隔離，逾時或過度使用池的操作頁不會使其他動作失敗。

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

泰坦尼克號艙壁設計（無效的設計）

斷路器

為了限制操作的期間，我們可以使用逾時。逾時可以防止掛起操作並保持系統響應。然而，在微服務中使用靜態、精細的逾時是一種反模式，因為我們處於高度動態環境中，幾乎不可能提出在每種情況下都能正常工作的正確的時間限制。

替代這種靜態逾時的手段是，我們可以使用斷路器來處理錯誤。斷路器以現實世界的電子元件命名，因為它們的作用是相同的。您可以保護資源，並協助他們使用斷路器進行恢複。它們在分布式系統中非常有用，因為在分布式系統中，重複故障可能導致雪球效應並使整個系統癱瘓。

當特定類型的錯誤在短時間內多次發生時，斷路器會被斷開。開路的斷路器可以防止進一步的請求 - 就像我們平時所說的電路跳閘一樣。斷路器通常在一定時間後關閉，在這期間可以為底層服務提供足夠的空間來恢複。

請記住，並不是所有的錯誤都應該觸發斷路器。例如，您可能希望跳過用戶端問題，例如具有4xx響應代碼的請求，但不包括5xx伺服器端故障。一些斷路器也具有半開狀態。在這種狀態下，服務發送第一個請求以檢查系統可用性，同時讓其他請求失敗。如果這個第一個請求成功，它將使斷路器恢複到關閉狀態並使流量流動。否則，它保持開啟。

斷路器

測試故障

您應該不斷測試您系統的常見問題，以確保您的服務可以抵抗各種故障。您應經常測試故障，讓您的團隊具備故障處理的能力。

對於測試，您可以使用外部服務來標識執行個體組，並隨機終止此組中的一個執行個體。這樣，您可以準備單個執行個體故障，但您甚至可以關閉整個地區來類比雲供應商的故障。

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

結尾

實施和運行可靠的服務並不容易。 您需要付出很多努力，同時公司也要有相應的財力投入。

可靠性有很多層次和方面，因此找到最適合您團隊的解決方案很重要。您應該使可靠性成為您的業務決策流程中的一個因素，並為其分配足夠的預算和時間。

主要收穫

• 動態環境和分布式系統（如微服務）會導致更高的故障機率；
• 服務應該做到故障隔離，到達優雅降級，來提升使用者體驗；
• 70％的中斷是由變化引起的，代碼復原不是一件壞事；
• 做到服務快速失敗與獨立性。團隊是無法控制他們所依賴的服務情況；
• 緩衝、艙壁、斷路器和限流器等架構模式與技術有助於構建可靠的微服務架構。