微服务轮子项目（18） -Alibaba Sentinel限流熔断（生产应用）

1. 前言

在上一篇博客《微服务轮子项目（17） -Alibaba Sentinel限流熔断（动态规则扩展）》，主要讲解了Sentinel的推拉配置。

Sentinel核心库目前已可用于生产环境，目前除了阿里巴巴以外，也有多家企业在生产环境中使用它们。

生产环境的 Sentinel Dashboard 需要具备下面几个特性:

• 规则管理及推送，集中管理和推送规则。sentinel-core提供 API 和扩展接口来接收信息。开发者需要根据自己的环境，选取一个可靠的推送规则方式；同时，规则最好在控制台中集中管理。
• 监控，支持可靠、快速的实时监控和历史监控数据查询。sentinel-core记录秒级的资源运行情况，并且提供 API 来拉取资源运行信息。当机器大于一台以上的时候，可以通过 Dashboard 来拉取，聚合，并且存储这些信息。这个时候，Dashboard 需要有一个存储媒介，来存储历史运行情况。
• 鉴权，区分用户角色，来进行操作。生产环境下的权限控制是非常重要的，理论上只有管理员等高级用户才有权限去修改应用的规则。
  由于开发者有各自不一样的环境和需求，我们会对“规则管理和推送”，“监控”这两个方面给出建议以及最佳实践；对于鉴权，由于每个开发者的环境都不一样，我们在最佳实践中仅仅使用了简单的认证。开发者可以依循自己的需求，生产环境，选择最适合自己的方式。

2. 规则管理及推送

一般来说，规则的推送有下面三种模式:

2.1 原始模式

如果不做任何修改，Dashboard的推送规则方式是通过 API 将规则推送至客户端并直接更新到内存中。

这种做法的好处是简单，无依赖；坏处是应用重启规则就会消失，仅用于简单测试，不能用于生产环境。

2.2 Pull模式

pull 模式的数据源（如本地文件、RDBMS 等）一般是可写入的。使用时需要在客户端注册数据源：将对应的读数据源注册至对应的 RuleManager，将写数据源注册至 transport 的WritableDataSourceRegistry中。以本地文件数据源为例：

public class FileDataSourceInit implements InitFunc {
    @Override
    public void init() throws Exception {
        String flowRulePath = "xxx";
        ReadableDataSource<String, List<FlowRule>> ds = new FileRefreshableDataSource<>(
            flowRulePath, source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {})
        );
        // 将可读数据源注册至 FlowRuleManager.
        FlowRuleManager.register2Property(ds.getProperty());
        WritableDataSource<List<FlowRule>> wds = new FileWritableDataSource<>(flowRulePath, this::encodeJson);
        // 将可写数据源注册至 transport 模块的 WritableDataSourceRegistry 中.
        // 这样收到控制台推送的规则时，Sentinel 会先更新到内存，然后将规则写入到文件中.
        WritableDataSourceRegistry.registerFlowDataSource(wds);
    }
    private <T> String encodeJson(T t) {
        return JSON.toJSONString(t);
    }
}

本地文件数据源会定时轮询文件的变更，读取规则。这样我们既可以在应用本地直接修改文件来更新规则，也可以通过 Sentinel控制台推送规则。

过程：

• 首先 Sentinel 控制台通过 API 将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则保存到本地的文件中。使用 pull 模式的数据源时一般不需要对 Sentinel 控制台进行改造。

这种实现方法好处是简单，不引入新的依赖，坏处是无法保证监控数据的一致性

2.3 Push模式

生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了：

我们提供了 ZooKeeper, Apollo, Nacos 等的动态数据源实现。以ZooKeeper为例子，如果要使用第三方的配置中心作为配置管理，您需要做下面的几件事情:

1. 实现一个公共的ZooKeeper 客户端用于推送规则，在Sentinel控制台配置项中需要指定 ZooKeeper 的地址，启动时即创建ZooKeeper Client。
2. 我们需要针对每个应用（appName），每种规则设置不同的path（可随时修改）；或者约定大于配置（如 path的模式统一为/sentinel_rules/{appName}/{ruleType}，e.g.sentinel_rules/appA/flowRule）。
3. 规则配置页需要进行相应的改造，直接针对应用维度进行规则配置；修改同个应用多个资源的规则时可以批量进行推送，也可以分别推送。Sentinel 控制台将规则缓存在内存中（如InMemFlowRuleStore），可以对其进行改造使其支持应用维度的规则缓存（key 为 appName），每次添加/修改/删除规则都先更新内存中的规则缓存，然后需要推送的时候从规则缓存中获取全量规则，然后通过上面实现的 Client 将规则推送到 ZooKeeper 即可。
4. 应用客户端需要注册对应的读数据源以监听变更。

从 Sentinel 1.4.0 开始，Sentinel 控制台提供DynamicRulePublisher和DynamicRuleProvider接口用于实现应用维度的规则推送和拉取，并提供了相关的示例。Sentinel 提供应用维度规则推送的示例页面（/v2/flow），用户改造控制台对接配置中心后可直接通过 v2 页面推送规则至配置中心。改造详情可参考应用维度规则推送示例。

3. 监控

Sentinel会记录资源访问的秒级数据（若没有访问则不进行记录）并保存在本地日志中，具体格式请见秒级监控日志文档。Sentinel 控制台可以通过Sentinel客户端预留的 HTTP API从秒级监控日志中拉取监控数据，并进行聚合。

目前 Sentinel控制台中监控数据聚合后直接存在内存中，未进行持久化，且仅保留最近 5 分钟的监控数据。若需要监控数据持久化的功能，可以自行扩展实现MetricsRepository接口（0.2.0 版本），然后注册成 Spring Bean 并在相应位置通过@Qualifier注解指定对应的bean name 即可。MetricsRepository接口定义了以下功能：

• save与saveAll：存储对应的监控数据
• queryByAppAndResourceBetween：查询某段时间内的某个应用的某个资源的监控数据
• listResourcesOfApp：查询某个应用下的所有资源

其中默认的监控数据类型为MetricEntity，包含应用名称、时间戳、资源名称、异常数、请求通过数、请求拒绝数、平均响应时间等信息。

同时用户可以自行进行扩展，适配 Grafana 等可视化平台，以便将监控数据更好地进行可视化。

对于监控数据的存储，用户需要根据自己的存储精度，来考虑如何存储这些监控数据。

4. 其它

Awesome Sentinel里记录非常多的社区用户的一些扩展和解决方案，也欢迎大家将一些比较好的扩展实现添加进来。