# kronos

**Repository Path**: ATM006/kronos

## Basic Information

- **Project Name**: kronos
- **Description**: 基于k8s的流式分布式任务调度系统
- **Primary Language**: Java
- **License**: AFL-3.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 2
- **Created**: 2020-09-04
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

## DockerFile
- FROM java:8
- VOLUME /data/application/logs/kronos
- ADD package/lib/* /

# 前言
    Kronos是基于k8s的流式分布式任务调度系统
Kronos是一套流式任务调度系统，在日常开发工作中我们往往避免不了要处理一些比较复杂的流式任务，市面上的定时任务系统的实现方式也是多种多样，优缺点各有不同，在此之前我最长用的就是ElasticJob和XxlJob。他们的实现原理这里就不再缀诉了，有兴趣的小伙伴可以去了解一下。

使用定时系统过程中，发现很多时候任务的处理效率往往不尽人意，排查原因后发现往往是线程或内存出现资源竞争，严重的情况下可能会影响到同一服务器上的其他服务。

设置定时任务的执行时间时，我们经常发现有些任务之间存在着先后执行的关系，比如B任务必须在A任务执行完成后再执行，这时我们通常的解决办法就是在两个任务触发时间之间预留出足够长的时间，这样往往会浪费一些时间，而且这个时间会随着任务链的增长而增长，这对一些对处理效率要求很严格的任务就不适用了

那么我们了解了上诉问题怎么改进呢？这时运维同事在做k8s的技术分享的时候提到了k8s的Job，这对我的启发很大，对k8s技术做了一些研究之后，决定保留分布式任务分片功能，设计开发一个基于k8s对流式分布式任务调度系统

# 使用Kubernetes

k8s在生成Job时声明Job所需要的资源（CPU、内存、带宽等）以及任务要分片的数量，每一片任务都是一个单独的Pod并独享一片资源，这样就能够避免了任务间的资源竞争问题，Job组件在执行完所有的Pod后会自动释放资源，当资源不足的时候会停止生成Pod等待资源。

# Kronos设计方案

![输入图片说明](https://images.gitee.com/uploads/images/2020/0620/154650_ac66e0e6_1074282.jpeg "Untitled Diagram.jpg")

Kronos项目分成两部分：kronos-schedule、kronos-executor
kronos-schedule：负责任务的触发、调度、声明、以及k8s资源的监控，对外提供api
kronos-executor：任务的执行端，业务容器项目引入executor依赖后生成docker镜像，k8s在生成Pod时会pull下来这个镜像

# 任务流的实现

现在我们有了k8s对服务器资源管理可以对每片任务进行资源隔离，那么接下来就要解决第二个问题---任务流
如果所资源隔离是一种任务间的解偶，那么任务流就恰恰相反，增加任务之间的联系，以上图为例，任务流的执行顺序是：Job-A -> Job-B -> Job-C，
当Job-A执行完成后怎么通知调度端（kronos-schedlue）触发Job-B呢？最简单的方式就是当Job-A执行完成后调用kronos-schedlue的接口进行通知，最初我也是这样做的，后来发现了kubernetes的watch-list功能，可以监听k8s中每个job的执行进程

### 任务流的刹车
任务流在触发后往往会因为各种原因需要手动的关停，k8s中是没有Job停止的功能的只有创建和删除，经过测试删除Job后这个Job中声明的Pod不会立即停止，还会继续执行占用资源，同时还会影响到执行信息的溯源，所以我们采用了比较温和的方案，清空上述存放索引的任务队列，pod获取不对索引立即结束进程不再执行业务代码释放资源