地理節點模式

Geode 模式牽涉到將後端服務的集合部署到一組 geographical nodes，其中每一個都可以針對任何區域中的任何用戶端服務任何要求。 此模式允許以 主動-主動 樣式提供要求，藉由在世界各地散發要求處理來改善延遲並增加可用性。

內容和問題

許多大規模服務在異地可用性和規模方面都有特定的挑戰。 傳統設計通常會 將數據儲存在遠端 SQL Server 中，以作為該數據的計算層來將數據帶入計算 ，並依賴相應增加以進行成長。

傳統方法可能會面臨許多挑戰：

• 來自全球另一端的用戶連線到裝載端點的網路等待時間問題
• 需求高載的流量管理，可能會使單一區域中的服務不堪重負
• 將應用程式基礎結構複本部署到多個區域的成本禁止複雜度，以供 24x7 服務使用

新式雲端基礎結構已演變為啟用前端服務的地理負載平衡，同時允許後端服務的地理複寫。 為了獲得可用性和效能，讓數據更接近用戶是不錯的。 當數據分散在極遠的使用者基底時，異地分散式數據存放區也應該與處理數據的計算資源共置。 地理數據模式 會將計算帶入數據。

解決方案

將服務部署到散佈在世界各地的一些衛星部署，每個部署都稱為地理定位。 地理柵欄模式利用 Azure 的主要功能，透過最短路徑將流量路由傳送至附近的地理柵欄，進而改善延遲和效能。 每個地理柵欄都位於全域負載平衡器後方，並使用 Azure Cosmos DB 等異地複寫的讀寫服務來裝載數據平面，確保跨地區數據一致性。 數據復寫服務可確保跨地理位置的數據存放區完全相同，因此所有要求都可以從所有地理區域提供服務。

部署戳記和地理柵欄之間的主要差異在於地理區域永遠不會隔離。 生產平臺中一律應該有一個以上的地理設定。

地理區域具有下列特性：

• 由不同類型的資源集合所組成，通常定義於範本中。
• 在地理柵欄使用量之外沒有相依性，而且是獨立的。 沒有地理柵欄依賴另一個來操作，如果一個死亡，其他人繼續操作。
• 透過邊緣網路和復寫後板鬆散結合。 例如，您可以使用 Azure 流量管理員 或 Azure Front Door 來前端地理柵欄，而 Azure Cosmos DB 則可做為復寫後台程式。 地理區域與叢集不同，因為它們共用復寫後台程式，因此平臺會負責仲裁問題。

地理數據模式會在巨量數據架構中發生，這些架構會使用商用硬體來處理同一部計算機上共置的數據，而 MapReduce 則會跨計算機合併結果。 另一種使用方式是接近邊緣的計算，這可讓計算更接近網路的智慧邊緣，以減少響應時間。

服務可以使用此模式超過數十個或數百個地理區域。 此外，整個解決方案的復原功能會隨著每個新增的地理柵欄而增加，因為如果區域中斷讓一或多個異地中斷脫機，任何地理位置都可以接管。

您也可以使用全域可用性的地理柵欄模式來增強本機可用性技術，例如可用性區域或配對區域。 這會增加複雜度，但如果您的架構是由記憶體引擎所支撐，例如只能復寫到配對區域的 Blob 記憶體，這會很有用。 您可以將地理區域部署至區域內、區域或區域使用量，並留意位置的法規或延遲限制。

問題和考量

使用下列技術和技術來實作此模式：

• 現代化DevOps做法和工具，可跨大量區域或實例產生並快速部署相同的地理位置。
• 自動調整以相應放大地理區域內的計算和資料庫輸送量實例。 每個地理柵欄會在通用背板條件約束內個別相應放大。
• 像是 Azure Front Door 的前端服務，會執行動態內容加速、分割 TCP 和 Anycast 路由。
• 復寫數據存放區，例如 Azure Cosmos DB 來控制數據一致性。
• 盡可能降低無伺服器技術，以減少 Always-On 部署成本，尤其是在全球經常重新平衡負載時。 此策略可讓許多地理位置部署最少的額外投資。 無伺服器和以耗用量為基礎的計費技術可減少重複異地分散式部署的浪費和成本。
• API 管理 不需要實作設計模式，但可以新增至區域 Azure 函式應用程式前方的每個地理柵欄，以提供更健全的 API 層，例如實作額外的功能，例如速率限制。

