練習 - 新增 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 Service 的健全狀況檢查功能相容？
• 您是否包含執行時間相依性的檢查？ 您使用什麼做為 Proxy/測試？
  • Cosmos DB 讀取/寫入
  • 第三方 API
• 您是否快取健康情況檢查的結果，以減少效能額外負荷？
• 您是否在健康情況檢查中記錄事件？ 您是否記下成功和失敗？
• 您是否已將 Azure Application Insights 記錄取樣套用至健康情況檢查記錄？

知識檢查