练习 - 添加 Web 应用程序运行状况检查
- 30 分钟
Contoso Shoes 需要一种方法来检查 API 级别的 Web 应用程序运行状况及其依赖项。 你希望在应用程序上实现专用运行状况检查终结点，该终结点会定期报告 API 运行状况。
当前状态和问题
在当前设计中，当 API 代码中存在运行时问题或是对依赖服务的调用失败（例如数据库查询失败）时，应用程序会记录错误。 此方法可用于在事件发生后对问题进行故障排除。
但是，此方法不是主动性的。 Azure 应用服务和外部监视工具无法检查应用程序本身的运行状况。 这种差距会影响许多用例，例如负载的分布方式。 当前实现仅依赖于应用服务计划会尽力在不检查应用程序运行状况的情况下，在实例间均匀分配流量。 在一个报告的事件中，流量路由到运行不正常的应用服务实例，从而导致请求失败。
规范
任务是将专用运行状况服务构建为已部署代码的扩展。
在应用程序中引入运行状况检查 API。 API 必须检查应用程序的运行状况及其依赖项，并返回状态指示。 例如，API 应定期检查对 Azure Cosmos DB 的读取和写入操作。 将这些函数作为单独探测进行实现，以便独立检查读取和写入。
提示
将运行状况检查扩展到非功能服务，例如 Azure Key Vault和 Azure 容器注册表。 此步骤十分重要，因为如果这些服务遇到中断，则你可能会注意到横向扩展或承受应用服务实例重启的能力受到影响。
运行状况检查 API 终结点由多个源频繁调用，不应降低 API 的性能。 例如，Azure 应用服务计划必须每分钟向终结点发送两次请求，并做出有关要将流量分配到哪些应用服务实例的明智决策。
通过将结果在内存中缓存 10 秒来优化运行状况检查 API 的性能。 并非对运行状况检查终结点的每个查询都应导致后端调用。 某些响应可以从缓存进行提供。
使运行状况检查数据可在 Azure Monitor 中用于将来进行分析。
推荐的方法
若要开始设计，建议采用以下方法：
1 – 运行状况检查
运行状况检查 API 发送的所有查询都必须以异步方式并行执行。 针对关键组件（如数据库）设计运行状况检查。 API 应定期检查读取和写入操作。 将这些函数作为单独探测进行实现，以便独立检查读取和写入。
使用模拟实际应用程序行为的请求，而不是仅仅从运行状况探测对服务施加过多负载。 若要也测试写入请求，需要设计一种方法来高效移除测试数据，使其不会与实际用户数据混合。
2 – 缓存模式
若要避免运行状况检查使下游服务过载，运行状况检查 API 应在可配置的秒数内缓存结果。 考虑实现此目标的可能方法。
检查你的工作
下面是 应用程序健康服务示例。 是否在设计中涵盖了所有方面？
- 运行状况检查终结点是否与 Azure 应用服务的运行状况检查功能兼容？
- 是否包含对运行时依赖项的检查？ 将什么用作代理/测试？
- Cosmos DB 读/写
- 第三方 API
- 是否缓存运行状况检查的结果以减少性能开销？
- 是否在运行状况检查中记录事件？ 是否记下了成功和失败？
- 是否已将 Azure Application Insights 日志采样应用于运行状况检查日志？