ClusterNode

ClusterNode 是 Alibaba Sentinel 中用于实现全局资源维度流量统计的核心数据结构。要深入理解其作用，需掌握两个关键设计思想：

1. 全局视角：对于同一个资源（resource），无论其被哪个业务上下文（Context）调用，所有请求的统计数据都会汇聚到唯一的 ClusterNode 实例中进行统一管理。
2. 来源隔离：支持按照调用方（origin）进行细分统计，从而实现“根据不同调用来源实施差异化流控”的策略需求。

接下来我们将从结构、用途与并发设计三个层面逐步解析。

一、什么是 ClusterNode？

定位：作为每个资源名在系统中的全局唯一统计节点。

每一个受 Sentinel 保护的资源（例如接口 /api/order）都会对应一个独立的 ClusterNode 实例。

/api/order

该类继承自 StatisticNode，因此天然具备以下核心指标的统计能力：

• QPS（通过量与拒绝量）
• 平均响应时间（RT）
• 当前并发线程数
• 异常请求数

特点说明：

// 同一个资源名称，全局仅存在一个 ClusterNode 实例
// 即使你在 Context A 或 Context B 中调用 /api/order 接口
// 所有流量仍会汇总至这一个共享的统计节点上

类比理解：如果将每一个 Context 视作公司内部的不同“部门”，那么 ClusterNode 就相当于整个公司的“总报表中心”，负责汇总所有部门对某一特定接口的访问情况。

Context

二、为何需要按 origin 分别统计？——originCountMap 的设计动机

背景：Sentinel 支持通过调用上下文标识调用方身份，例如：

ContextUtil.enter("/api/order", "user-service");   // 用户服务发起调用
ContextUtil.enter("/api/order", "admin-service");  // 管理后台服务发起调用

实际需求：尽管整体 QPS 需要控制，但不同来源的服务往往应适用不同的限流阈值。

比如：

user-service

admin-service

这就要求系统不仅要维护资源的总体流量视图，还需支持按 origin 维度拆分统计。

解决方案：引入字段

private Map<String, StatisticNode> originCountMap = new HashMap<>();

其中：

• Key：

  origin

  —— 调用方标识（通常为应用名称）
• Value：专属的 StatisticNode 实例，专门记录来自该 origin 的请求数据

效果对比：

• ClusterNode 自身：统计所有调用来源的总和数据
  

  ClusterNode

• originCountMap.get("user-service")：仅统计 user-service 发起的请求流量
  

  originCountMap.get("user-service")

三、线程安全机制：为何选用显式锁而非并发容器？

这是 Sentinel 源码中一段极具启发性的注释：

// The longer the application runs, the more stable this mapping will become.
// So we didn't use concurrent map here, but a lock,
// as this lock only happens at the very beginning while concurrent map will hold the lock all the time.

下面通过对比分析来理解这一设计选择。

ConcurrentHashMap

HashMap + ReentrantLock

为何此设计合理？基于以下三点现实考量：

• origin 数量有限：通常仅有数个至数十个调用方（如 user-service、order-service 等）
• 配置趋于稳定：应用启动后，新增调用来源的情况极为罕见
• 访问模式偏斜：99% 的请求属于“读取已有 origin 的统计节点”，仅首次注册某个新 origin 时才触发写操作
  

  get(origin)

因此，在写操作极少发生的前提下，使用“写时复制 + 显式锁”策略，可以在保障线程安全的同时极大提升高频读取的效率。

结论：这是一种典型的“为稳定运行状态优化”的工程权衡，优先服务于系统的长期高性能表现。

写时复制（Copy-on-Write）的具体实现逻辑：

lock.lock();
try {
    // double-check 机制避免重复创建
    if (originCountMap.get(origin) == null) {
        StatisticNode newNode = new StatisticNode();
        // 创建新 HashMap，复制旧数据并加入新项
        HashMap<string, statisticnode> newMap = new HashMap<>(originCountMap.size() + 1);
        newMap.putAll(originCountMap);
        newMap.put(origin, newNode);
        originCountMap = newMap; // 原子性地替换引用
    }
} finally {
    lock.unlock();
}

这种设计确保了 originCountMap 的引用始终指向一个不可变对象（immutable），从而使得后续的并发读取无需加锁即可安全执行。

originCountMap

ClusterNode

StatisticNode

originCountMap

ContextUtil.enter(resourceName, origin)

ReentrantLock

ConcurrentHashMap

put

读操作不需要加锁，可直接进行访问，保证了统计过程中的高性能读取能力。

写操作则通过原子引用的方式完成切换，有效避免在并发修改时出现异常情况，确保数据一致性。

originCountMap.get(origin)

四、典型使用场景

场景：基于调用方的限流控制

// 示例规则：限制来自 "user-app" 的请求，QPS 不超过 50
FlowRule rule = new FlowRule("GET:/order")
    .setLimitApp("user-app")      // ← 核心配置：指定流量来源 origin
    .setCount(50)
    .setGrade(RuleConstant.FLOW_GRADE_QPS);

Sentinel 内部工作机制：

当请求进入系统时，Sentinel 会执行以下流程：

ContextUtil.enter("/order", "user-app")

ClusterNode clusterNode = ...

（获取对应资源的全局节点信息）

Node originNode = clusterNode.getOrCreateOriginNode("user-app")

在进行流控检查阶段：

• 若规则中明确指定了

  limitApp="user-app"

  → 则检查该特定来源

  originNode

  的 QPS 情况；
• 否则 → 统一检查

  clusterNode

  的总体 QPS。

五、总结：核心价值解析

ClusterNode

origin

一句话理解：

ClusterNode

它使得系统既能掌握整体流量趋势（森林），又能精确识别每个调用方的流量行为（每棵树），从而支撑更智能的流控与熔断决策。

这种架构设计充分体现了“统一管理、精细控制”的分布式治理理念，也是 Sentinel 能够广泛应用于微服务架构中的关键因素之一。