Azure 平台復原

在雲端中建置可靠的應用程式不同於傳統內部部署應用程式的開發。 雖然在過去，您購買高階硬體是為了擴大，但在雲端環境中，您可以擴增。目標不是試圖防止失敗，而是將其影響降至最低並保持系統穩定。

也就是說，可靠的雲端應用程式會展現不同的特性：

• 這些應用程式具有復原能力，可從問題中順利復原，並繼續運作。
• 具有高可用性 (HA)，可依據設計訴求在健全狀態下執行，並且沒有重大的停機時間。

了解這些特性如何一起運作及如何影響成本，都是建置可靠雲端原生應用程式的要素。 接下來，我們將探討如何利用 Azure 雲端的功能，在雲端原生應用程式中建置復原能力和可用性。

復原設計

如先前所述，復原能力可讓應用程式回應失敗，並保持運作。 ＜Azure 中的復原能力＞白皮書提供在 Azure 平台中達到復原能力的指引。 部分重要建議如下：

• 硬體故障。 透過將元件部署在不同的容錯網域上，來為應用程式建置備援。 例如，使用可用性設定組，確保 Azure VM 放在不同的機架中。

• 資料中心故障。 為資料中心上有容錯隔離區域的應用程式建置備援。 例如，使用 Azure 可用性區域，確保 Azure VM 放在不同的容錯隔離資料中心。

• 區域故障。 將資料和元件複寫到另一個區域，以便快速復原應用程式。 例如，使用 Azure Site Recovery 將 Azure VM 複寫到另一個 Azure 區域。

• 重載。 跨執行個體進行負載平衡，以因應使用量尖峰。 例如，將兩個以上的 Azure VM 放在負載平衡器後方，以將流量分散到所有 VM。

• 意外刪除或損毀資料。 備份資料，以便在發生任何資料刪除或損毀時還原資料。 例如，使用 Azure 備份定期備份您的 Azure VM。

備援設計

故障因影響範圍而異。 硬體故障 (例如磁碟故障) 可能會影響叢集中的單一節點。 故障的網路交換器則可能影響整個伺服器機架。 較不常見的故障，例如失去電源，則可能會中斷整個資料中心。 至於整個區域都變得無法使用的情況則很罕見。

備援是提供應用程式復原能力的其中一種方式。 所需的確切備援層級取決於您的業務需求，而且會影響系統的成本和複雜度。 例如，比起單一區域部署，管理多區域部署的成本更高且更複雜。 您將需要作業程序來管理容錯移轉和容錯回復。 額外的成本和複雜度對一些商務情節可能合理，但對其他情節則不適用。

若要建構備援，您需要識別應用程式中的關鍵路徑，然後判斷路徑中的每個點上是否有備援？ 如果子系統失敗，應用程式是否將容錯移轉到其他項目？ 最後，您需要清楚了解 Azure 雲端平台中內建的功能，以用於滿足備援需求。 以下是建構備援的建議：

• 部署多個服務執行個體。 如果您的應用程式相依於服務的單一執行個體，它會建立單一失敗點。 佈建多個執行個體可以提高復原能力和可擴縮性。 在 Azure Kubernetes Service 中裝載時，您可以在 Kubernetes 資訊清單檔中以宣告方式設定備援執行個體 (複本集)。 您可以在入口網站中，或透過自動調整功能，以程式設計方式管理複本計數值。

• 利用負載平衡器。 負載平衡功能可將應用程式的要求分配至狀況良好的服務執行個體，並從循環中移除狀況不良的執行個體。 部署至 Kubernetes 時，您可以在 Services 區段中的 Kubernetes 資訊清單檔中指定負載平衡。

• 規劃多區域部署。 如果您將應用程式部署至單一區域，而該區域變成無法使用，則您的應用程式也會變成無法使用。 您應用程式的服務等級協定條款可能無法接受這種情況。 請改為考慮在多個區域中部署您的應用程式及其服務。 例如，Azure Kubernetes Service (AKS) 叢集會部署到單一區域。 為了保護您的系統免於發生區域性失敗，您可以將應用程式部署到不同區域上的多個 AKS 叢集，並使用配對區域功能來協調平台更新，並排定復原工作的優先順序。

• 啟用異地複寫。 Azure SQL Database 和 Cosmos DB 等服務的異地複寫將會跨多個區域建立資料的次要複本。 雖然這兩個服務都會自動在相同區域內複寫資料，但異地複寫可讓您藉由容錯移轉至次要區域，來防範區域性中斷。 另一個以儲存容器映像為中心的異地複寫最佳做法。 若要在 AKS 中部署服務，您需要從存放庫儲存和提取映像。 Azure Container Registry 與 AKS 整合，並可安全地儲存容器映像。 若要改善效能和可用性，請考慮使用異地複寫，將映像複寫至每個 AKS 叢集所在區域中的登錄。 接著每個 AKS 叢集會從其區域中的本機容器登錄提取容器映像，如圖 6-4 所示：

圖 6-4。 跨區域複寫的資源

