軟體即服務 (SaaS) 組織不斷髮展，其全球業務覆蓋範圍也不斷擴大，與此同時，他們必須考慮更廣闊的地理覆蓋範圍會對其系統架構產生怎樣的影響。遷移到地理位置分散的 SaaS 模型可能會對運營、部署、敏捷性、安全性和擴充套件等方面產生影響。

這種朝著多區域模式轉變的趨勢通常代表著 SaaS 組織的重大轉變。系統運營和部署配置檔案的複雜程度越高，持續實現常見的 SaaS 交付模式敏捷性目標的難度就越大。

這篇博文重點講解了如何應對這一難題，即在滿足多區域分配需求的同時，靈活滿足市場需求。因此，本文將探討 SaaS 組織採用多區域策略的常見原因。以此為背景，我們可以深入瞭解在構建、部署和管理多區域 SaaS 環境時常用的架構模式和策略。

確定多區域問題的範圍

多區域架構的主題涵蓋範圍廣，包括廣泛的架構考慮因素，而這些因素可能會影響系統架構的很多方面。AWS 提供一系列實用資源，可從整體上為使用多區域架構提供實用指導。有許多博文和白皮書都審視了各項服務、聯網模型和常規故障轉移模式的多區域能力。本文末尾處隨附了部分多區域參考資料。

在探討過程中，更有意義的做法是專注於與多區域 SaaS 環境相關的細節和動機。本指南與更廣泛的多區域策略相結合，應該能為您提供一系列基本的考慮因素，供您確定整體的多區域策略。

為什麼要遷移到多區域 SaaS？

在我們研究多區域架構之前，首先來了解促使 SaaS 提供商採用多區域模型的動態。 在許多情況下，SaaS ISV 都可以通過傳統、基於邊緣的內容分配策略應對基本的地理位置挑戰。例如，

在達到某個特定點後，問題就會脫離靜態內容分配，更加專注於可用性、效能和區域考慮事項。在這些情況下，您必須引入新的往往也是定製的機制，從而實現多區域目標。下文列出了促使 SaaS 提供商轉而採用多區域模式的常見因素。

• 故障轉移：抵禦區域系統故障的能力，使部分或全部系統能夠有效地將負載轉移到備用區域。
• 延遲：需要處理和提供非靜態資料，同時保證不會產生長網路跳躍的開銷。
• 合規性：區域合規性要求的變化意味著資料和服務必須在區域內託管。

故障轉移是一個相當廣泛的多區域主題，往往更多地涉及到採用可以承受區域化應用程式問題的災難恢復模型。在這種模式下，SaaS 提供商往往要設法將其部分或全部環節複製到另一個區域。如果發生故障，他們的系統可以從容將流量重定向到另一個區域。

故障轉移可以通過多種不同的模型實現，並且在您的解決方案中具有不同的粒度級別。您在此方面選擇的方法將由架構性質和系統的分解情況決定。它也可能受到您在解決方案中使用的各種工具和服務的複製能力的影響。具有穩健的故障轉移策略可能對 SaaS 提供商十分有益，此類提供商的所有區域客戶都可以託管在一個共享基礎設施之中。在此模型中，您可以選擇跨區域模型來限制以區域為中心的應用程式問題的影響範圍。

另一方面，延遲和合規性是促使 SaaS 提供商採用多區域方法的更常見的因素。對於某些全球化的 SaaS 提供商來說，其應用程式的訪問模式和常規使用模式使其很難在一個區域中託管解決方案。雖然基於邊緣的內容有所幫助，但內容分發網路 (CDN) 可能無法充分涵蓋某些應用程式流程。應用程式的某些功能可能需要交換資料，而這些資料必須直接由一項或多項應用程式服務提供。在這些情況下，您可能很快就會到達臨界點，因此將部分或全部應用程式直接部署到一個區域中便是自然而然的選擇了。舉例來說，如果您正在構建需要在幾毫秒內呈現廣告的廣告投放平臺，則可能會發現從單個區域投放內容不足以滿足需求。

合規性往往受監管資料隱私的地區性法規影響。資料主權和通用資料保護法規 (GDPR) 的要求往往會施加一定的限制，只能通過某種多區域策略才能成功應對這樣的限制。即使在這些情況下，也可以選擇應用程式中受區域合規性問題影響的部分。此時，您可能會發現自己需要平衡部署和管理更為複雜的架構範圍的複雜性。通常在這些情況下，SaaS 提供商更願意將其整個解決方案遷移到一個區域。

多區域模型的影響

現在我們已經掌握了一些可以將 SaaS 提供商推向多區域模型的常見主題，接下來，我們來看看採用多區域模型對 SaaS 解決方案的設計、架構、操作和敏捷性有何影響。 我們的首要目標是找到一種方法來引入多區域的概念，同時保證不會影響大多數 SaaS 解決方案的基本敏捷性目標。