當您決定如何實作此模式時，請考慮下列幾點：

• 選擇是否要在本機處理每個區域中的數據，或將匯總分散在單一地理區域中，並將結果復寫到全球各地。 Azure Cosmos DB 變更摘要處理器會使用其租用容器概念，以及對應 Azure Functions 系結中的 leasecollectionprefix，提供此細微的控制。 每個方法都有明顯的優點和缺點。
• 使用 Azure Cosmos DB 變更摘要和 SignalR 等即時通訊平臺，地理區域可以同時運作。 地理區域可以透過網格模式中的其他地理區域與遠端用戶通訊，而不需要知道或關心遠端使用者所在的位置。
• 此設計模式會隱含地分離所有專案，進而產生超高度分散式和分離架構。 請考慮如何追蹤相同要求的不同元件，因為它們可能會在不同的實例上以異步方式執行。 適當的監視策略至關重要。 Azure Front Door 和 Azure Cosmos DB 都可以輕鬆地與 Log Analytics 整合，且應與 Application Insights 一起部署 Azure Functions，以在架構中的每個元件上提供強固的監視系統。
• 分散式部署具有較多需要屬性安全性措施的秘密和輸入點。 金鑰保存庫 為秘密管理提供安全層，而且 API 架構內的每一層都應該受到適當的保護，讓 API 的唯一輸入點是 Azure Front Door 之類的前端服務。 Azure Cosmos DB 應該使用 Microsoft Entra ID 或 IP 限制等做法，限制 Azure Function Apps 的流量，以及將函式應用程式限制至 Azure Front Door。
• 效能會受到部署的地理位置數目和套用至每個地理位置中 API 技術的特定 App Service 方案所影響。 針對進階層部署額外的異地或移動，會增加額外的記憶體和計算成本，但不會在每個交易的基礎上這樣做。 請考慮在部署 API 架構之後進行負載測試，並以增加定價層來增加地理位置數目，讓最符合成本效益的模型用於您的需求。
• 判斷數據的可用性需求。 Azure Cosmos DB 具有選擇性旗標，可啟用多區域寫入、可用性區域等等。 這些會增加 Azure Cosmos DB 實例的可用性，並建立更具彈性的數據層，但會產生額外的成本。
• Azure 提供各種負載平衡器，可提供不同的功能來散發流量。 使用判定樹來協助為您的 API 前端選取正確的選項。

使用此模式的時機

使用此模式：

• 若要實作大規模平臺，讓使用者分散於廣域。
• 對於任何需要極端可用性和復原特性的服務，因為以地理柵欄模式為基礎的服務可以在同時遺失多個服務區域時倖存下來。

此模式可能不適合

• 具有條件約束的架構，讓所有地理位置都不能等於數據記憶體。 例如，可能有數據落地需求、需要維護特定會話暫存狀態的應用程式，或對單一區域要求進行加權的繁重要求。 在此情況下，請考慮使用部署戳記搭配全域路由平面，瞭解用戶數據所在的位置，例如部署戳記模式中所述的流量路由元件。
• 不需要地理分佈的情況。 相反地，請考慮可用性區域和配對區域來進行叢集。
• 需要改造舊版平台的情況。 此模式僅適用於雲端原生開發，而且難以進行改造。
• 簡單的架構和需求，其中異地備援和異地散發並非必要或有利。

工作負載設計

架構設計人員應該評估如何在其工作負載的設計中使用 Geode 模式，以解決 Azure Well-Architected Framework 支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

範例

• Windows Active Directory 會實作此模式的早期變體。 多主複寫表示所有可服務節點都可以從所有可服務節點提供所有更新和要求，但彈性單一主機作業 （FSMO） 角色表示所有地理位置不相等。
• GitHub 上的地理設計模式加速器會在實務上展示此設計模式，並設計來協助開發人員使用真實世界 API 來實作。