运行状况终结点监视模式

若要验证应用程序和服务是否正常运行，可以使用运行状况终结点监视模式。 此模式指定在应用程序中使用功能检查。 外部工具可以通过公开的终结点定期访问这些检查。

上下文和问题

监视 Web 应用程序和后端服务是一种良好的做法。 监视有助于确保应用程序和服务可用并正常运行。 业务要求通常包括监视。

监视云服务有时比监视本地服务更困难。 一个原因是你无法完全控制托管环境。 另一个原因是服务通常依赖于平台供应商和其他一方提供的其他服务。

许多因素都会影响云托管的应用程序。 示例包括网络延迟、基础计算和存储系统的性能与可用性，以及这些系统之间的网络带宽。 由于其中的任何因素，服务可能发生整体性或局部性的故障。 为了确保达到所需的可用性级别，必须定期验证服务是否正常运行。 服务级别协议 (SLA) 可能规定了需要达到的级别。

解决方案

通过将请求发送到应用程序上的终结点来实现运行状况监视。 应用程序应执行必要的检查，然后返回其状态指示。

运行状况监视检查通常结合了两个因素：

• 应用程序或服务在响应针对运行状况验证终结点的请求时执行的检查（如果有）
• 通过执行运行状况验证检查的工具或框架分析结果

响应代码指示应用程序的状态。 响应代码还会选择性地提供应用使用的组件和服务的状态。 监视工具或框架执行延迟或响应时间检查。

下图提供了模式概览。

应用程序中的运行状况监视代码还可能运行其他检查来确定：

• 云存储或数据库的可用性和响应时间。
• 应用程序使用的其他资源或服务的状态。 这些资源和服务可能位于应用程序内部或外部。

可以使用某些服务和工具，通过将请求提交到一组可配置的终结点来监视 Web 应用程序。 然后，这些服务和工具根据一组可配置的规则评估结果。 创建一个只是在系统上执行某些功能测试的服务终结点相对较为容易。

监视工具执行的典型检查包括：

• 验证响应代码。 例如，HTTP 响应 200（正常）表示应用程序已做出响应且未出错。 监视系统可能还会检查其他响应代码以提供更全面的结果。
• 即使状态代码为 200（正常），也会检查响应内容以检测错误。 通过检查这些内容，你可以检测仅影响所返回网页的某个部分或服务响应的错误。 例如，你可以检查页面标题，或查找指示应用返回了正确页面的特定短语。
• 度量响应时间。 该值包括网络延迟，以及应用程序发出请求所花费的时间。 如果值增大，则可能表示应用程序或网络正在出现问题。
• 检查位于应用程序外部的资源或服务。 一个例子是内容分发网络，应用程序使用它从全局缓存分发内容。
• 检查 TLS 证书是否过期。
• 度量针对应用程序 URL 执行 DNS 查找所花费的响应时间。 此项检查度量 DNS 延迟和 DNS 故障。
• 验证 DNS 查找返回的 URL。 通过验证，你可以确保条目正确。 此外，可以帮助防止在 DNS 服务器受到攻击后可能导致的恶意请求重定向。

在可能的情况下，从不同的本地位置或托管位置运行这些检查，然后比较响应时间也很有用。 理想情况下，应该从靠近客户的位置监视应用程序。 这样可以获取每个位置的准确性能视图。 这种做法提供了更可靠的检查机制。 结果还可以帮助你做出以下决策：

• 在何处部署你的应用程序
• 是否将其部署到多个数据中心

为确保所有客户都可正常运行你的应用程序，请针对客户使用的所有服务实例运行测试。 例如，如果客户存储分散在多个存储帐户中，则监视过程应检查每个帐户。

问题和注意事项

在决定如何实现此模式时，请考虑以下几点：

• 考虑如何验证响应。 例如，确定 200（正常）状态代码是否足以确认应用程序在正常运行。 检查状态代码是此模式的最基本实现方式。 状态代码提供应用程序可用性的基本度量。 但是，代码在应用程序中的操作、趋势和可能即将出现的问题方面提供的信息极少。

