Sentinel 控制台 需要具备下面几个特性:
- 规则管理及推送，集中管理和推送规则。sentinel-core 提供 API 和扩展接口来接收信息。开发者需要根据自己的环境，选取一个可靠的推送规则方式；同时，规则最好在控制台中集中管理。
- 监控，支持可靠、快速的实时监控和历史监控数据查询。sentinel-core 记录秒级的资源运行情况，并且提供 API 来拉取资源运行信息。当机器大于一台以上的时候，可以通过 Dashboard 来拉取，聚合，并且存储这些信息。这个时候，Dashboard 需要有一个存储媒介，来存储历史运行情况。
- 鉴权，区分用户角色，来进行操作。生产环境下的权限控制是非常重要的，理论上只有管理员等高级用户才有权限去修改应用的规则。
对于规则管理及推送，规则的推送有三种模式：
原始模式：API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDataSource）
这种模式简单，无任何依赖。但是不保证一致性；规则保存在内存中，重启即消失。所以不适用与生产环境，我们需要实现规则的持久话。Sentinel给我们提供了两种持久化方法，就是规则的另外两种推送模式。
Pull 模式：扩展写数据源（WritableDataSource）， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等。优点是简单，无任何依赖；规则持久化。缺点是不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。
Push 模式：扩展读数据源（ReadableDataSource），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。优点是规则持久化；一致性；快速。缺点是引入了第三方依赖。