• 實作 DNS 流量負載平衡器。Azure 流量管理員會藉由在 DNS 層級上進行負載平衡，為重要應用程式提供高可用性。 其可以根據地理位置、叢集回應時間，甚至是應用程式端點健康情況，將流量路由至不同的區域。 例如，Azure 流量管理員可以將客戶導向與其最接近的 AKS 叢集和應用程式執行個體。 如果您在不同區域中有多個 AKS 叢集，請使用流量管理員來控制流量如何流向每個叢集中執行的應用程式。 圖 6-5 顯示此案例。

圖 6-5。 AKS 和 Azure 流量管理員

可擴縮性設計

雲端會在調整之下不斷成長。 能夠增加/減少系統資源來處理系統負載增加/減少的問題，是 Azure 雲端的重要原則。 但是，若要有效地調整應用程式，您需要了解應用程式中每個 Azure 服務的調整功能。 以下是在系統中有效實作調整的建議。

• 縮放設計。 應用程式必須設計為可供調整。 若要開始，服務應該在無狀態的情況下，才能將要求路由至任何執行個體。 具有無狀態服務也表示新增或移除執行個體不會對目前的使用者造成負面影響。

• 分割工作負載。 將網域分解成獨立自成的微服務，可讓每個服務獨立於其他服務進行調整。 一般而言，服務會有不同的可擴縮性需求和要求。 分割可讓您只調整需要調整的內容，而不需要花費不必要的成本調整整個應用程式。

• 偏好擴增雲端式應用程式偏好擴充資源，而不是擴大資源。 擴充 (也稱為水平調整) 涉及將更多服務資源新增至現有的系統，以符合並共用所需的效能層級。 擴大 (也稱為垂直調整) 涉及將現有資源取代為更強大的硬體 (更多磁碟、記憶體和處理核心)。 您可以使用某些 Azure 雲端資源中可用的自動調整功能來自動叫用擴充作業。 跨多個資源擴充也會為整體系統增加備援。 最後，擴大單一資源的成本通常比擴增許多較小資源還要昂貴。 圖 6-6 顯示這兩種方法：

圖 6-6。 擴大與擴增

• 按比例調整。 調整服務時，請從資源集方面思考。 如果您要大幅擴增特定服務，對後端資料存放區、快取和相依服務有何影響？ Cosmos DB 等某些資源可以按比例擴增，而其他許多資源則無法這麼做。 您可以確保不會將資源擴增至會耗盡其他相關資源的位置點。

• 避免親和性。 最佳做法是確保節點不需要本機親和性，通常稱為黏性工作階段 (sticky session)。 要求應該能夠路由至任何執行個體。 如果您需要保存狀態，其應該儲存至分散式快取，例如 Azure Redis 快取。

• 利用平台自動縮放功能。 盡可能使用內建的自動調整功能，而不是自訂或第三方機制。 請儘可能使用排程的調整規則，確保資源可正常使用而不會造成啟動延遲，但適度地將重新啟動自動調整新增至規則中，以在必要時因應非預期的變更。 如需詳細資訊，請參閱自動調整指引。

• 積極擴增。 最後一個做法是積極擴增，以便快速滿足立即的流量尖峰，而不會造成業務損失。 然後保守地縮減 (也就是移除不需要的執行個體)，讓系統保持穩定。 實作此作業的簡單方法是，將增加資源和移除執行個體的冷卻期間 (也就是調整作業之間的等候時間) 分別設定為 5 分鐘和最多 15 分鐘。

服務中的內建重試

我們已在先前章節中建議實作程式設計重試作業的最佳做法。 請記住，許多 Azure 服務及其對應的用戶端 SDK 也包含重試機制。 下列清單摘要說明本書討論的許多 Azure 服務重試功能：

• Azure Cosmos DB。 來自用戶端 API 的 DocumentClient 類別會自動重試失敗的嘗試。 您可以設定重試次數和等候時間上限。 用戶端 API 擲回的例外狀況是超過重試原則或非暫時性錯誤的要求。

• Azure Cache for Redis。 Redis StackExchange 用戶端會使用包含嘗試失敗時重試的連線管理員類別。 重試次數、特定重試原則和等候時間都是可設定的。

• Azure 服務匯流排： 服務匯流排用戶端會公開 RetryPolicy 類別，此類別可使用輪詢間隔、重試計數和 TerminationTimeBuffer (指定作業可能需要的最長時間) 來設定。 預設原則是重試嘗試上限為 9 次，且嘗試之間有 30 秒的輪詢期間。

• Azure SQL Database。 使用 Entity Framework Core 程式庫時會提供重試支援。

• Azure 儲存體。 儲存體用戶端程式庫支援重試作業。 這些策略會因 Azure 儲存體資料表、Blob 和佇列而有所不同。 此外，啟用異地備援功能時，主要和次要儲存體服務位置之間的替代重試也會切換。

• Azure 事件中樞。 事件中樞用戶端程式庫具有 RetryPolicy 屬性，其中包含可設定的指數輪詢功能。