拥抱Kubernetes,再见了,SpringBoot @Scheduled

项目开发中老是须要执行一些定时任务，好比定时处理数据以后发送邮件，定时更新缓存等等。

Java定时任务

1. 基于 java.util.Timer 定时器，实现相似闹钟的定时任务
2. 使用 Quartz、elastic-job、xxl-job 等开源第三方定时任务框架，适合分布式项目应用
3. 使用 Spring 提供的一个注解： @Scheduled

项目框架使用的是SpringBoot,因此以前定时任务使用的是SpringBoot中的@Scheduled。但是这种方式并不适合咱们如今的cloud环境，为了更加cloud native一点,我删除了使用SpringBoot写的37个定时任务，改成使用Kubernetes cronjob的方式。

定时任务代码编写

public interface Command {
 /**  * 遵循Unix约定，若是命令执行正常，则返回0；不然为非0。  */  int execute(String... args); }  复制代码

首先定义一个接口，全部具体的定时任务都必须实现该接口。接下来是具体的某一个定时任务

@Component
@Slf4j public class ProjectCommandLineRunner implements CommandLineRunner {   Map<String, Command> commandMap = new HashMap<>();   @Autowired  private SendEmailCommand sendEmailCommand;   @PostConstruct  private void init() {  commandMap.put("sendEmail", sendEmailCommand);  }   @Override  public void run(String... args) throws Exception {   if (args.length == 0) {  return;  }   if (!commandMap.containsKey(args[0])) {  log.error("'{}' command not found", args[0]);  System.exit(-1);  }   Command command = commandMap.get(args[0]);   String[] arguments = Arrays.copyOfRange(args, 1, args.length);   System.exit(command.execute(arguments));  } }  @Component @Slf4j public class SendEmailCommand implements Command {   @Override  public int execute(String... args) {   try {  // 省略业务逻辑代码   log.info("send email success");   return 0;   } catch (Exception e) {  log.error("send email error", e);  return -1;  }  } }  复制代码

上面的代码咱们采用了策略模式，后面即便新增其余定时任务也只是会改动不多的代码。

本地调试

cronjob不用打包成单独的镜像，它直接和咱们的web应用公用同一个镜像,本地调试的时候也是极为方便的,只须要咱们启动SpringBoot Application时指定参数便可

调试定时任务

对应的定时任务执行完成以后就会，application就会退出。

cronjob yaml

一个基本的cronjob yaml以下所示

apiVersion: batch/v1beta1
kind: CronJob metadata:  name: send-email-job spec:  failedJobsHistoryLimit: 3  successfulJobsHistoryLimit: 1  startingDeadlineSeconds: 180  concurrencyPolicy: Forbid  schedule: "0 4 * * 1-5"  jobTemplate:  spec:  template:  spec:  containers:  - name: send-email-job  image: harbor.xxx.com/think123/project  imagePullPolicy: Always  command: ["java"]  args: ["-jar","/app/target/think123-task.jar","sendEmail"]  envFrom:  - configMapRef:  name: smcp-config  - secretRef:  name: smcp-service-secret  resources:  requests:  cpu: "250m"  memory: 1024Mi  limits:  cpu: "500m"  memory: 1024Mi  restartPolicy: Never  复制代码

在定时任务中,可能某个job尚未执行完，另一个job就产生了。这个时候咱们能够经过spec.concurrencyPolicy字段来定义具体的处理策略。

1. concurrencyPolicy=Allow，这也是默认状况，这意味着这些Job能够同时存在；
2. concurrencyPolicy=Forbid，这意味着不会建立新的Pod，该建立周期被跳过；
3. concurrencyPolicy=Replace，这意味着新产生的Job会替换旧的、没有执行完的Job

几个关键参数解释以下:

1. schedule : Unix Cron格式的表达式，cron表达式中的五个部分分别表明：分钟、小时、日、月、星期。
2. startingDeadlineSeconds ： 表示在过去的多少秒(这里设置的180)里，若是job建立失败的数据达到了100次，那么这个job就不会被建立执行了。
3. restartPolicy: 重启策略(有Never和OnFailure两个选项)。当job正常结束以后是否须要重启

restartPolicy在Job对象里只容许被设置为Never和OnFailure；而在Deployment对象里，restartPolicy则只容许被设置为Always。

实际上在jobTemplate.spec.template中能够像pod中那样，指定volume,指定nodeSelector，都是能够的。这个template实际上就是指的pod的template。好比上面示例咱们就指定了环境变量，咱们的一些参数就能够经过环境变量进行注入，好比redis地址，mongodb用户名密码等。

实际使用

上面的yaml虽然能够直接使用，可是咱们用不着每一个job都去写一份一样的模板，实际中咱们会使用Kustomize控制模板来生成job。好比咱们有一个新的任务，是计算热点文章并更新redis

对于这个任务而言，变化的主要有两个地方，第一个是定时任务的时间不一样，第二个是指定的参数不一样。因此咱们的每一个任务只须要更新这两个参数就好了

关于kustomize的使用能够参考我以前的kustomize的介绍,打包的话能够看看springboot build的文章

对于模板设定，咱们造成了下面的目录结构

$ tree
. |-- base | |-- cronjob.yaml | `-- kustomization.yaml `-- overlay  `-- beta  |-- kustomization.yaml  `-- send-email-patch-args.yaml  复制代码

cronjob.yaml做为全部job的模板,而send-emial-patch-args.yaml则是针对具体的job的一个替换。涉及到的yaml文件内容以下:

# base/kustomization.yaml  apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - cronjob.yaml   # base/cronjob.yaml apiVersion: batch/v1beta1 kind: CronJob metadata:  name: think123- spec:  failedJobsHistoryLimit: 3  successfulJobsHistoryLimit: 1  startingDeadlineSeconds: 180  concurrencyPolicy: Forbid  schedule: "0 0 1 * *"  jobTemplate:  spec:  template:  spec:  containers:  - name: cron-job  image: harbor.xxx.com/think123/my-task  imagePullPolicy: Always  args:  - "help"  envFrom:  - configMapRef:  name: smcp-config  - secretRef:  name: smcp-service-secret  resources:  requests:  cpu: "250m"  memory: 1024Mi  limits:  cpu: "500m"  memory: 1024Mi  restartPolicy: Never   # overlay/beta/kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization  nameSuffix: send-email-job  resources: - ../../base/  patchesStrategicMerge:  - send-email-patch-args.yaml   # overlay/beta/send-email-patch-args.yaml apiVersion: batch/v1beta1 kind: CronJob metadata:  name: think123- spec:  schedule: "0 4 * * 1-5"  jobTemplate:  spec:  template:  spec:  containers:  - name: send-email-job  args: ["sendEmail"]  复制代码

你可使用kustomize build beta > send-email-cron-job.yaml命令,而后查看send-email-cron-job.yaml文件，就能够看到生成的具体的cronjob的详细。

kustomize的文档能够参考: https://kubernetes-sigs.github.io/kustomize/api-reference/

为何要用Kubernetes Cron Job

使用SpringBoot的定时任务不香吗？为何要还要引入新的东西。再想这个问题的时候，想一想为何你在SpringBoot中不写Servlet,不是同样能够吗？

其实想一想仍是有缘由的，首先咱们的服务是分布式的，咱们的定时任务应该只须要运行一次，而不是每一个实例都运行一次，若是用SpringBoot的task那么咱们须要用代码来保证这个行为。

若是引入分布式任务框架，又是引入了一堆其余新的东西，好比注册中心等等，并且还要去学习一项新的技术。

而咱们的服务因为是经过Kubernetes部署的，咱们的job再使用Kubernetes来，更是相得益彰。