以下部分強調了轉移到多區域 SaaS 模型時需要考慮的一些關鍵方面。此列表並不完整，但如實反映了 SaaS 組織面臨的一些常見挑戰。

租戶註冊

提供順暢無憂的註冊體驗對 SaaS 組織而言至關重要。我們的目標是簡化獲取和預置新客戶環境的過程。當然，如果您的解決方案託管在多個區域，那麼就可能會給您的註冊流程增加難度。

圖 1 展示了在多區域模型中註冊租戶時可以採用的一種方法。您會注意到，我們有一些新租戶在多個區域註冊了 SaaS 解決方案。在此模型中，租戶在註冊過程中提供資料來區分其目標區域。 然後，共享註冊服務將負責編排在其指定區域預置新租戶的工作。

圖 1 – 集中化註冊模型。

該模型會嘗試將註冊流程集中在一個區域。這能簡化流程，但與此同時，也造成了合規性方面的挑戰。由於需要在各區域以外收集使用者資訊，因此可能會違反某個區域的主權要求。但是，如果您沒有遇到合規性問題，那麼這種方法會對您極具吸引力。

這種策略的另一種替代方法就是分散處理註冊流程的某些方面。 圖 2 展示了這個問題的替代方法，即將註冊流程分別分配到各區域。

圖 2 – 分散註冊模型。

基本區別在於，註冊體驗現在託管在各個區域，從而確保所收集的關於租戶的任何資料都在該區域的範圍內進行管理。這種模型的主要挑戰在於，確定租戶如何重定向到各區域的註冊體驗。為此，我們引入了登入/路由頁面，允許使用者選擇進入其所選的區域。這只是一種選擇，每個解決方案都可以採取不同的方法，保證租戶登入到正確的區域。關鍵要點在於，租戶資料的實際註冊和收集均在區域本地完成。

在這種更為分散式的模型中，部署模型的複雜程度確實會有所提高，同時也會喪失管理和部署集中化體驗的能力。不過，如果您正部署到具有 GDPR 或一般資料主權要求的區域，這通常是您唯一的選擇。

多區域身份

成功註冊租戶之後，您仍然需要確定多區域環境將如何支援身份驗證。雖然為所有使用者提供集中化模型身份提供商是不錯的選擇，但這些資料的集中化並不符合監管個人資訊管理的任何基本資料主權要求。

鑑於這一點，您的身份識別方法應該專注於租戶體驗，並引入一種機制，以便有效地將您的身份管理路由到每個區域。就許多方面來說，此處所述的挑戰都與上面的註冊討論重疊。但現在，您必須具備一種非侵入式模型，以將使用者路由到以區域為中心的身份驗證體驗。

理想情況下，您希望這能給您的租戶帶來相對無縫的體驗，保證到給定區域的路由大多是透明的。解決此問題的一種常見方法是在您的應用程式的 URL 中嵌入租戶上下文。 圖 3 提供了這種方法的實際應用示例。

圖 3 – 使用 URL 路由租戶身份驗證。

採用這種模型時，系統會為每個租戶分配一個唯一 URL，並在註冊體驗中預置此唯一 URL。在本例中，我們建立了子域，在應用程式 URL 之前加上了租戶範圍。此子域使用傳統 DNS 路由（顯示為圖 3 中的 Amazon Route 53）將各租戶指引到相應的區域。

路由到相應的區域之後，您的 SaaS 解決方案就會依靠區域託管的身份提供商來對系統使用者進行管理和身份驗證。在本例中，我們將 Amazon Cognito 顯示為各區域的身份提供商。

雖然這種模型在租戶預置流程中添加了配置元素和更多活動部分，但也為終端使用者提供了更加直觀的體驗。另請務必注意，子域名前面的租戶識別符號不應直接對映到實際租戶識別符號的任何內部表示。反之，這應表現為一個唯一的子域，僅用於將使用者路由到其所在區域。

在某些情況下，您的應用程式可能需要依靠租戶選擇目標區域或環境，然後才能進行身份驗證。在使用者可以選擇在多個區域中擁有賬戶的情況下，會顯示這樣的選項。在此類情況下，可能不可避免地需要將該區域作為身份驗證體驗的一部分加以顯示。

對於某些解決方案，如果使用者想要將其現有身份從一個區域遷移到另一個區域，可能需要支援身份轉移。此時也可能需要使用者管理系統中的其他工作流程來啟用這種性質的傳輸。還可能會造成違反合規性法規的風險。

管理和監控

即使將客戶環境分配到各個區域，您也仍然更希望擁有管理和監控租戶整體執行狀況的集中化模型。事實上，隨著您轉向更為分散的多區域模式，對穩健的操作工具的需求將變得更加明顯。關鍵是要制定一種能有效擴充套件業務覆蓋範圍的機制，使您能夠通過集中化體驗來觀察 SaaS 環境的區域和全球執行狀況。

