在上一個單元中，我們描述了計算擴展，並在此過程中提高了可用性。 我們也建議新增 Azure Managed Redis（Redis）以提升效能，並透過分片擴展 Azure SQL 資料庫。
隨著您的業務成長，下一步可能是走向全球。 不過，在嘗試實作完全全域架構之前，您需要考慮一些事項。
要思考的問題
第一個問題是： 你真的需要走向全球嗎？
請務必瞭解客戶在處理這類工作之前所受的痛苦，因此請問自己幾個問題：
- 您可以透過內容傳遞網路更接近用戶內容嗎？
- 您真的需要跨兩個（或更多）地理位置調整此特定系統嗎？ 例如，美國 的使用者是否需要擁有完全相同的英國帳號？ 獨立系統更適合嗎？ 這種模式在電子商務中很常見。
- 如果您真的需要全域分散式系統，您需要資料庫的一致性為何？ 要在全球各地保持高度一致性是相當困難的。 像 Cosmos DB 這類服務確實支援多區域配置中的強一致性，但這也帶來重大代價，包括更高的延遲、區域停機時可用性降低，以及每次操作的 RU 消耗增加。
資料一致性
讓我們更仔細地看看數據一致性的問題。
在分散式運算中，一致性 是指系統所有副本中的資料是否及時更新並保持一致。 主要有兩種一致性模型。
強式一致性 提供線性化的保證。 保證讀取一定會傳回項目的最新認可版本。
然後是 最終一致性，即資料庫或系統最終會隨著時間而變得一致的想法。 讀取沒有排序保證。 如果沒有任何進一步的寫入，則複本最終會趨於一致。
像 Cosmos DB 這類服務也提供中介一致性模型，如限制新舊度、會話和一致性前綴，這些模型在效能與資料新鮮度之間提供不同的平衡。
如果你發現真的需要將應用程式擴展到全球，有些 Azure 服務可以幫助你達成這個目標。 讓我們來看看 Azure 流量管理員 和 Azure Front Door：
- Azure 流量管理員 是一個全球基於 DNS 的負載平衡服務。 它會使用 DNS 和健康探測，根據您定義的路由原則，將使用者路由傳送到最佳後端伺服器。 這種路由可以根據效能、地點、輪流循環等來決定。 識別出狀況良好的後端之後，用戶端一律會直接連線到後端。
- Azure Front Door 是一款現代化的雲端 CDN 與全球負載平衡器，為您的應用程式提供多種第 7 層負載平衡功能。 可提供動態網站加速 (DSA) 以及具有近乎即時容錯移轉的全域負載平衡。 它是一項高度可用且可擴展的服務，完全由 Azure 管理。
Azure Front Door 基本上是一個全球基於 HTTP 的負載平衡器。 用戶端會建立與 Front Door 本身的連線，因此 Front Door 會 Proxy 處理使用者的要求。 如果要求的專案不在快取中，則會識別正確的路由規則。 接著，它會檢查相關後端的健康探測，並在一切正常時，根據路由方法將使用者請求轉發至最佳後端。
因為 Azure Front Door 會代理連線，你可以執行一些進階功能，例如執行 Web 應用程式防火牆 和快取，這對擴展很有幫助。 這兩個功能都無法透過「流量管理員」達成。
此圖顯示如何同時使用這兩者。
此設定會使用流量管理員，對記憶體帳戶中的靜態資產進行簡單的 DNS 型負載平衡。 其也會使用 Front Door 在 Web 應用程式上跨 App Service 和 VM 進行路徑型路由。