練習 - 將您的設計擴充至多個區域
Contoso Shoes 需要可承受區域中斷的方法。 您想要將目前的戳記部署至主動-主動、共用狀態和多區域拓撲。 架構的設計必須設計為將流量重新導向至另一個區域，以防區域失敗。
目前的狀態和問題
單一區域已足堪應用程式使用。 不過，近期影響到網路功能的區域中斷導致系統在使用者端呈現離線狀態。 在區域內進行水平調整，甚或在該區域中部署新的戳記，都不會使應用程式從失敗狀態復原。
DNS 由 api.contososhoes.com 的現有註冊機構所持有。 DNS 記錄會解析為後端應用程式服務端點 (apicontososhoes.azurewebsites.net)，存留時間 (TTL) 期間為兩天。 當解決方案部署至多個區域時，必須移轉 DNS。
規格
- 擴充結構，以在主動-主動的多區域拓撲中運作。
- 修改部署戳記模型，讓您能夠視需要動態新增和移除區域，而不是列出兩個區域間的硬式編碼資源。
- 如果發生區域性失敗，流量必須路由傳送至非錯誤區域，且不會對已在非錯誤區域中的用戶端造成任何顯著的影響。
- 用戶端不應釘選到區域。
- 用戶端應該無須變更 URL 以聯繫 API。 DNS 應移轉至全域路由器。
建議的方法
若要開始設計，建議您依照這些步驟操作：
1：多區域拓撲
架構必須散發至兩個或更多 Azure 區域，以防止區域中斷。 選擇區域時請考量下列因素：
- 此區域必須能夠承受該區域的資料中心中斷。
- 此區域必須支援在結構中使用的 Azure 服務和功能。
- 區域和部署於其中的資源必須接近使用者和相依系統，以盡可能縮短網路延遲。
思考失敗案例。 假設區域 1 會獲得 75% 的流量，而新增的區域 2 則獲得其餘流量。 兩者都會適當調整，以處理該負載。 區域 1 發生區域中斷，所有流量現在都會路由傳送至區域 2。 您能夠順暢地完成轉換嗎？ 區域 2 可支援增加的流量負載嗎？
檢查您的進度：全域散發
2 – 全域路由
若要讓用戶端以透明的方式路由傳送至任一個工作區域，請新增全域負載平衡器。 負載平衡器應使用您在先前的練習中新增的健康情況檢查，以判斷戳記是否狀況良好。 您是否能想辦法處理頻繁且類似的要求，且不需聯繫後端就能達到要求？
- 選擇與現有架構整合、且能夠快速容錯移轉的原生 Azure 服務。
- 請確定網路輸入路徑有控制機制可拒絕未經授權的流量。
- 藉由從邊緣快取為終端使用者提供服務，盡可能縮短網路延遲。
- 移轉現有的 DNS，而不影響現有的用戶端。
- 有自動化方式可指出區域性失敗，以確保流量不會路由傳送至錯誤的區域。 此外，在區域恢復為可用時取得通知，讓負載平衡器可以繼續路由傳送至該區域。
檢查您的進度：全域流量路由
3 – 部署戳記變更
理想的狀態是主動-主動設定，不需要任何手動容錯移轉，而且可從任何區域處理用戶端要求。 想想這對您的架構有何意涵。 例如，您是否有任何狀態儲存在區域戳記中？
目前架構中的某些服務具有異地複寫功能。 請考慮將服務分成不同的戳記：一個是包含全域資源的戳記，另一個區域戳記會與全域戳記共用資源。 這些資源的生命週期應為決定因素之一。 相對於結構中的其他資源，資源的預期存留期為何？ 資源應有較長的存留期，還是與整個系統或區域共用存留期，或者應為暫時的？
探索架構中使用的 Azure 服務的可靠性功能。 您可以從這些功能開始著手，再進一步探索，以獲得最大的可靠性。
| Azure 服務 | 功能 |
|---|---|
| Azure Cosmos DB | 多區域寫入 |
| Azure Container Registry | 異地複寫 |
| Azure App Service 方案 | 可用性區域支援 |
檢查您的工作
以下是類似架構的應用程式和資料設計選項。 您的設計是否涵蓋了各個層面？
- 您為多區域拓撲選取了其他哪個 Azure 區域？原因為何？
- 您是否在每個 Azure 區域中啟用了兩個或更多 Azure 可用性區域，以防止資料中心中斷？
- 您是否納入了 Web 應用程式防火牆以控制輸入流量？ 您設置了哪些路由規則？原因為何？
- 負載平衡器如何支援您現有的 DNS 記錄？
- 您如何使用先前練習中的健康情況檢查 API？
- 您是否保護應用程式不受 DDoS 攻擊，特別是防止惡意用戶端略過負載平衡器並進入區域執行個體？
- 您如何處理 DNS 移轉？
- 您是否對現有元件進行了任何 SKU 變更以支援多區域拓撲？
- 您將哪些 Azure 服務保留為單一服務？ 您如何做出每項服務的合理選擇？ 您是否進行了任何設定變更？
- 您是否記錄資源？ 您認為這會影響您對整體系統檢查記錄的能力嗎？