本指南說明決定何時跨可用區域或區域部署工作負載的建議。
當您設計 Azure 的解決方案時，您必須決定要跨區域中的多個可用性區域部署，還是部署至多個區域。 此決策會影響解決方案的可靠性、成本和效能，以及小組操作解決方案的能力。 本指南提供影響您決策之關鍵商務需求、您可以考慮的方法、每個方法所涉及的取捨，以及每個方法對 Azure Well-Architected Framework 核心支柱的影響的相關資訊。
您用於解決方案的 Azure 區域是重要的選擇。 選取 Azure 區域指南說明如何在多個地理區域中選取和操作。 您在解決方案中使用區域和可用性區域的方式也會影響 Well-Architected Framework 的數個支柱：
可靠性： 您的部署方法可協助您降低各種類型的風險。 一般而言，透過將工作負載分散到地理上更分散的區域，您可以達到更高的復原能力。
成本優化： 某些架構方法需要您部署比其他方法更多的資源，這可能會增加您的資源成本。 其他方法涉及跨地理位置分開的可用區域或區域傳送資料，這可能會產生網路流量費用。 考慮管理資源的持續成本也很重要，當您有全面的業務需求時，成本通常會更高。
性能效率： 可用性區域會透過高頻寬、低延遲的網路連結連線在一起。 此連結足以讓大部分工作負載啟用跨區域的同步複寫和通訊。 不過，如果您測試工作負載，並判斷它對跨區域的網路延遲很敏感，您可能需要考慮將工作負載的元件實體定位得很近，以將它們通訊時的延遲降到最低。
卓越營運： 複雜的架構需要更多努力來部署、設定和管理。 針對高可用性解決方案，您可能也需要規劃如何容錯移轉至次要資源集。 容錯移轉、容錯回復和透明地重新導向流量可能很複雜，尤其是在需要手動步驟時。 自動化部署和管理程序是很好的做法。 如需詳細資訊，請參閱卓越營運支柱指南，包括 OE：05 基礎結構即程式碼、 OE：09 工作自動化、 OE：10 自動化設計和 OE：11 部署做法。
無論您如何設計解決方案，安全性支柱都會適用。 通常，決定是否以及如何使用可用區域和區域不會改變您的安全狀態。 Azure 會將相同的安全性嚴格性套用至每個區域和可用性區域。
小提示
對於許多生產工作負載， 區域備援部署 可提供最佳的取捨平衡。 您可以使用 非同步資料備份將此方法延伸至另一個區域。 如果您不確定要選取哪種方法，請從這種類型的部署開始。
當您需要其他工作負載方法提供的特定優點時，請考慮這些方法，但請注意取捨。
定義
| 術語 | Definition |
|---|---|
| Active-active | 解決方案的多個執行個體同時主動處理要求的架構。 |
| Active-passive | 一種架構，其中解決方案的一個執行個體被指定為 主要 執行個體並處理流量，並在主要執行個體無法使用時部署一或多個 次要 執行個體來提供流量。 |
| 非同步複寫 | 一種資料複寫方法，其中資料會寫入並認可至一個位置。 稍後，變更會複製到另一個位置。 |
| 可用性區域 | 區域內的分隔資料中心群組。 每個可用區域都獨立於其他可用區域，並擁有自己的電源、冷卻和網路基礎設施。 許多區域都支援可用性區域。 |
| 資料中心 | 包含伺服器、網路設備和其他硬體以支援 Azure 資源和工作負載的設施。 |
| 本機備援部署 | 一種部署模型，其中資源部署到單一區域，而不參考可用區域。 在支援可用性區域的區域中，資源可能會部署在區域的任何可用性區域中。 |
| 多地區部署 | 將資源部署至多個 Azure 區域的部署模型。 |
| 配對的區域 | 兩個 Azure 區域之間的關聯性。 某些 Azure 區域 會連線到另一個已定義的區域，以啟用特定類型的多區域解決方案。 較新的 Azure 區域不會配對。 |
| 區域 | 包含一組資料中心的地理周界。 |
| 區域架構 | Azure 區域的特定設定，包括可用性區域數目，以及區域是否與其他區域配對。 |
| 同步複寫 | 一種資料複寫方法，其中將資料寫入並認可至多個位置。 每個位置都必須先確認寫入作業的完成，才能將整體寫入作業視為完成。 |
| 區域 （釘選） 部署 | 將資源部署到特定可用區域的部署模型。 |
| 區域備援部署 | 一種部署模型，其中資源跨多個可用區域部署。 Microsoft 會管理資料同步處理、流量散發，以及區域發生中斷時容錯移轉。 |
瞭解區域和可用性區域在 Azure 中的組織方式
Azure 在全球有許多資料中心。 Azure 區域 是包含一組資料中心的地理周邊。 您必須完整瞭解 Azure 區域和可用性區域。
Azure 區域有各種設定，也稱為 區域架構。
許多 Azure 區域都提供 可用性區域，這些區域是個別的資料中心群組。 在區域內，可用區域足夠近，可以與其他可用區域進行低延遲連線，但相距足夠遠，以降低多個區域受到本機中斷或天氣影響的可能性。 可用區域具有獨立的電源、冷卻和網路基礎設施。 它們的設計目的是，如果一個區域發生中斷，其餘區域可以繼續支援區域服務、容量和高可用性。
下圖會顯示數個範例 Azure 區域。 區域 1 和 2 支援可用性區域。
如果您部署至 包含可用性區域的 Azure 區域，您可以同時使用多個可用性區域。 透過使用多個可用性區域，您可以在大都會區域的個別實體資料中心內保留應用程式和資料的個別複本。
在解決方案中使用可用性區域有兩種方式：
區域資源 會釘選至特定可用性區域。 您可以結合不同區域的多個區域部署，以符合高可靠性需求。 您負責管理資料複寫，並跨區域散發要求。 如果單一可用區域發生中斷，您必須負責容錯移轉至另一個可用區域。
區域備援資源 會分散在多個可用性區域中。 Microsoft 會管理要求的散發，以及跨區域的資料複寫。 如果單一可用性區域發生中斷，Microsoft 會自動管理容錯移轉。
Azure 服務支援其中一種或兩種方法。 平臺即服務 （PaaS） 解決方案通常支援區域備援部署。 基礎結構即服務 （IaaS） 解決方案通常支援區域部署。 如需 Azure 服務如何與可用性區域搭配使用的詳細資訊，請參閱 具有可用性區域支援的 Azure 服務。
Microsoft 會嘗試在服務更新部署期間使用中斷最少的方法。 例如，Microsoft 的目標是一次將更新部署到單個可用性區域。 此方法可以減少更新可能對作用中工作負載產生的影響，因為工作負載可以在進行更新時繼續在其他區域中執行。 不過，工作負載小組最終有責任確保其工作負載在平台升級期間繼續運作。 例如，當您將 虛擬機器擴展集搭配彈性協調流程模式或大部分的 Azure PaaS 服務使用時，Azure 會智慧地放置您的資源，以減少平臺更新的影響。 請考慮 過度佈建，即部署更多資源執行個體，以便在升級其他執行個體時，某些執行個體仍可用。 如需 Azure 如何部署更新的詳細資訊，請參閱 進階安全部署做法。
許多區域也有 成對區域。 配對區域支援特定類型的多區域部署方法。 某些較新的區域有 多個可用性區域，而且沒有配對的區域。 您仍然可以將多區域解決方案部署到這些區域，但您使用的方法可能會有所不同。
如需 Azure 如何使用區域和可用性區域的詳細資訊，請參閱 Azure 區域和可用性區域。
了解共同責任
共同責任原則說明雲端提供者和您之間的責任如何劃分。 根據您使用的服務類型，您可能會承擔或多或少的操作服務責任。
Microsoft 提供可用性區域和區域，讓您有彈性地設計解決方案，以符合您的需求。 當您使用受控服務時，Microsoft 會承擔更多資源的管理責任。 這些責任可能包括資料複寫、容錯移轉、容錯回復，以及與操作分散式系統相關的其他工作。
您自己的程式碼需要遵循 建議的做法和設計模式，以正常處理失敗。 這些做法在容錯移轉操作期間特別重要，例如在發生可用區域或區域容錯移轉時發生的操作，因為區域或區域之間的容錯移轉通常需要您的應用程式重試與服務的連線。
識別關鍵業務和工作負載需求
若要就如何在解決方案中使用可用性區域和區域做出明智的決策，您必須瞭解您的需求。 解決方案設計人員與商務利害關係人之間的討論應該會推動這些需求。
風險承受能力
不同的組織有不同程度的風險承受能力。 即使在單一組織內，風險承受能力通常也會因工作負載而異。 大部分的工作負載不需要極高的可用性。 然而，某些工作負載非常重要，即使是不太可能的風險也值得減輕，例如影響廣泛地理區域的重大自然災害。
下表列出您在雲端環境中應考慮的一些常見風險。
| 風險 | 範例 | 可能性 |
|---|---|---|
| 硬體中斷 | - 硬碟或網路設備問題 - 主機重新開機 |
高。 任何彈性策略都應考慮這些風險。 |
| 資料中心中斷 | - 整個數據中心的電源、冷卻或網絡故障 - 大都市區某部分發生自然災害 |
中等 |
| 區域中斷 | - 影響廣泛地理區域的重大自然災害 - 網路或服務問題，導致一或多個 Azure 服務在整個區域中無法使用 |
Low |
這是降低每個工作負載的所有可能風險的理想選擇。 然而，這種方法不實用或不具有成本效益。 與業務利害關係人進行公開討論非常重要，這樣您就可以就應減輕的風險做出明智的決策。
小提示
無論可靠性目標為何，所有工作負載都必須有一些災害復原 （DR） 風險降低措施。 如果您的工作負載需要高可靠性目標，則您的緩解策略應該是全面的，而且您應該降低低可能性事件的風險。 對於其他工作負載，請就哪些風險是可接受的，哪些風險需要緩解做出明智的決定。
可靠性要求
請務必瞭解工作負載的可靠性需求，例如同意復原目標，例如復原時間目標 （RTO） 和復原點目標 （RPO）。 可靠性需求可協助您決定要排除哪些方法。如果您沒有明確的要求，您就無法就遵循哪種方法做出明智的決定。 如需詳細資訊，請參閱 識別和評等流程的架構策略。
服務等級目標
您應該瞭解解決方案的預期正常運行時間服務等級目標 （SLO）。 例如，您可能有業務需求，您的解決方案需要滿足 99.9% 的運作時間。
Azure 為每項服務提供服務等級協定 （SLA）。 SLA 會指出您應該從服務預期的運作時間層級，以及達到預期 SLA 所需滿足的條件。 不過，請記住，Azure SLA 定義服務可用性的方式可能不一定符合您評估工作負載健康情況的方式。
您的架構決策會影響解決方案的 複合 SLO。 一般而言，您在解決方案中建置的備援越多，您的 SLO 可能就越高。 當您在區域備援或多區域設定中部署服務時，許多 Azure 服務都會提供較高的 SLA。 檢閱您使用的每個 Azure 服務的 SLA，以確保您瞭解如何將服務的復原能力和 SLA 最大化。
資料存放位置
一些組織對可以儲存和處理其資料的實體位置施加了限制。 有時這些要求是基於法律或監管標準。 在其他案例中，組織可能會決定採用資料落地原則，以避免客戶的擔憂。 如果您有嚴格的資料落地需求，您可能需要使用單一區域部署，或使用 Azure 區域和服務的子集。
備註
避免對資料駐留需求做出毫無根據的假設。 如果您需要遵守特定的法規標準，請驗證這些標準實際指定的內容。
使用者位置
透過了解使用者所在的位置，您可以就如何根據您的需求優化延遲和可靠性做出明智的決定。 Azure 提供許多選項來支援地理位置分散的使用者群。
如果您的使用者集中在一個區域，單一區域部署可以簡化您的營運需求並降低成本。 不過，您需要考慮單一區域部署是否符合您的可靠性需求。 對於關鍵任務應用程式，即使您的使用者位於共置，您仍應該使用多區域部署。
如果您的使用者在地理位置上分散，則跨多個區域部署工作負載可能是有意義的。 Azure 服務提供不同的功能來支援多區域部署，而且您可以使用全域 Azure 使用量來改善使用者體驗，並讓應用程式更接近使用者群。 您可以使用 部署戳記模式 或 Geodes 模式，或跨多個區域複寫資源。
即使您的使用者位於不同的地理區域，也請考慮您是否需要多區域部署。 請考慮您是否可以使用全域流量加速，例如 Azure Front Door 提供的加速，在單一區域內達成您的需求。
預算
如果您在預算有限的情況下運作，請務必考慮部署備援工作負載元件所涉及的成本。 這些成本可能包括額外的資源費用、網路成本，以及管理更多資源和更複雜環境的營運成本。
複雜性
避免解決方案架構中不必要的複雜性是很好的做法。 您引入的複雜性越高，就越難做出有關架構的決策。 複雜的架構更難操作、更難保護，而且效能通常較差。 確保您遵循 簡單原則。
範例案例
藉由提供區域和可用性區域，Azure 可讓您選取符合您需求的部署方法。 每種方法都提供特定的好處並產生相關成本。
為了說明您可以使用的部署方法，請考慮範例案例。 假設您想要部署新的解決方案，其中包含將資料寫入某種儲存體的應用程式。
此範例並非特定於任何特定的 Azure 服務。 它旨在提供一個說明基本概念的範例。
有多種方式可以部署此解決方案。 每種方法都提供不同的好處並產生不同的成本。 在高層級上，您可以考慮本機備援、區域 （釘選）、區域備援或多區域部署。 下表摘要說明一些支柱問題。
| 要素 | 本地冗餘 | 區域 （釘選） | Zone-redundant | 多區域 |
|---|---|---|---|---|
| Reliability | 可靠性低 | 取決於方法 | 高或非常高的可靠性 | 高或非常高的可靠性 |
| 成本優化 | 低成本 | 取決於方法 | 成本適中 | 成本高 |
| 效能效率 | 可接受的效能 （適用於大部分工作負載） | 高效能 | 可接受的效能 （適用於大部分工作負載） | 取決於方法 |
| 卓越營運 | 操作要求低 | 高操作要求 | 操作要求低 | 高操作要求 |
下表摘要說明您可以使用的一些方法，以及它們如何影響您的架構。
| 架構問題 | 本地冗餘 | 區域 （釘選） | Zone-redundant | 多區域 |
|---|---|---|---|---|
| 符合資料落地 | High | High | High | 取決於地區 |
| 區域可用性 | 所有地區 | 具有可用性區域的區域 | 具有可用性區域的區域 | 取決於地區 |
本文的其餘部分說明上表中列出的每個方法。 方法清單並不詳盡。 您可能會決定結合多種方法，或在解決方案的不同部分使用不同的方法。
部署方法 1：本機備援部署
如果您在部署資源時未指定多個可用性區域或區域，Azure 不會保證資源是部署到單一資料中心，還是分割到區域中的多個資料中心。 在某些情況下，Azure 也可能會在可用性區域之間移動您的資源。
根據預設，大部分的 Azure 資源都是高可用性，在平台管理的資料中心內具有高 SLA 和內建備援。 不過，從可靠性的角度來看，如果區域的任何部分發生中斷，您的工作負載可能會受到影響。 如果是，您的解決方案可能無法使用，或者您的資料可能會遺失。
對於高度延遲敏感的工作負載，此方法也可能導致效能降低。 您的工作負載元件可能不會共置在相同的資料中心，因此您可能會觀察到區域內流量的一些延遲。 Azure 也可能會在可用性區域之間透明地移動您的服務執行個體，這可能會稍微影響效能。 不過，大部分工作負載不會擔心效能下降。
下表摘要說明一些支柱問題。
| 要素 | Impact |
|---|---|
| Reliability | 可靠性低。 如果資料中心發生故障，服務可能會中斷。 不過，您可以建置應用程式，以復原其他類型的失敗。 |
| 成本優化 | 成本最低。 您只需要擁有每個資源的單一執行個體，而且不會產生任何區域間頻寬成本。 |
| 效能效率 |
-
對於大部分的工作負載：可接受的效能。 這種方法可能會提供令人滿意的效能。 - 對於高度延遲敏感的工作負載：效能低。 元件可能位於不同的可用區域中，因此高度延遲敏感的元件可能會遇到較低的效能。 |
| 卓越營運 | 運營效率高。 您只需要部署和管理每個資源的單一執行個體。 |
下表從架構觀點摘要說明一些考量。
| 架構問題 | Impact |
|---|---|
| 符合資料落地 | 高。 當您部署使用此方法的解決方案時，資料會儲存在您選取的 Azure 區域中。 |
| 區域可用性 | 高。 此方法可用於任何 Azure 區域。 |
具有跨區域備份的本機備援部署
您可以定期將基礎結構和資料備份至次要區域，以擴充本機備援部署。 此方法會新增額外的保護層，以減輕主要區域的中斷。
當您實作此方法時，您必須仔細考慮 RTO 和 RPO。
恢復時間： 如果發生區域中斷，您可能需要在另一個 Azure 區域中重建解決方案，這會影響您的復原時間。 請考慮使用基礎結構即程式碼 （IaC） 方法來建置解決方案，以便在發生重大災害時，您可以快速重新部署到另一個區域。 請確定您的部署工具和程式與應用程式一樣具有復原能力，以便即使發生中斷，您也可以使用它們來重新部署解決方案。 規劃並排練將解決方案還原回工作狀態所需的步驟。
恢復點： 您的備份頻率決定了您可能遇到的資料遺失量，這稱為 復原點。 您通常可以控制備份的頻率，以便滿足 RPO。
下表摘要說明一些支柱問題。
| 要素 | Impact |
|---|---|
| Reliability | 可靠性適中。 如果資料中心發生故障，服務可能會中斷。 資料會以非同步方式備份至地理上分隔的區域，藉由將資料遺失降到最低，以減少完整區域中斷的影響。 在完整區域中斷中，您可以手動將作業還原至另一個區域。 不過，復原程式可能很複雜，而且手動還原至其他區域可能需要一些時間。 |
| 成本優化 | 低成本。 一般而言，將備份新增至另一個區域的成本僅比部署本機備援資源稍高。 |
| 效能效率 |
-
對於大部分的工作負載：可接受的效能。 這種方法可能會提供令人滿意的效能。 - 對於高度延遲敏感的工作負載：效能低。 元件可能位於不同的可用區域中，因此高度延遲敏感的元件可能會遇到較低的效能。 |
| 卓越營運 | 在區域內發生任何中斷期間：營運效率低。容錯移轉是您的責任，可能需要手動作業和重新部署。 |
下表從架構觀點摘要說明一些考量。
| 架構問題 | Impact |
|---|---|
| 符合資料落地 | 取決於地區選擇。 資料主要儲存在您指定的 Azure 區域中。 不過，您必須選取另一個區域來儲存備份，因此請務必選取符合資料駐留需求的區域。 |
| 區域可用性 | 高。 您可以在任何 Azure 區域使用此方法。 |
部署方法 2：區域 （釘選） 部署
在 區域部署 中，您可以指定應將資源部署至特定可用性區域。 此方法有時稱為 區域釘選 部署。
區域方法可減少元件之間的延遲。 不過，就其本身而言，它不會增加解決方案的復原能力。 若要提高彈性，您需要將元件的多個執行個體部署到多個可用區域，並決定如何在每個執行個體之間路由流量。 此示例顯示主動 -被動 流量路由方法。
在上一個範例中，負載平衡器會部署在多個可用區域中。 請務必考慮如何在不同可用區域中的執行個體之間路由流量，因為區域中斷也可能影響部署到該區域的網路資源。 您也可以考慮使用全域負載平衡器，例如 Azure Front Door 或 Azure 流量管理員，這些工具根本不會部署到區域中。
當您使用區域部署模型時，您會承擔許多責任：
您需要將資源部署到每個可用區域，並個別設定和管理這些資源。
您需要決定如何在可用性區域之間複寫資料，然後設定和管理複寫。
您負責將請求分發到正確的資源，例如使用負載平衡器。 您必須確保負載平衡器符合您的復原需求。 您也需要決定是否使用主動-被動或主動-主動要求配送模型。
如果可用區域發生中斷，您需要處理容錯移轉，以將流量傳送至另一個可用區域中的資源。
跨多個可用區域的主動-被動部署有時稱為區域內 DR 或城域 DR。
下表摘要說明一些支柱問題。
| 要素 | Impact |
|---|---|
| Reliability |
-
部署在單一可用區域中時：可靠性低。 區域部署不會為資料中心或可用性區域中的中斷提供任何復原能力。 您必須跨多個可用性區域部署備援資源，才能達到高彈性。 - 部署在多個可用區時：高可靠性。服務可以針對資料中心或可用性區域中斷進行復原。 |
| 成本優化 |
- 部署在單一可用區域中時：成本低。單一區域部署只需要每個資源的單一執行個體。 - 部署在多個可用區域中時：成本高。您可以部署資源的多個執行個體，每個執行個體都會個別計費。 |
| 效能效率 | 高性能。 當提供請求的元件位於相同的可用區域時，延遲可能非常低。 |
| 卓越營運 | 運營效率低。 您需要設定和管理服務的多個執行個體。 您需要在可用性區域之間複寫資料。 在可用區域中斷期間，容錯移轉是您的責任。 |
下表從架構觀點摘要說明一些考量。
| 架構問題 | Impact |
|---|---|
| 符合資料落地 | 高。 當您部署使用此方法的解決方案時，資料會儲存在您選取的 Azure 區域中。 |
| 區域可用性 | 具有可用性區域的區域。 此方法適用於任何支援 可用性區域的區域。 |
此方法通常用於以虛擬機器 （VM） 為基礎的工作負載。 如需支援區域部署之服務的完整清單，請參閱 可用性區域服務和區域支援。
當您規劃區域部署時，請確認您計劃使用的可用性區域支援您使用的 Azure 服務。 若要列出每個可用性區域中可用的 VM SKU，請參閱 檢查 VM SKU 可用性。
小提示
當您將資源部署到特定可用性區域時，請選取區域編號。 每個 Azure 訂用帳戶的區域號碼順序都不同。 如果您跨多個 Azure 訂用帳戶部署資源，請確認您應該在每個訂用帳戶中使用的區域號碼。 如需詳細資訊，請參閱實體和邏輯可用性區域。
部署方法 3：區域備援部署
當您使用此方法時，您的應用程式層會分散在多個可用區域中。 當請求到達時，服務內建的負載平衡器會將請求分散到每個可用區域的執行個體之間。 服務本身跨越可用性區域。 如果可用區域發生中斷，負載平衡器會將流量導向至運作狀態良好的可用區域中的執行個體。
您的儲存層也會分散在多個可用性區域中。 應用程式資料的複本會透過 同步複寫分散在多個可用性區域中。 當應用程式對資料進行變更時，儲存體服務會將變更寫入多個可用性區域。 只有在所有這些變更都完成時，交易才會被視為完成。 此程序可確保每個可用區域一律都有資料的 up-to日期複本。 如果可用區域發生中斷，可以使用另一個可用區域來存取相同的資料。
區域備援方法可增加解決方案對資料中心中斷等問題的復原能力。 不過，由於資料是同步複寫，因此您的應用程式必須等待資料寫入跨多個可能位於大都市區域不同部分的個別位置。 對於大多數應用程序，區域間通信的延遲可以忽略不計。 不過，對於某些高度延遲敏感的工作負載，跨可用性區域的同步複寫可能會影響應用程式的效能。
下表摘要說明一些支柱問題。
| 要素 | Impact |
|---|---|
| Reliability | 高可靠性。 服務可復原資料中心或可用性區域中斷。 資料會跨可用區域同步複寫，不會延遲。 |
| 成本優化 | 成本適中。 視您使用的服務而定，您可能需要較高服務層級的一些成本，以啟用區域備援。 |
| 效能效率 |
-
對於大部分的工作負載：可接受的效能。 這種方法可能會提供令人滿意的效能。 - 對於高度延遲敏感的工作負載：效能低。 某些元件可能因為區域間流量或資料複寫時間而對延遲敏感。 |
| 卓越營運 | 運營效率高。 您通常只需要管理每個資源的單一邏輯實例。 對於大部分的服務，在可用性區域中斷期間，容錯移轉是 Microsoft 的責任，而且會自動發生。 |
下表從架構觀點摘要說明一些考量。
| 架構問題 | Impact |
|---|---|
| 符合資料落地 | 高。 當您部署使用此方法的解決方案時，資料會儲存在您選取的 Azure 區域中。 |
| 區域可用性 | 具有可用性區域的區域。 此方法適用於任何支援 可用性區域的區域。 |
許多 Azure 服務都可以使用此方法，包括 Azure 虛擬機器擴展集、Azure App Service、Azure Functions、Azure Kubernetes Service （AKS）、Azure 儲存體、Azure SQL、Azure 服務匯流排和許多其他服務。 如需支援區域備援之服務的完整清單，請參閱 可用性區域服務和區域支援。
具有跨區域備份的區域備援部署
您可以定期將基礎結構和資料備份至次要區域，以擴充區域備援部署。 此方法可讓您享有區域備援方法的優點，並新增一層保護，以減輕極不可能發生的完整區域中斷事件。
當您實作此方法時，您必須仔細考慮 RTO 和 RPO。
恢復時間： 如果確實發生區域中斷，您可能需要在另一個 Azure 區域中重建解決方案，這會影響復原時間。 請考慮使用 IaC 方法建置解決方案，以便在重大災害期間快速重新部署至另一個區域。 請確定您的部署工具和程序與應用程式一樣具有復原能力，以便即使發生中斷，您也可以使用它們來重新部署解決方案。 規劃並排練將解決方案還原回工作狀態所需的步驟。
恢復點： 您的備份頻率決定了您可能遇到的資料遺失量，稱為 復原點。 您通常可以控制備份頻率以符合 RPO。
小提示
這種方法通常為所有架構問題提供了良好的平衡。 如果您不確定要使用哪種方法，請從這種類型的部署開始。
下表摘要說明一些支柱問題。
| 要素 | Impact |
|---|---|
| Reliability | 非常高的可靠性。 服務可復原資料中心或可用性區域中斷。 對於大多數服務，資料會自動跨區域複寫，而不會延遲。 資料會以非同步方式備份至地理上分隔的區域。 此備份可將資料遺失降到最低，以減少完整區域中斷的影響。 在完整區域中斷之後，您可以手動將作業還原至另一個區域。 不過，復原程式可能很複雜，而且手動還原至其他區域可能需要一些時間。 |
| 成本優化 | 成本適中。 通常，將備份新增至另一個區域的成本僅比實作區域備援稍高。 |
| 效能效率 |
-
對於大部分的工作負載：可接受的效能。 這種方法可能會提供令人滿意的效能。 - 對於高度延遲敏感的工作負載：效能低。 某些元件可能因為區域間流量或資料複寫時間而對延遲敏感。 |
| 卓越營運 |
-
在可用性區域中斷期間：高營運效率。 容錯移轉是 Microsoft 的責任，而且會自動發生。 - 區域性中斷期間：營運效率低。 容錯移轉是您的責任，可能需要手動作業和重新部署。 |
下表從架構觀點摘要說明一些考量。
| 架構問題 | Impact |
|---|---|
| 符合資料落地 | 取決於地區選擇。 資料主要儲存在您指定的 Azure 區域中，但您必須選取另一個區域來儲存備份。 選取與您的資料落地需求相容的區域。 |
| 區域可用性 | 具有可用性區域的區域。 此方法適用於任何支援 可用性區域的區域。 |
部署方法4：多區域部署
您可以同時使用多個 Azure 區域，將解決方案散發到廣泛的地理區域。 您可以使用此多區域方法來改善解決方案的可靠性，或支援地理位置分散的使用者。 透過部署到多個區域，您也可以降低在單一區域中遇到暫時資源容量限制的風險。 如果資料落地是您解決方案的重要考慮因素，請仔細考慮您使用哪些區域來確保資料僅儲存在符合您需求的位置。
主動和被動區域
多區域架構很複雜，設計多區域解決方案的方法有很多種。 對於某些工作負載，讓多個區域同時主動處理請求 （主動-主動部署） 是有意義的。 針對其他工作負載，最好指定一個 主要區域 ，並使用一或多個 次要區域 進行容錯移轉 （主動-被動部署）。 本節重點介紹第二種情況，其中一個區域是主動的，另一個區域是被動的。 如需主動-主動多區域解決方案的詳細資訊，請參閱 部署戳記模式 和 Geode 模式。
資料複寫
跨區域通訊比區域內通訊慢得多。 一般而言，兩個區域之間的地理距離越大，會產生更多的網路延遲，因為資料需要傳輸的實體距離較長。 如需在兩個區域之間連線時預期網路延遲的詳細資訊，請參閱 Azure 網路來回延遲統計資料。
跨區域網路延遲可能會嚴重影響您的解決方案設計，因為您需要仔細考慮額外的延遲如何影響資料複寫和其他交易。 對於許多解決方案，跨區域架構需要非 同步 複寫，以將跨區域流量對效能的影響降到最低。
非同步資料複寫
當您跨區域實作非同步複寫時，您的應用程式不會等待所有區域都確認變更。 在主要區域中認可變更之後，交易會被視為完成。 變更稍後會複寫至次要區域。 此方法可確保區域間連線延遲不會直接影響應用程式效能。 不過，由於複寫延遲，全區域中斷可能會導致部分資料遺失。 發生此資料遺失可能是因為區域在主要區域中完成寫入之後，但在將變更複寫至另一個區域之前，區域可能會發生中斷。
下表摘要說明一些支柱問題。
| 要素 | Impact |
|---|---|
| Reliability | 高可靠性。 此解決方案可復原資料中心、可用性區域或整個區域的中斷。 資料會複寫，但可能不是同步的，因此在容錯移轉案例中可能會遺失某些資料。 |
| 成本優化 | 成本高。 您需要在每個區域部署單獨的資源，每個資源都會產生部署和維護成本。 跨區域的資料複寫也可能會產生大量成本。 |
| 效能效率 | 高性能。 應用程式請求不需要跨區域流量，因此流量通常具有低延遲。 |
| 卓越營運 | 運營效率低。 您需要跨多個區域部署和管理資源。 您也負責區域中斷期間區域之間的容錯移轉。 |
下表從架構觀點摘要說明一些考量。
| 架構問題 | Impact |
|---|---|
| 符合資料落地 | 取決於地區選擇。 此方法需要您選取多個區域，讓工作負載在其中執行。 選擇與您的資料駐留需求相容的區域。 |
| 區域可用性 | 許多 Azure 區域 都會配對。 某些 Azure 服務會使用配對區域來自動複寫資料。 如果您在 沒有配對的區域中執行工作負載，則可能需要使用 不同的方法來複寫資料。 |
同步資料複寫
如果您實作同步多區域解決方案，您的應用程式必須等候每個 Azure 區域中的寫入作業完成，交易才會被視為完成。 等待寫入作業所產生的延遲取決於區域之間的距離。 對於許多工作負載，區域間延遲可能會使同步複寫太慢而無法使用。
下表摘要說明一些支柱問題。
| 要素 | Impact |
|---|---|
| Reliability | 非常高的可靠性。 此解決方案可復原資料中心、可用性區域或整個區域的中斷。 資料一律會跨區域同步。 因此，即使整個區域發生故障，您的資料仍然完整，並且可以在另一個區域中使用。 |
| 成本優化 | 成本高。 您需要在每個區域部署單獨的資源，每個資源都會產生部署和維護成本。 跨區域的資料複寫也可能會產生大量成本。 |
| 效能效率 | 性能低下。 應用程式請求需要跨區域流量。 視區域之間的距離而定，同步複寫可能會為要求增加顯著的延遲。 |
| 卓越營運 | 運營效率低。 您需要跨多個區域部署和管理資源。 您也負責區域中斷期間區域之間的容錯移轉。 |
下表從架構觀點摘要說明一些考量。
| 架構問題 | Impact |
|---|---|
| 符合資料落地 | 取決於地區選擇。 此方法需要您選取多個區域，讓工作負載在其中執行。 選取與您的資料落地需求相容的區域。 |
| 區域可用性 | 許多 Azure 區域 都會配對。 某些 Azure 服務會使用配對區域來自動複寫資料。 如果您在 沒有配對的區域中執行工作負載，則可能需要使用 不同的方法來複寫資料。 |
區域架構
當您設計多區域解決方案時，請考慮您計劃使用的 Azure 區域是否配對。
即使區域未配對，您也可以建立多區域解決方案。 不過，您用來實作多區域架構的方法可能會有所不同。 例如，在儲存體中，您可以使用異地備援儲存體 （GRS） 搭配配對區域。 如果 GRS 無法使用，請考慮使用儲存體 物件複寫等功能，或將應用程式設計為寫入多個區域。
結合多區域和多區域方法
如果您的業務需求需要這類解決方案，您應該結合多區域和多區域陳述式。 例如，您可以將區域備援元件部署到每個區域中，並在區域之間設定複寫。 對於某些解決方案，這種方法提供了非常高的可靠性。 不過，設定這種類型的方法可能會很複雜，而且這種方法可能會很昂貴。
這很重要
關鍵任務工作負載 應同時使用多個可用性區域 和 多個區域。
Azure 服務如何支援部署方法
請務必瞭解您所使用的 Azure 服務的特定詳細數據。 例如，某些 Azure 服務需要您在第一次部署資源時設定其可用性區域設定，而其他服務則支援稍後變更部署方法。 同樣地，某些服務功能可能並非適用於每個部署方法。
若要深入瞭解每個 Azure 服務要考慮的特定部署選項和方法，請流覽 可靠性中樞。
使用案例範例
本節說明一些常見使用案例，以及您通常需要針對每個工作負載考慮的關鍵需求。 針對每個工作負載，會根據本文所述的需求和方法，提供一或多個建議的部署方法。
企業的企業營運應用程式
Contoso， Ltd. 是一家大型製造公司。 該公司正在實施業務線 （LOB） 應用程序來管理其財務流程的某些組件。
業務需求： 系統管理的資訊很難替換，因此資料需要可靠地保存。 架構師需要系統盡可能減少停機時間和資料遺失。 Contoso 員工在整個工作日都會使用系統，因此高效能對於避免讓小組成員等待很重要。 成本也是一個問題，因為財務團隊必須為解決方案付費。
建議的方法：具有跨區域備份的區域備援部署可提供 高效能的多層復原能力。
內部應用
Fourth Coffee 是一家小型企業。 該公司正在開發一個新的內部應用程序，員工可以使用它來提交時間表。
業務需求： 對於此工作負載，成本效益是主要考慮因素。 Fourth Coffee 評估了停機對業務的影響，並決定應用程式不需要優先考慮彈性或效能。 公司接受 Azure 可用性區域或區域中斷可能導致應用程式暫時無法使用的風險。
建議的方法：
跨區域備份的本機備援部署成本最低，但也存在重大風險。
具有跨區域備份的區域備援部署可提供更好的復原能力，但成本略高。
舊版應用程式移轉
Fabrikam， Inc. 正在將舊版應用程式從內部部署資料中心移轉至 Azure。 他們計劃使用以 VM 為基礎的 IaaS 方法。 該應用程式不是為雲端環境設計的，應用程式層和資料庫之間的通訊非常 閒聊。
業務需求： 性能是此應用程序的首要任務。 復原能力也很重要，即使 Azure 資料中心發生中斷，應用程式也必須繼續運作。
建議的方法：
Fabrikam 應該先嘗試 區域備援部署。 他們應該驗證性能是否符合他們的要求。
如果區域備援解決方案的效能無法接受，他們應該考慮區域 性 （釘選） 部署，並跨多個可用性區域 （區域內 DR） 進行被動部署。
醫療保健應用
Lamna Healthcare Company 正在 Azure 上實作新的電子健康記錄系統。
業務需求： 由於此解決方案儲存的資料性質，資料落地至關重要。 Lamna 在嚴格的法規架構下運作，要求資料必須保留在特定位置。
建議的方法：
多區域多區域部署，如果有多個區域符合 Lamna 的數據落地需求。
如果只有單一區域符合其需求，他們應該考慮 區域備援部署 ，或具有 跨區域備份的區域備援部署 ，以提供單一區域解決方案。
銀行系統
Woodgrove Bank 會從部署至 Azure 的大型解決方案執行其核心銀行作業。
業務需求： 該系統是關鍵任務。 任何中斷都可能對客戶造成重大財務影響。 因此，伍德格羅夫銀行的風險承受能力非常低。 系統需要盡可能高的可靠性，而架構需要降低任何可以減輕的故障風險。
建議的方法： 對於關鍵任務系統，他們應該使用 多區域多區域部署 ，並確保這些區域符合公司的數據落地要求。
軟體即服務
Proseware， Inc. 構建供世界各地公司使用的軟件。 該公司的用戶群分佈廣泛。
業務需求： Proseware 需要讓每個客戶都能選擇接近客戶的部署區域。 啟用此選擇對於延遲和客戶的資料落地需求非常重要。
建議的方法：
具有全域流量加速解決方案的單一區域 區域備援部署 ，例如 Azure Front Door。
後續步驟
下列參考架構和範例案例適用於多區域和多區域解決方案：
使用下列 Azure 服務來跨多個可用性區域實作解決方案：