我們已經使用默認設置使用Azure流量管理器部署了我們的高可用性解決方案。使用Azure流量管理器實現高可用性
我們選擇的路由方法是性能。
我們預計一旦主服務器關閉，用戶就會轉移到輔助服務器。但不幸的是延遲了30秒。對於我們測試中的那些30秒，我們發現用戶正在收到未響應問題和請求超時。需要幾分鐘的時間才能找回所有工作。 Azure Traffic Manager with 30 second TTL 通常，我們不會在Facebook或微軟網站觀察到這些輟學，這些網站肯定會保持高可用性的解決方案。
我們是否需要在我們的應用程序中編寫代碼來優雅地處理這些退出，就像在客戶端顯示對話框一樣，我們很快會回來等等？什麼是最好的解決方案，以便用戶體驗無縫。
由於Azure流量管理器是基於DNS的負載均衡器，客戶端必須等待DNS條目上的TTL通過才能重新查詢DNS。這就是爲什麼你有你的問題。流量管理器不管理通信本身，只是您的客戶端將通過DNS與哪個服務器進行通信
Facebook和Microsoft正在更深層次的協議中使用負載平衡器（例如平衡IP地址）當一個節點退出時，負載均衡器可以切換到另一個節點，因爲它正在接收並重定向所有流量。
如果您可以切換到將解決您的問題的Azure負載平衡器（不確定名稱）。否則，你不得不縮短你的TTL或代碼來刷新你的DNS緩存並重試。
Azure負載平衡器或應用程序網關的問題在於，它們不適用於數據中心而僅適用於Azure流量管理器，因此Web應用程序必須管理它們自身的錯誤，並在一段時間後進行刷新（以確保TTL已過期）重定向到新的服務器。 https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
您正在運行Web App的多個實例嗎？如果是這樣，流量管理器故障切換解決方案僅僅是爲了在Azure數據中心全面停機的情況下爲您提供保護嗎？ –
對於故障轉移，您希望配置優先級算法，而不是性能。另外，您是否有多個Web應用程序實例，或者您有多個Web應用程序託管您的網站？ –