自去年10月底发布GA版本后，Sentinel在近期发布了另一个里程碑版本v1.4（最新的版本号是v1.4.1），加入了开发者关注的集群流控功能。
集群流控简介
为什么要使用集群流控呢？假设我们希望给某个用户限制调用某个 API 的总 QPS 为 50，但机器数可能很多（比如有 100 台）。这时候我们很自然地就想到，找一个 server 来专门来统计总的调用量，其它的实例都与这台 server 通信来判断是否可以调用。这就是最基础的集群流控的方式。
那么这个 server 如何部署呢？最直观的方式就是作为独立的 token server 进程启动，独立部署：
另一种就是嵌入模式（Embedded），即作为内置的 token server 与服务在同一进程中启动，无需单独部署：
另外集群流控还可以解决流量不均匀导致总体限流效果不佳的问题。假设集群中有 10 台机器，我们给每台机器设置单机限流阈值为 10 QPS，理想情况下整个集群的限流阈值就为 100 QPS。不过实际情况下流量到每台机器可能会不均匀，会导致总量没有到的情况下某些机器就开始限流：
因此仅靠单机维度去限制的话会无法精确地限制总体流量。而集群流控可以精确地控制整个集群的调用总量，结合单机限流兜底，可以更好地发挥流量控制的效果。
Sentinel 1.4.0 开始引入了集群流控模块，主要分为两个部分：Token Client 和 Token Server：
- Token Client 即集群流控客户端，用于向所属 Token Server 通信请求 token。集群限流服务端会返回给客户端结果，决定是否限流。Sentinel 集群流控的通信底层采用 Netty 实现。
- Token Server 即集群流控服务端，处理来自 Token Client 的请求，根据配置的集群规则判断是否应该发放 token（是否允许通过）。
Sentinel 集群流控支持限流规则和热点规则两种规则。集群流控支持两种形式的阈值计算方式：
- 集群总体模式：即限制整个集群内的某个资源的总体 QPS 不超过此阈值。
- 单机均摊模式：单机均摊模式下配置的阈值等同于单机能够承受的限额，Token Server 会根据连接数来计算总的阈值（比如独立模式下有 3 个 client 连接到了 token server，然后配的单机均摊阈值为 10，则计算出的集群总量就为 30），按照计算出的总的阈值来进行限制。这种方式根据当前的连接数实时计算总的阈值，对于机器经常进行变更的环境非常适合。
部署方式
Sentinel 集群流控服务端支持独立模式（Alone）以及嵌入模式（Embedded）。两者的优缺点对比：
- 独立模式作为独立的 token server 进程启动，独立部署，隔离性好，但是需要额外的部署操作。独立模式适合作为 Global Rate Limiter 给整个集群提供流控服务。
- 嵌入模式作为内置的 token server 嵌入到应用进程中。嵌入模式下集群中各个实例都是对等的，token server 和 client 可以随时进行转变，无需单独部署，灵活性比较好。但缺点就是隔离性不佳，
需要限制 token server 的总 QPS，防止影响应用本身。嵌入模式适合某个应用集群内部的流控。
Sentinel 提供 API 来对 client / server 进行配置以及指定模式，但是机器多的时候不方便进行管理。一般我们需要通过 Sentinel 控制台的集群流控管理功能来统一管理某个应用集群下所有的 token server 和 token client，灵活进行分配。
配置
配置是集群流控中比较重要的一部分。Sentinel 集群流控的配置主要包含几部分：
集群规则配置
集群规则配置需要借助动态规则源。以集群流控规则为例，对于客户端，我们可以用之前的方式向FlowRuleManager 注册动态规则源。而对于 Token Server，我们需要向集群规则管理器 ClusterFlowRuleManager 注册规则源。我们推荐的方式是在应用端注册动态规则源，然后在 Sentinel 控制台直接推送规则到配置中心，即 push 模式：
Token Server / Client 的分配
以嵌入模式为例，一个比较好的实践是：结合流量分布和实时负载情况来在服务集群中选取几台较为空闲的机器作为 Token Server，其它的机器作为 Token Client，划分成几组，分别归属各自的 Token Server 管理。最后组成一个映射表，类似于：
// ip: token server IP, port: token server port, clientSet: 所管辖的 token client 集合
[{"clientSet":["[email protected]","[email protected]"],"ip":"112.12.88.68","machineId":"[email protected]","port":11111}]
然后像 Token Client / Token Server 通信配置、集群流控模式等配置源都可以监听这个分配映射表对应的数据源，来解析自己的身份和相关通信配置。当分配映射表变更时每台机器对应的身份和配置也会实时变更，实时生效。Sentinel 1.4.1 改进了 Sentinel 控制台集群流控的管理页面，可以直接以应用维度来分配 Token Server。可以参考本文后面的指引来使用。
其它配置
其它的配置比如 Token Server 的命名空间集合（namespace set，用于指定该 Token Server 可以为哪些应用/分组服务）、最大允许的总 QPS 等，既可以通过 Sentinel 预留的 HTTP API 来变更配置，也可以通过注册动态配置源来进行配置。
快速使用集群流控
下面我们来看一下如何快速使用集群流控功能。接入集群流控模块的步骤如下：
（1）引入集群流控依赖
这里我们以嵌入模式来运行 token server，即在应用集群中指定某台机器作为 token server，其它的机器指定为 token client。
首先我们引入集群流控相关依赖：
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-cluster-client-default</artifactId>
<version>1.4.1</version>
</dependency>
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-cluster-server-default</artifactId>
<version>1.4.1</version>
</dependency>（2）配置动态规则源
要想使用集群流控功能，我们需要在应用端配置动态规则源，并通过 Sentinel 控制台实时进行推送。流程如下所示：
以流控规则为例，假设我们使用 ZooKeeper 作为配置中心，则可以向客户端 FlowRuleManager 注册 ZooKeeper 动态规则源：
ReadableDataSource<String, List<FlowRule>> flowRuleDataSource = new ZookeeperDataSource<>(remoteAddress, path, source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {}));
FlowRuleManager.register2Property(flowRuleDataSource.getProperty());另外我们还需要针对 Token Server 注册集群规则数据源。由于嵌入模式下 token server 和 client 可以随时变换，因此我们只需在每个实例都向集群流控规则管理器 ClusterFlowRuleManager 注册动态规则源即可。Token Server 抽象出了命名空间（namespace）的概念，可以支持多个应用/服务，因此我们需要注册一个自动根据 namespace 创建动态规则源的生成器:
// Supplier 会根据 namespace 生成的动态规则源，类型为 SentinelProperty<List<FlowRule>>，针对不同的 namespace 生成不同的规则源（监听不同 namespace 的 path）.
// 默认 namespace 为应用名（project.name）
// ClusterFlowRuleManager 针对集群限流规则，ClusterParamFlowRuleManager 针对集群热点规则，配置方式类似
ClusterFlowRuleManager.setPropertySupplier(namespace -> {
return new SomeDataSource(address, dataIdPrefix + namespace).getProperty();
});（3）控制台进行改造适配动态规则源
我们只需简单对 Sentinel 控制台进行改造即可直接将流控规则推送至配置中心。从 Sentinel 1.4.0 开始，Sentinel 控制台提供 DynamicRulePublisher 和 DynamicRuleProvider 接口用于实现应用维度的规则推送和拉取，并提供了 Nacos 推送的示例（位于 test 目录下）。我们只需要实现自己的 DynamicRulePublisher 和 DynamicRuleProvider 接口并在 FlowControllerV2 类中相应位置通过 @Qualifier 注解指定对应的 bean name 即可，类似于：
@Autowired
@Qualifier("flowRuleNacosProvider")
private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider;
@Autowired
@Qualifier("flowRuleNacosPublisher")
private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;Sentinel 控制台提供应用维度推送的页面（/v2/flow）。在上述配置完成后，我们可以在此页面向配置中心推送规则：
（4）控制台分配 Token Server
当上面的步骤都完成后，我们就可以在 Sentinel 控制台的“集群流控” Token Server 列表页面管理分配 token server 了。假设我们启动了三个应用实例，我们选择一个实例为 token server，其它两个为 token client：
页面上机器的显示方式为 [email protected]，其中 commandPort 为应用端暴露给 Sentinel 控制台的端口。选择好以后，点击 保存 按钮，刷新页面即可以看到 token server 分配成功：
并且我们可以在页面查看 token server 的连接情况：
（5）配置规则，观察效果
接下来我们配置一条集群限流规则，限制 com.alibaba.csp.sentinel.demo.cluster.app.service.DemoService:sayHello(java.lang.String) 资源的集群总 QPS 为 10，选中“是否集群”选项，阈值模式选择总体阈值：
模拟流量同时请求这三台机器，过一段时间后观察效果。可以在监控页面看到对应资源的集群维度的总 QPS 稳定在 10：
总结
集群流控能够精确地控制整个集群的 QPS，结合单机限流兜底，可以更好地发挥流量控制的效果。还有更多的场景等待大家发掘，比如：
- 在 API Gateway 处统计某个 API 的总访问量，并对某个 API 或服务的总 QPS 进行限制
- Service Mesh 中对服务间的调用进行全局流控
- 集群内对热点商品的总访问频次进行限制
尽管集群流控比较好用，但它不是万能的，只有在确实有必要的场景下才推荐使用集群流控。
另外若在生产环境使用集群限流，管控端还需要关注以下的问题：
- Token Server 自动管理（分配/选举 Token Server）
- Token Server 高可用，在某个 server 不可用时自动 failover 到其它机器
未来我们还计划实现集群流控多语言版本的客户端，并对接 Service Mesh，让 Sentinel 集群流控可以在更多场景下使用。
原文地址：https://www.cnblogs.com/zhaowei121/p/10272468.html