• 确定要为应用程序公开的终结点数。 一种方法是为应用程序使用的核心服务至少公开一个终结点，并为低优先级服务公开另一个终结点。 通过这种方法，可将不同级别的重要性分配给每项监视结果。 此外，请考虑公开更多的终结点。 可为每个核心服务公开一个终结点，以提高监视粒度。 例如，运行状况验证检查可能会检查应用程序使用的数据库、存储和外部地理编码服务。 每个检查项需要不同级别的运行时间和响应时间。 地理编码服务或其他某个后台任务可能有几分钟不可用。 但应用程序可能仍处于正常状态。

• 确定是否使用同一个终结点进行监视和常规访问。 可以将同一个终结点用于这两项活动，但为运行状况验证检查设计特定的路径。 例如，可以在常规访问终结点上使用 /health。 通过这种方法，监视工具可以在应用程序中运行某些功能测试。 例如，注册新用户、登录和下达测试工单。 同时，你还可以验证常规访问终结点是否可用。

• 确定响应监视请求时要在服务中收集的信息类型。 还需要确定如何返回此信息。 大多数现有工具和框架仅查看终结点返回的 HTTP 状态代码。 若要返回并验证其他信息，可能需要创建自定义监视实用工具或服务。

• 确定要收集的信息量。 在检查期间执行过多的处理可能导致应用程序过载并影响其他用户。 处理时间还可能超过监视系统的超时。 因此，系统可能会将应用程序标记为不可用。 大多数应用程序包含错误处理程序和性能计数器等检测功能。 这些工具可以记录性能和详细错误信息，这些信息可能已足够。 请考虑使用这些数据，而不要通过运行状况验证检查返回其他信息。

• 考虑缓存终结点状态。 频繁执行运行状况检查可能会产生很高的开销。 例如，如果通过仪表板报告运行状况，则你不希望每次向仪表板发出请求都触发运行状况检查。 应该定期检查系统运行状况并缓存状态。 公开返回缓存状态的终结点。

• 规划如何为监视终结点配置安全性。 配置安全性有助于防止以公开方式访问终结点，否则可能会导致：

  • 应用程序遭受恶意攻击。
  • 泄露敏感信息的风险。
  • 吸引拒绝服务 (DoS) 攻击。

  通常你会在应用程序配置中配置安全性。 然后，无需重启应用程序即可轻松更新设置。 考虑使用以下一种或多种技术：

  • 要求身份验证，以保护终结点。 如果监视服务或工具支持身份验证，则你可以在请求头中使用身份验证安全密钥。 还可以在请求中传递凭据。 使用身份验证时，请考虑如何访问运行状况检查终结点。 例如，Azure 应用服务有一个内置运行状况检查与应用服务的身份验证和授权功能集成。

  • 使用模糊化或隐藏的终结点。 例如，在不是由默认应用程序 URL 使用的 IP 地址上公开终结点。 在非标准 HTTP 端口上配置终结点。 此外，考虑使用测试页的复杂路径。 通常可以在应用程序配置中指定额外的终结点地址和端口。 如有必要，可将这些终结点的条目添加到 DNS 服务器。 然后，可以避免直接指定 IP 地址。

  • 在终结点上公开一个可接受键值或操作模式值等参数的方法。 当请求到达时，代码可以运行依赖于参数值的特定测试。 如果代码无法识别参数值，代码可能会返回 404（未找到）错误。 可以在应用程序配置中定义参数值。

  • 使用一个单独的终结点，在不影响应用程序正常运行的情况下执行基本功能测试。 这种方法有助于减轻 DoS 攻击的影响。 理想情况下，请避免使用可能透露敏感信息的测试。 有时必须返回可能对攻击者有用的信息。 在这种情况下，请考虑如何防止未经授权访问终结点和数据。 仅凭模糊处理并不足够。 另请考虑使用 HTTPS 连接并加密敏感数据，不过这种方法会增大服务器的负载。

