负载均衡监控组：多服务健康检查为弹性应用保驾护航

现代应用不再是单体架构，而是复杂的分布式系统，其可用性依赖于多个独立组件的协同工作。Web服务器可能正在运行，但如果其数据库连接中断或身份验证服务无响应，整个应用仍处于不健康状态。依赖单一健康检查就像只知道"检查引擎"灯未亮，却不知道某个轮胎已被扎破——发动机运转良好，但你可能开不了多远。

随着应用复杂度的增加，“健康"的定义也变得更加复杂。我们听到各种规模的客户反馈，他们需要验证多个服务才能确认端点已准备好接收流量。例如，在将用户路由到某个端点前，他们可能需要确认底层API网关健康且特定的”/login"服务响应正常。此前，这需要构建自定义的聚合服务来整合这些检查，增加了运维开销和潜在的故障点。

今天，我们为Cloudflare负载均衡推出监控组功能。该特性提供了一种在我们的平台上直接创建复杂多服务健康评估的新方法。通过监控组，您可以将多个健康监控捆绑为单一逻辑实体，定义哪些组件是关键组件，并使用聚合健康评分做出更智能、更具弹性的故障转移决策。

这项新功能通过API向企业客户提供，消除了对自定义健康聚合服务的需求，并能更准确地反映应用的真实可用性。在不久的将来，该功能将出现在所有负载均衡用户的仪表板中，不仅限于企业客户！

监控组工作原理

监控组作为监控器的超集运行。创建监控器后，它们可以捆绑成单个单元——监控组！当您将监控组附加到端点池时，该池中每个端点的健康状况通过聚合组内所有启用监控器的结果来确定。这些在监控组"members"数组中定义的设置，让您能够精细控制整体健康状态的判定方式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// 组内单个监控器的结构
{
  "description": "测试监控组",
  "members": [
    {
      "monitor_id": "字符串",
      "enabled": true,
      "monitoring_only": false,
      "must_be_healthy": true
    },
    {
      "monitor_id": "字符串",
      "enabled": true,
      "monitoring_only": false,
      "must_be_healthy": true
    }
  ]
}

以下是每个属性的作用：

关键监控器(must_be_healthy)：您可以将监控器指定为关键。如果具有此设置的监控器对某个端点的健康检查失败，该端点将立即被标记为不健康。这为基本服务提供了明确的覆盖，无论组中其他监控器的状态如何。

观察性探测(monitoring_only)：将监控器标记为"仅监控"，可在不影响池健康状态或流量导向的情况下接收警报和数据。这非常适合测试新检查或观察非关键依赖项，而不会影响生产流量。

基于仲裁的健康状态：在没有关键监控器失败的情况下，端点的健康状况由所有其他活动监控器的仲裁决定。只有当超过50%的已分配监控器报告端点不健康时，该端点才会被视为全局不健康。此系统可防止由于单个非关键监控器的瞬时故障而将端点过早标记为不健康。

您最多可以向组中添加五个监控器。

![显示三个健康监控器(HTTP、TCP和数据库)组合成单个监控组的图表。该组附加到Cloudflare负载均衡池，该池评估三个源服务器的健康状况。]

全球分布式视角

