Sentinel核心：ClusterNode全局资源统计解析

ClusterNode 类是 Alibaba Sentinel（流量治理组件）中用于 全局资源维度统计 的核心数据结构。理解它，关键在于把握两个核心概念：

✅ 1. 全局视角：同一个资源（resource），无论在哪个业务上下文（Context）中被调用，都共享同一个 ClusterNode。

✅ 2. 来源隔离：按调用方（origin）细分统计，支持"针对不同调用方做差异化流控"。

下面我们逐层拆解。

---

🌐 一、ClusterNode 是什么？

定位

• 全局唯一的资源统计节点。
• 每个受 Sentinel 保护的 资源名（如 /api/order） 对应一个 ClusterNode。
• 它继承自 StatisticNode，因此天然具备统计能力：
  • QPS（通过/拒绝）
  • 平均响应时间（RT）
  • 当前线程数
  • 异常数等

特点

// 同一个 resource name，全局只有一个 ClusterNode
// 不管你是在 Context A 还是 Context B 中调用 /api/order，
// 所有流量都会汇总到这一个 ClusterNode 上

💡 类比 ：

如果把每个 Context 看作一个"部门"，那么 ClusterNode 就是公司层面的"总报表"，汇总所有部门对某个接口的调用情况。

---

🧩 二、为什么需要 originCountMap？

背景：区分调用来源（Origin）

Sentinel 支持通过 ContextUtil.enter(resourceName, origin) 指定调用方身份，例如：

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

需求

• 虽然总 QPS 要控制，但 不同调用方可能需要不同的限流策略 。
  • 比如：user-service 最多 100 QPS，admin-service 最多 10 QPS。
• 因此，除了全局统计，还要 按 origin 分别统计。

解决方案：originCountMap

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

• Key：origin（调用方标识，通常是应用名）
• Value：该 origin 专属的 StatisticNode，只统计来自这个 origin 的请求

✅ 效果：

• ClusterNode 自身 → 统计 所有 origin 的总和
• originCountMap.get("user-service") → 只统计 user-service 的流量

---

🔒 三、线程安全设计：为什么用 ReentrantLock 而不是 ConcurrentHashMap？

这是代码中的一个经典注释亮点：

// 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	天然线程安全	每次 get/put 都有锁开销（虽然分段，但仍存在）
HashMap + ReentrantLock	读多写少场景下性能更高	写时需加锁

为什么合理？

• origin 数量有限：通常只有几个到几十个调用方（如 user-service, order-service...）
• 初始化后基本不变：应用启动后，新的 origin 很少出现
• 读远多于写 ：99% 的时间都在 get(origin)，只有首次调用某个 origin 时才需要 put

✅ 结论 ：用"写时复制 + 锁"策略，在保证线程安全的同时，最大化读性能 ，是典型的 "为稳定状态优化" 的工程设计。

写时复制（Copy-on-Write）实现

lock.lock();
try {
    // double-check
    if (originCountMap.get(origin) == null) {
        StatisticNode newNode = new StatisticNode();
        // 创建新 map，复制旧数据 + 新 entry
        HashMap<String, StatisticNode> newMap = new HashMap<>(originCountMap.size() + 1);
        newMap.putAll(originCountMap);
        newMap.put(origin, newNode);
        originCountMap = newMap; // 原子引用替换
    }
} finally {
    lock.unlock();
}

• 保证 originCountMap 引用始终是 不可变的（immutable）
• 读操作无需加锁，直接访问 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 内部如何工作？

1. 请求进入时，ContextUtil.enter("/order", "user-app")
2. ClusterNode clusterNode = ... （获取全局节点）
3. Node originNode = clusterNode.getOrCreateOriginNode("user-app")
4. 流控检查时：
   • 如果规则指定了 limitApp="user-app" → 检查 originNode 的 QPS
   • 否则 → 检查 clusterNode 的总 QPS

---

🧠 五、总结：ClusterNode 的核心价值

维度	说明
全局聚合	所有 Context 中对同一资源的调用，统一统计
来源隔离	按 origin（调用方）细分流量，支持精细化管控
高性能读	读操作无锁，写操作极少发生，适合高并发场景
扩展基础	为"黑白名单"、"来源限流"、"来源熔断"等高级功能提供数据支撑

💡 一句话理解 ：
ClusterNode 是 Sentinel 实现"全局资源视图 + 多租户（origin）隔离统计"的基石。

它让系统既能看到"森林"（总流量），也能看清"每棵树"（各调用方流量），从而做出更智能的流控决策。

这种设计体现了 "统一管理、精细控制" 的分布式系统治理思想，是 Sentinel 能广泛应用于微服务场景的关键之一。