解锁 ElasticJob 云原生实践的难题

发生了什么

最近在逛 ElasticJob 在官方社区，我发现很多朋友都头疼 ElasticJob 上云的问题，ElasticJob 被称为分布式弹性任务调度框架，如何在云原始环境中出现问题，这将从 Kubenertes 和 ElasticJob 从一些状态化开始。

在了解两者的特征之前，我们可以先看看什么是状态。

先来看百科的介绍:

“状态是人或事的形式。它是指现实（或虚拟）事物在生成、生存、发展、消亡或转化临界点时的形式或情况。”

如果指 人的形态：

• 它可以包括情绪、思想、行为和生理状态，比如某人最近的状态不好。

如果指 事物的形式：

• 例如，当系统的温度、压力、体积、物理状态、物质量、相、各种能量等时，我们说系统处于同一状态（state)。

状态这个词对开发者来说并不陌生，比如:

• 前端 UI 组件的状态存储。
• 软件工程中的状态图。
• 过程的运行状态。
• 再到云原生 Kubernetes 中提到的无状态服务（Stateless Service）与普通有状态服务（Stateful Service）等等。

在 Kubernetes 中， 无状态 和 有状态 是指应用于容器运行时的数据持久性需求。

无状态应用

这意味着数据不会在容器中连续存储，应用容器可以随意创建和销毁。对于无状态应用程序，请求转发给任何容器实例都可以正确运行。例如，web 应用是一种无状态应用。

有状态应用

它是指在容器中运行时需要稳定的持久存储、稳定的网络标志、固定的 pod 启动和停止顺序。这些应用程序需要在不同的节点之间保持数据同步，并在节点故障时快速恢复。例如，数据库、缓存等都是状态应用程序。

可以看出，对于大多数人来说 计算型 (业务型) ，建议使用非存储应用程序 无状态 这种模式可以随意创建（扩展）、销毁（缩减）操作。由于大多数业务系统使用这种无状态容器，这意味着容器的网络和存储总是在每次销毁和创建的发布周期中发生变化。简单来说就是容器 IP 每次发布时 总会创造新的 IP。

容器 IP 每次创建时如何产生一个新的？ IP 是的，这个原理可以研究一下 Kubernetes 的虚拟 IP 这里重点介绍一下这个的产生 IP 在传统的物理机和虚拟机下部署服务带来的变化问题 IP 它通常由操作和维护统一控制和分配，即使用相同的应用程序 IP 相对固定往往不会发生大规模变化，然而，在云原生环境中，当无状态容器快速频繁扩缩时，使用哪些服务？ IP 通常不会固定每一个变化总会有一个新的 IP 的使用。

每次 IP 变化是一种无状态的模式本身没有问题，但问题是许多现有的框架或中间件在开发阶段没有遇到或考虑到，因为它们很早就产生了 IP 在频繁变化的帮助下，经常使用频繁变化的场景 IP 有状态处理，如 Dubbo2 接口级服务配置，ShardingSphere-ElasticJob 的有状态 Server IP 节点等等，这是对的 IP 有状态操作的框架或中间件在云原生环境中频繁变化 IP 在这种情况下，很容易产生大量无意义的脏数据存储，给注册中心或存储带来无意义的压力。

ShardingSphere-ElasticJob 以当当网为基础的分布式任务调度框架 Quartz 二次开发功能丰富强大，采用 Zookeeper 分布式协调可以实现高任务和分片。ShardingSphere-ElasticJob 已于 2020 年 5 月 28 日成为 Apache ShardingSphere 的子项目。

如何使用可以查阅官网，相关原理也可以查阅微信官方账号中的中间件源码 ShardingSphere-ElasticJob 文章的分析。

在 ShardingSphere-ElasticJob 默认注册中心采用分布式协调中间件 Zookeeper,对 IP 处理有两个位置：

• instance 目录： 位于注册中心的位置 instance 该节点包含了目录中的临时节点 IP+在此目录下的节点的帮助下，进程信息可以有效地实现分片逻辑。节点的存在意味着过程的存在，节点的存在意味着过程的存在。
• server 目录： 另一个位置是注册中心 server 持久的目录 IP 节点，这个 IP 用于存储当前存储的节点 IP 例子的状态，例如当前例子是否被禁用， 有问题的是，在无状态容器环境下，随着容器发布次数的增加，这个持久的、有状态的节点会出现 IP 会有越来越多的节点，注册中心会有越来越多毫无意义的脏数据，对注册中心的压力会线性增加，这是社区用户头疼的问题。

既然 ShardingSphere-ElasticJob 如果我们想去容器支持云原生环境下的无状态业务，那么我们就把它放在一边 ShardingSphere-ElasticJob 有状态的 IP 变成无状态，更优雅、更彻底的方法是废弃持久性 IP 这种有状态的功能让 ShardingSphere-ElasticJob 它已经完全成为一个无状态的定时调度，但考虑到现有的分布式定时调度业务部署在物理机器或虚拟机环境中可能已经使用了这个状态功能，并且已经使用了这个状态 IP 暂时不做节点处理直接跳过，针对已下线的 IP 直接删除节点。

感兴趣的朋友可以查看以下代码和 PR 当然，如果有问题，可以继续反馈。

相关 PR 如下所示(需复制打开)：

https://github.com/apache/shardingsphere-elasticjob/pull/2251

关注微信微信官方账号 “中间件源码” 订阅更多内容。