可以採取多種不同的方法來集中聚合來自各區域的資料。您選擇的模型取決於最適合應用程式的堆疊和工具。例如，某些解決方案可以在本地捕獲資料，然後將資料複製到不同區域。其他解決方案可能會將日誌資料直接傳輸到某個集中式儲存庫。

幸運的是，APN 合作伙伴社群提供了管理監控領域的多種不同解決方案，可以幫您簡化多區域監控。豐富的合作伙伴解決方案集合中包括 Sumologic、New Relic、Datadog 和 Dynatrace 等，可供您考慮選擇。這些產品中的每一款都採用自己的模型來捕獲和分析多區域環境。

AWS 還具有聯網結構，可用於構建管理環境。例如，某些組織利用跨區域 VPC 對等連線來管理分散式環境。這可以加強整個管理範圍內的安全性，並可能簡化自動化和部署體驗。您或許已經想到了，您需要將 GDPR 納入健康策略考慮範圍。在某些情況下，您可能需要確保所記錄的資料已經過完全篩查，符合 GDPR 法規中列出的要求。

部署自動化

敏捷性是促使採用 SaaS 交付模型的原因。但是，隨著您轉向多區域模型，這可能會增加環境的複雜性，對敏捷性目標造成不利影響。例如，當您開始考慮與在多個區域釋出產品相關的自動化和 DevOps 管道影響時，部署將成為一個需要更多方參與的流程。

在多區域模型中保持敏捷性的關鍵在於限制每次部署引入的變化量。這實際上只是 DevOps 核心原則的延伸，額外強調了打造可通過程式碼管理配置所有方面的自動化、重複性部署流程。

圖 4 提供了多區域管道的概念檢視。我們的目標是將每次區域部署視為原本可能在單個區域中託管的環境的克隆。隨著您轉向多區域模型，管道必須在服務需要針對具體區域做出最小更改的情況下，將各項更改（在本例中為各微服務）部署到目標區域。最終，您對所有區域的覆蓋越廣泛，就越有可能釋出新功能，而不會感到多區域模型妨礙您的敏捷性。

圖 4 – 多區域部署身份驗證。

儘管我們的目標是儘量減少變化，但某些區域的具體要求也可能會為您的管道新增新元素。例如，在各個區域中，很多情況下都需要向管道新增負責執行合規性驗證的下游步驟。根據可能引入區域配置和部署變化的 AWS 服務的變化，可能存在一定的細微差別，但目標仍然是將其視為整體管道的擴充套件。

計費

與管理和監控類似，計費功能也是一項應該使用集中化模型實施的服務。您的最終目標是希望擁有一種管理 SaaS 客戶賬戶、政策和計費活動的體驗。具體思路是，應將各區域中生成 SaaS 賬單所需的計量和活動資料釋出到一個集中化系統，負責聚合資訊並生成賬單。相同的系統也會負責向各個區域推送客戶狀態、策略和配置的最新狀態。

當然，雖然這是理想狀態，但合規性和法規也會增加其複雜性。在面臨主權或 GDPR 要求的情況下，您需要構建一種更為分散化的計費模型，防止客戶資訊離開某個區域。因此，儘管計費機制在所有區域都是相同的，但您仍然需要讓各區域生成賬單。這顯然會給計費流程增加複雜並導致效率低下，但這種問題可能無法避免。

多區域或多可用區

對於面臨區域化延遲和合規性障礙的 SaaS 組織而言，轉向多區域模型往往是一種自然而然的發展趨勢。但是，當純粹將多區域作為故障轉移策略加以採用時，討論會變得更加複雜。在某些情況下，您可能會發現多可用區方法將滿足解決方案的故障轉移需求，而不需要承受多區域模型的額外開銷。

最終，這要歸結於牢牢掌握推動您採用多區域模型的因素。審視可用選項時，您應該權衡這些選擇對解決方案的整體複雜性和敏捷性的影響。

實施遷移

遷移到多區域模型絕非易事。從上面介紹的各項內容中可以看到，在考慮如何在多區域環境中交付 SaaS 解決方案時，需要考慮許多因素。註冊、身份、操作 – 所有這些領域都需要特定的架構策略，以滿足多區域模型的要求。在著手實施轉型時，您必須始終專注於為客戶打造無縫體驗。

多區域環境也有可能影響組織的敏捷性。您的多區域方法必須要對自動化和管理解決方案的能力提出更高的要求，以確保您可以繼續快速推出新功能。

其他資源和後續步驟

關於 AWS SaaS Factory

AWS SaaS Factory 為 AWS 合作伙伴網路 (APN) 合作伙伴提供資源，幫助加速和指導其對於 SaaS 交付模型的採用。 SaaS Factory 包括用於在 AWS 上構建 SaaS 解決方案的參考架構；自動在 AWS 上部署關鍵工作負載的 Quick Start；以及在 AWS 上開展 SaaS 業務的獨家培訓機會。我們鼓勵開發 SaaS 解決方案的 APN 技術合作夥伴加入此計劃！

作者：Tod Golding，AWS 合作伙伴解決方案架構師