設計異地分散式資料架構
我們的應用程式架構設計最後要考慮的部分是資料儲存層。 我們想要確保資料在全區域失敗後可讀取及寫入，並具有完整的功能。
在出貨追蹤入口網站中，我們選擇使用 Azure Front Door 將所有要求傳送到位於美國東部地區的應用程式服務。 如果美國東部地區失敗，Front Door 會偵測到失敗，並將要求傳送到位於美國西部地區的應用程式服務元件複本。 在我們的原始單一區域架構中，我們將關聯式資料儲存在 Azure SQL Database 中，並將半結構化資料儲存在 Cosmos DB 中。 現在，我們想要了解如何確保這兩個資料庫在美國東部地區失敗時仍可供使用。
在這裡，我們將了解如何在區域之間複寫資料，以及如何確保容錯移轉會在必要時快速進行。
Azure SQL Database
若要建立 Azure SQL Database 的多區域實作來儲存關聯式資料，我們可以使用下列其中一項：
- 作用中異地複寫
- 自動容錯移轉群組
作用中異地複寫
Azure SQL Database 可以使用作用中異地複寫功能，自動將資料庫與其所有變更從某個資料庫複寫到另一個資料庫。 只有主要邏輯伺服器會裝載資料庫的可寫入複本。 我們最多可以建立四部其他邏輯伺服器，以裝載資料庫的唯讀複本。
針對出貨追蹤入口網站，請在美國西部地區建立次要資料庫，並設定從美國東部地區進行異地複寫。 發生地區失敗時，Front Door 會將使用者要求重新導向到位於美國西部地區的應用程式服務。 應用程式服務與 Azure Functions 可以存取關聯式資料，因為複本已複寫到美國西部地區。
此變更是自動的，但請記住，位於美國西部的次要資料庫是唯讀的。 如果使用者嘗試修改資料 (例如，透過建立新的出貨)，可能會發生錯誤。 我們可以在我們發現 Azure 入口網站的問題時，手動起始目標為美國西部的容錯移轉。 若我們想要將此程序自動化，我們的開發人員可以撰寫程式碼來呼叫 Azure SQL Database REST API 中的 failover 方法。
注意
Azure SQL Database 的受控執行個體不支援作用中異地複寫。 受控執行個體的設計可讓您輕鬆地從內部部署 SQL Server 移轉資料，同時維護安全性。 如果您使用的是受控執行個體，請考慮改為使用容錯移轉群組。
自動容錯移轉群組
自動容錯移轉群組是一組資料庫，其中資料會自動從主要伺服器複寫到一或多部次要伺服器。 此設計類似於作用中異地複寫，並使用相同的資料複寫方法。 不過，我們可以透過定義原則來自動回應失敗。
在貨運入口網站中，我們將在美國西部地區建立次要資料庫。 接著，我們會新增一個原則，在美國東部發生嚴重失敗時，將資料庫的主要複本容錯移轉到美國西部地區。 如果發生這種情況，美國西部複本會自動成為可寫入的主要資料庫，而且會維持完整功能。
如果您想要將可寫入資料庫的容錯移轉自動化，而不需要撰寫自訂程式碼來加以觸發，請考慮使用自動容錯移轉群組。 此外，如果您的資料庫在 Azure SQL Database 的受控執行個體中執行，請使用自動容錯移轉群組。
重要
作用中異地複寫與自動容錯移轉群組的複寫都是非同步的。 將變更套用至主要複本時，會將通知傳送給用戶端。 此時，交易會被視為已完成，而且會進行複寫。 如果發生失敗，在主要資料庫中所作的最新變更可能尚未複寫到次要資料庫。 請記住，在發生災害之後，最新的資料庫變更可能已遺失。
Azure Cosmos DB
我們的 Azure Cosmos DB 設定較不複雜，因為它是以多區域雲端資料庫系統來設計。 Cosmos DB 是多模型資料庫，能夠儲存關聯式資料、半結構化資料與其他形式的資料。 即使我們在單一區域中執行 Cosmos DB，資料仍會複寫到不同容錯網域的多個執行個體，以獲得最佳可用性。
當我們建立多區域的 Cosmos DB 帳戶時，可以從下列模式中選擇：
具有多寫入區域的多區域帳戶。
在此模式中，資料庫的所有複本隨時都可寫入。 如果區域失敗，不會進行容錯移轉。
具有單一寫入區域的多區域帳戶。
在此模式中，只有主要區域包含可寫入的資料庫。 複寫到次要地區的資料是唯讀的。 當主要區域失敗時，預設會停用更新。 不過，我們可以選取 [啟用自動容錯移轉]，讓 Cosmos DB 自動將主要、可寫入的資料庫複本容錯移轉到另一個區域。
重要
在 Cosmos DB 中，資料複寫是同步的。 套用變更時，除非交易複寫到複本的仲裁，否則不會被視為完成。 然後，通知會傳送給用戶端。 當發生失敗時，由於複寫已發生，因此不會遺失最近的變更。