Sentinel 实验
Sentinel 实验
通过观察 Sentinel 的日志输出，大概能看懂 Sentinel 的工作模式。
1 | java -Dserver.port=8090 -Dlogging.level.org.springframework.web=TRACE -jar `sentinel`-dashboard-1.8.1.jar |
Sentinel 控制台和 Sentinel 客户端都启动以后，双方并不会直接就互相感知到。
只有等到 Sentinel 客户端访问了端点后，Sentinel 客户端才会开始向 Sentinel 控制台发送心跳，此时双方才互相感知到。
随后，Sentinel 控制台会定期向 Sentinel 客户端发送请求，获取客户端的运行信息，从而实现监控。
当在 Sentinel 控制台为客户端的相关资源配置规则时，规则信息会发送到对应的 Sentinel 客户端。
默认情况下，Sentinel 客户端接收到配置规则信息以后，是将其存储在内存中。
因此，如果 Sentinel 客户端重启了，那么所有的配置规则都将丢失。
即使 Sentinel 客户端重新连接，也无法从 Sentinel 控制台中获取之前配置的流控规则，Sentinel 控制台本身不提供这样的功能。
当 Sentinel 客户端意外下线后，Sentinel 控制台会继续尝试发送请求，尝试获取数据实现监控，尝试 8 次后，获取不到即停止继续请求。
无论 Sentinel 客户端在控制台的 8 次请求期间内重启，还是控制台停止请求后才重启，重启后客户端并不能被 Sentinel 控制台感知到。Sentinel 客户端必须重新访问端点，触发心跳机制后，才能与 Sentinel 控制台重新恢复通信。
当 Sentinel 控制台下线后，Sentinel 客户端本身保存的规则不会失效，客户端仍然可以正常完成流控，熔断等操作。Sentinel 客户端发现发送心跳得不到控制台响应后，还会一直保持发送，这样当 Sentinel 控制台恢复上线以后，就能立刻接收到 Sentinel 客户端的心跳信息，从而感知到 Sentinel 客户端，并且可以从 Sentinel 客户端获取到簇点以及规则等信息。
对于 Sentinel 客户端，只有相应的端点被访问到了，才会显示相应的簇点链路。
假设存在两个 Controller 方法，如 /order/query 和 /order/update，当只访问了 /order/query 时，在 Sentinel 控制台将只会看到 /order/query 的簇点链路信息。
对于同一个服务，比如 order-service 订单服务，我启动了多个实例（实例 A 和实例 B），也即存在同一个订单服务的多个 Sentinel 客户端。
此时进入到控制台，配置实例 A 的流控规则，规定 /order/query 的 qps 阈值为 5，此时压测实例 A 的 /order/query 接口可以触发限流，但压测实例 B 的 /order/query 接口不会触发限流。
这说明，Sentinel 控制台上配置的规则，其实是针对单个实例的。
如果希望做到针对一个服务集群内的多个实例来实现规则配置，一般是让 Sentinel 控制台将配置规则先推送到 Nacos 这样的配置中心，然后让集群内的 Sentinel 客户端启动时从 Nacos 拉取配置，从而实现规则配置可以对多实例生效，且实例也可以持续监听 Nacos 配置变化实现热更新。
关于使用流控模式中的链路模式，为什么需要设置 web-context-unify: false 来关闭 web context 整合？
链路模式中需要配置一个叫入口资源的东西，这里其实就是配置某条链路的链路名。
如果不关闭 web context 整合，/order/query 和 /order/save 这些 Controller 方法都会被整合到一个名为 sentinel_spring_web_context 的链路中，作为其两个子链路分支存在。
此时，链路模式中的入口资源就不认识 /order/query，它只认识 sentinel_spring_web_context，这样就无法根据不同的 Controller 方法做来源的链路流控了。
关闭 web context 整合以后，/order/query 和 /order/save 这些 Controller 方法，每个都将作为一条独立的链路存在，且链路名就是 /order/query 和 /order/save，这样就可以进行链路模式的流控了。
Sentinel 规则持久化 Pull 模式。
一般来说，如果规则信息是做文件持久化，或者存放到数据库，由于文件和数据库不像 Nacos 这样配置中心，数据发生变更后会发出通知，因此需要定期扫描文件，或者轮询数据库来确定文件是否发生了变更，这也即 Pull 模式。