毋庸置疑xxl-job 是一款非常优秀的 分布式任务调度组件，帮助我们解决了K8S Cronjob 调度 中的一些问题，类如：
频繁创建 pod 导致节点上 cgroup 过多，memory cgroup 不能及时回收 导致Node 节点稳定性不够

优美的代码及设计 让我很快了解整个 xxl-job 的架构设计，这里我需要提醒一下，目前流行的各种组件都是向云原生靠拢，而当前的xxl-job 在这方面确实是不足的，比如存在一下我罗列的一些问题点：

1. 代码上线的过程中基于 K8S 可能会进行 蓝绿 切换 或 滚动 切换， 但这种平滑切换的机制 和 xxl-job 结合 会导致 任务会存在一些重复执行的 case (这种情况 下 一致性HASH 路由策略会时效)。
2. HPA自动扩缩容， 这种情况下也可能会导致任务的重复执行

当然上面两个 严格的 任务重复执行这种 问题 或许 更希望通过 在执行任务中 业务自己去控制 ，但我认为基于 框架层面确实 可以 做到更加开放的 理念设计，比如

路由策略、阻塞处理策略、调度任务过期策略 等策略机制类的功能， 可以 基于 SPI 机制 去设计， 比我 想做的一件事就是 实现通用 的分布式锁， 但是基于当前 xxl-job 的实现 做这个事情 其实并不容易， 而 如果 是 SPI 的模式 则 可以 快速 集成 ETCD | Redis | ZK 等组件的分布式锁。

我上述 所说的只是 策略 方面 基于 SPI 实现的 好处 的一个举例 ，我相信如果基于这 层片继续抽象，会有更多的可拓展性。