解锁 ElasticJob 云原生实践的难题

本文介绍: 最近在逛 ElasticJob 官方社区时发现很多小伙伴都在头疼这个 ElasticJob 上云的问题，ElasticJob 本就号称分布式弹性任务调度框架，怎么在云原生环境就有了问题了呢，这就要从 Kubenert es 和 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 中的接口级服务配置，Shar d in gSphere-ElasticJob 的有状态 Server IP 节点等等，这种对 IP 做了有状态操作的框架或者中间件在云原生环境频繁变更 IP 的场景下很容易产生大量无意义的脏数据存储，对注册中心或者存储都带来了无意义的压力。

ElasticJob 中的有状态 IP

Shar d in gSphere-ElasticJob 是一个分布式任务调度框架，它由当当网基于 Quartz 二次开发，功能丰富强大，采用 Zookeeper 实现分布式协调，可实现任务高可用以及分片。Shar d in gSphere-ElasticJob 已于 2020 年 5 月 28 日成为 Apache Shar dingSphere 的子项目。

具体如何使用可以查阅官网，相关原理也可以查阅《中间件源码》公众号中对 Shar dingSphere-ElasticJob 分析的文章。

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

instance 目录：一个位置是位于注册中心 instance 目录下的临时节点，这个节点包含了 IP+进程信息，借助此目录下的节点可以有效的实现分片逻辑。节点存在意味着进程存在，节点不存在意味着进程不存在。

server 目录：另外一个位置是位于注册中心 server 目录下的持久 IP 节点，这个 IP 节点是用来存储当前 IP 实例的状态的，比如当前实例是否处于禁用状态，有问题的就是这个持久的，有状态的节点，在无状态的容器环境下随着容器发布次数增多这个 IP 节点也会越来越多，注册中心无意义的脏数据也会越来越多，对注册中心的压力也会呈线性增长，这就是社区用户遇到的头疼的问题。

解决方案

既然 ShardingSphere-ElasticJob 要上容器支持云原生环境下的无状态的业务，那我们就把 ShardingSphere-ElasticJob 有状态的 IP 变成无状态，比较优雅且彻底的方式就是废弃掉持久化 IP 这个有状态的功能让 ShardingSphere-ElasticJob 彻底变成无状态的定时调度，但是考虑到部署在物理机或者虚拟机环境下现存的分布式定时调度业务可能已经使用到了此状态功能，对于已经使用到此状态 IP 的节点暂不做处理直接跳过，针对已经下线的 IP 节点则直接删除即可。