練習 - 新增 Web 應用程式健康情況檢查
- 30 分鐘
Contoso Shoes 需要一種方法，來檢查 API 層級的 Web 應用程式健康情況及其相依性。 您需要在應用程式上，實作定期報告 API 健全狀態的專用健康情況檢查端點。
目前的狀態和問題
在目前的設計中，當 API 程式碼發生運行時問題或相依服務的呼叫失敗時 (例如失敗的資料庫查詢)，應用程式會記錄錯誤。 此方法可用於在事件發生後針對問題進行疑難排解。
不過，此方法非主動性。 Azure App Service 和外部監視工具沒有辦法檢查應用程式本身的健康情況狀態。 此差距會影響許多使用案例，例如負載的分佈方式。 目前的實作僅依賴 App Service 方案盡力在不檢查應用程式健康情況下，在執行個體間均勻分配流量。 在某個回報的事件中，會將流量路由至狀況不良的 App Service 執行個體，進而導致要求失敗。
規格
您的工作是建置專用健康情況服務，作為已部署程式碼的延伸模組。
在您的應用程式中引進健康情況檢查 API。 API 必須檢查應用程式的健全狀態及其相依性，並傳回狀態指示。 例如，API 應定期檢查 Azure Cosmos DB 的讀取和寫入作業。 將這些函式實作為個別探查，以獨立檢查讀取和寫入。
提示
將健康情況檢查延伸至非功能性服務，例如 Azure Key Vault 和 Azure Container Registry。 此步驟很重要，因為如果這些服務發生中斷，您可能會注意到擴增或承受 App Service 執行個體重新開機的能力受到影響。
健康情況檢查 API 端點應經常由多個來源呼叫，而且不應降低 API 的效能。 例如，Azure App Service 方案必須每分鐘將要求傳送至端點兩次，並做出將流量散發至哪些 App Service 執行個體的明智決策。
透過將結果在記憶體中快取 10 秒來最佳化健康情況檢查 API 的效能。 並非所有健康情況檢查端點的查詢皆應產生後端呼叫。 某些回應可從快取提供。
讓健康情況檢查資料可在 Azure 監視器中使用以供未來分析。
建議的方法
若要開始設計，建議您使用下列方法：
1–健康情況檢查
健康情況檢查 API 傳送的所有查詢皆必須以非同步方式平行執行。 針對重要元件 (如資料庫) 設計健康情況檢查。 API 應定期檢查讀取和寫入作業。 將這些函式實作為個別探查，以獨立檢查讀取和寫入。
使用模擬實際應用程式行為的要求，而不需要從健康情況探查將過多負載放在服務上。 若要同時測試寫入要求，您必須設計有效率地移除測試資料的方式，使其不會與實際使用者資料混合。
2–快取模式
若要避免健康情況檢查使下游服務多載，健康情況檢查 API 應在可設定的秒數內快取結果。 請考慮達成此目標的可能方式。
檢查您的工作
以下是應用程式健康服務的範例。 您是否已涵蓋設計中的所有層面？
- 健康情況檢查端點是否與 Azure App 服務的健康情況檢查功能相容？
- 您是否包含執行時間相依性的檢查？ 您使用什麼做為 Proxy/測試？
- Cosmos DB 讀取/寫入
- 協力廠商 API
- 您是否快取健康情況檢查的結果，以減少效能額外負荷？
- 您是否在健康情況檢查中記錄事件？ 您是否記下成功和失敗？
- 您是否已將 Azure Application Insights 記錄取樣套用至健康情況檢查記錄？