• 确定如何确保监视代理正常运行。 一种方法是公开一个返回应用程序配置中的值，或者返回可用于测试代理的随机值的终结点。 另请确保监视系统对自身执行检查。 可以使用自我测试或内置测试来防止监视系统发出误报结果。

何时使用此模式

此模式适合用于：

• 监视网站和 Web 应用程序，以验证可用性。
• 监视网站和 Web 应用程序以检查是否正常运行。
• 监视中间层或共享服务，以检测并隔离可能会中断其他应用程序的故障。
• 补充应用程序中的现有检测，例如性能计数器和错误处理程序。 运行状况验证检查不能取代应用程序的日志记录和审核要求。 检测可为现有框架提供有用的信息，使它们能够监视计数器和错误日志，以检测故障或其他问题。 但是，如果应用程序不可用，则检测功能无法提供信息。

工作负荷设计

架构师应评估如何在其工作负载的设计中使用“运行状况终结点监视模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

示例

可以使用 ASP.NET 运行状况检查中间件和库来报告应用基础结构组件的运行状况。 此框架提供了以一致方式报告运行状况检查的方法。 它实施本文所述的许多做法。 例如，ASP.NET 运行状况检查包括外部检查（如数据库连接）和特定的概念（如运行情况和就绪情况探测）。

GitHub 上提供了几个使用 ASP.NET 运行状况检查的示例实现。

监视 Azure 托管应用程序中的终结点

用于监视 Azure 应用程序中的终结点的选项包括：

• 使用 Azure 的内置监视功能，例如 Azure Monitor。
• 使用第三方服务或框架，例如 Microsoft System Center Operations Manager。
• 创建自定义实用工具，或者创建可在你自己的服务器或托管服务器上运行的服务。

尽管 Azure 提供了全面的监视选项，但你也可以使用其他服务和工具来提供附加信息。 Application Insights 是 Azure Monitor 中的一项功能，专为开发团队而设计。 此功能可帮助你了解应用的运行状态和使用方式。 Application Insights 监视请求速率、响应时间、故障率和依赖项率。 它可以帮助你了解外部服务是否会导致速度减慢。

可监视的条件根据你为应用程序选择的托管机制而定。 本部分中的所有选项都支持警报规则。 警报规则使用你在服务设置中指定的 Web 终结点。 该终结点应及时做出响应，使警报系统可以检测到应用程序在正常运行。 有关详细信息，请参阅创建新的警报规则。

如果发生严重的服务中断，客户端流量应可路由到其他区域或地区中可用的应用程序部署。 这种情况非常适合使用跨界连接和全局负载均衡。 具体选择取决于应用程序是面向内部还是外部。 Azure Front Door、Azure 流量管理器或内容分发网络等服务可以根据运行状况探测提供的数据跨区域路由流量。

流量管理器是一个路由和负载均衡服务。 它可以使用一系列规则和设置将请求分发到应用程序的特定实例。 除了路由请求外，流量管理器还可以定期对 URL、端口和相对路径执行 ping。 指定 ping 目标的目的是确定应用程序的哪些实例处于活动状态并可响应请求。 如果流量管理器检测到状态代码 200（正常），它会将应用程序标记为可用。 其他任何状态代码会导致流量管理器将应用程序标记为脱机。 流量管理器控制台显示每个应用程序的状态。 可以配置每个规则，以将请求重新路由到可做出响应的应用程序的其他实例。

流量管理器会在等待特定的一段时间后从监视 URL 接收响应。 请确保你的运行状况验证代码在这段等待时间内运行。 考虑在流量管理器与应用程序之间往返通信时所存在的网络延迟。

后续步骤

以下指导可帮助你实现此模式：

• 基于微服务的应用程序中的运行状况监视指导
• 监视应用程序运行状况以确保可靠性（Azure 架构良好的框架的一部分）
• 新建警报规则

相关资源

• 外部配置存储模式
• 断路器模式
• 网关路由模式
• 守护程序模式