监控组的功能通过Cloudflare全球网络的规模得到增强。健康检查不是从少数静态位置执行；可以配置从全球300多个城市的数据中心执行。虽然您可以同时从每个数据中心配置监控(“所有数据中心"模式)，但我们建议对大多数应用采用更有针对性的方法。选择几个不同的区域，如北美西部和东欧，或使用"所有区域"设置，可以提供对应用健康状况的强大全球视角，同时减少发送到源站的健康监控流量。这在应用健康方面创建了分布式共识，防止局部网络问题触发误报并导致不必要的全局故障转移。您的应用健康状况不是由单一视角决定，而是由全球视角决定。

同样的原则在与监控组结合使用时提升了动态导向的能力。监控组的延迟不仅仅是单个RTT测量值。它是一个整体性能评分，可能从数百个存在点平均得出，涵盖您定义的所有关键服务。这意味着您的负载均衡器基于对应用性能的真实、全局感知来引导流量。

对于使用动态导向和监控组的负载均衡器，用于做出导向决策的延迟现在计算为组中所有活动的非仅监控成员的平均往返时间(RTT)。这提供了更稳定和具有代表性的性能指标。动态导向现在可以基于所有关键组件的集体性能做出决策，而不是依赖单个服务的延迟，确保流量被发送到真正整体性能最佳的端点。

健康聚合实战

让我们通过一个示例了解Cloudflare如何聚合来自监控组的健康信号以确定单个端点的整体健康状况。在此场景中，我们的应用有三个需要检查的关键组件：面向公众的/health端点、在特定TCP端口上运行的另一服务以及数据库依赖项。隐私和安全至关重要，因此，为了在不将数据库暴露给公共互联网的情况下监控它，您可以使用Cloudflare Tunnel安全地将其连接到Cloudflare，允许我们的健康检查安全地访问它。

设置

组中的健康监控器：

/health的HTTP检查(must_be_healthy: true)
端口3000连接的TCP检查(must_be_healthy: false)
数据库健康的DB检查(must_be_healthy: false)

健康检查区域：

北美西部(3个数据中心)
北美东部(3个数据中心)

仲裁阈值：如果超过50%的检查数据中心报告端点为UP，则认为该端点健康。

首先，Cloudflare从每个独立数据中心的角度确定健康状况。如果关键监控器失败，该数据中心的结果明确为DOWN。否则，结果基于剩余监控器的多数状态。

这是我们六个数据中心的结果：

[图片描述：显示来自两个区域六个数据中心的健康检查结果的表格。六个数据中心中的一个报告"DOWN"状态，因为关键HTTP监控器失败。其他五个报告"UP”，因为关键监控器通过且剩余监控器中的大多数是健康的。]

最后，所有六个检查数据中心的结果被组合以确定端点的最终全局健康状态。

全局结果：6个总数据中心中的5个(83%)报告端点为UP。

结论：因为83%大于50%的仲裁阈值，端点被视为全局健康并将继续接收流量。

这种多层仲裁系统提供了惊人的弹性，确保故障转移决策基于全面且地理分布的共识。

开始使用监控组

监控组现在通过API向所有拥有企业版Cloudflare负载均衡订阅的客户提供，并将在不久的将来向自助服务客户提供。要立即开始为您的应用构建更复杂的健康检查，请查看我们的开发人员文档。

要创建监控组，您可以使用POST请求发送到新的/load_balancers/monitor_groups端点。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


POST accounts/{account_id}/load_balancers/monitor_groups
{
  "description": "结账服务的监控组",
  "members": [
    {
      "monitor_id": "字符串",
      "must_be_healthy": true,
	"enabled": true
    },
    {
      "monitor_id": "字符串",
      "monitoring_only": false,
	"enabled": true
    }
  ]
}

创建后，您可以通过在池对象的monitor_group字段中引用其ID来将组附加到池。

未来展望

我们继续构建无缝的平台体验，简化内部和外部应用的流量管理。展望未来，监控组很快将进入所有用户的仪表板！我们还在开发更灵活的基于角色的访问控制和更先进的基于负载的负载均衡功能，为您提供管理最复杂应用所需的精细控制。

Cloudflare的连接云保护整个企业网络，帮助客户高效构建互联网规模的应用，加速任何网站或互联网应用，抵御DDoS攻击，阻止黑客，并可以帮助您完成零信任之旅。

从任何设备访问1.1.1.1，开始使用我们的免费应用，使您的互联网更快更安全。

要了解有关我们帮助构建更好互联网的使命的更多信息，请从此处开始。如果您正在寻找新的职业方向，请查看我们的空缺职位。

负载均衡监控组：为弹性应用构建多服务健康检查

Cloudflare推出负载均衡监控组功能，支持将多个健康检查监控捆绑为单一逻辑实体，通过关键服务标记、观察性探测和基于仲裁的健康评估，实现更智能的故障转移决策，提升分布式应用的弹性。