一 、自研s资前言
现在的源调企业很多都在用Jenkins做持续集成 ，各个业务端都依靠Jenkins，度系vivo Devops也是统设使用Jenkins来进行持续构建 ，部署Jenkins服务时如何保障服务的计实践高可用变得尤为重要 。
下面是自研s资目前Jenkins存在的一些问题 。
Jenkins本身是源调单体的，即只能有一个Jenkins Master 。度系虽然你也可以在多台机器上部署多个Jenkins Master ，统设但这些Master之间没有联系，免费模板计实践都是自研s资各自把任务交给手下的slaver去执行，没有任何交集 。源调
也许某个master下的度系slaver很忙 ，而另一个master下的统设slaver却很闲 ，资源得不到充分利用 。计实践 当其中一个slave宕机之后 ，该slave上的运行的job任务没有版本重新进行分配 ，需要用户重新执行 。并且slave节点离线之后没有通知管理员。 当系统业务量比较大的服务器租用时候业务请求集中在Jenkins Master上 ，会对Jenkins造成压力 ，甚至的造成Jenkins服务不可用 。 当有job任务在jenkins Master上队列排队的时候，Jenkins Master宕机后 ，队列任务不可持久化。Jenkins Workspace没有自动清理功能 ，会导致磁盘空间不足 ，任务执行不了的情况。基于以上情况 ，vivo Devops对Jenkins的部署架构进行优化搭建 ，并且配套了一套Jenkins资源调度系统用于管理Jenkins资源 。云计算
二 、业界实现
目前业界也包含一些Jenkins 高可用的设计方式 ，但是并不能完全的满足解决上述问题 ，比如 ：
2.1 方案一 Gearman + Jenkins这是OpenStack团队使用的方案。这个方案使用了gearman ， gearman是个任务分发框架 。
需要在每个Master上安装好gearman的插件，并配置好能连接到gearman server ，同时在每个Master必须建立相同的模板下载job。
之后运行任务的流程如下：
gearman worker运行在各个Jenkins Master中等待gearman server分发任务；gearman client向gearman server发出运行job的请求；gearman server通知各个gearman worker有任务拉 ，第一个闲着的worker会接受任务 ，如果所有的worker都忙 ，则放入gearman的任务队列 ，得worker空闲时再分配；gearman worker闲下来后会从任务队列里取job来执行 ，执行完之后 ，将结果发回给gearman server;gearman server将结果返回给 gearman client 。优点 ：
这样各个salver资源可以得到充分利用 ，某个master挂掉另外的master可以继续服务 。高防服务器
弊端 ：
每个master的slave必须配置一致，否则会造成job调度错误 ，同时会造成一些资源的浪费 。当一个master出现问题 ，该master的任务不会进行自动重新分配 。
2.2 方案二 改造Jenkins的文件存储方式
目前Jenkins的配置文件都是直接在硬盘上以文件形式存储的，你在JENKINS_HOME的个文件夹下能看到各种.xml文件 。有些公司在Jenkins上进行二次开发 ，香港云服务器将Jenkins的数据存储方式改为数据库存储 ，这样前端可以起多个Jenkins服务，后端连相同的数据库即可 。数据库也有比较成熟的高可用方案 。
优点:
可以达到Jenkins的高可用也就是某个master挂掉另外的master可以继续服务 。
弊端 ：
需要对Jenkins进行二次开发 ，使用数据库会降低读取资源效率下降。
2.3 方案三 最简单的Jenkins一主一备模式平时让Jenkins A机器提供服务 ，并使用SCM Sync configuration plugin保存数据 ，JenkinsA机器修改配置后触发Jenkins B更新配置 ，一旦Jenkins A出现问题挂掉后，切换到备机Jenkins B上 。
优点:
可以达到Jenkins的高可用，当master宕机后会进行切换到备机上。
弊端:
会有一批Jenkins备机存在资源浪费 ，切换master时间过长 ，会导致有段时间Jenkins服务不可用 。
三、vivo Jenkins Scheduler系统目标
由于目前业界的一些实现还不能完全的满足我们目前的需求 ，所以我们进行了vivo jenkins scheduler系统的设计与实现 。该系统需要达到如下的目的 ：
提升整个构建服务可靠性时长。保证jenkins集群的高可用，解决目前master-slave的单点问题，保证整个构建服务的可靠性时长 。降低灾难时服务恢复时长 。①提供精准流控方式，在jenkins构建出现请求量过高的时候可以进行流控和持久化操作，减少对目前系统的冲击 。
②当系统压力减少后，放开流控可以快速的对堆积的请求进行分配执行 。有效分配任务至各个子节点 ，保证资源的有效利用。能保证灾难时的及时切换任务至可用节点上 ，同时能快速的通知管理员进行处理 。能进行数据的可视化分析，能提供一系列帮助改善开发效率的视图 ，比如构建时长报表、构建量报表等 。四 、 vivo Jenkins Scheduler设计
该系统我们从两大部分进行了设计 ，首先 ，我们不采用原生的Jenkins部署方案，而是采用全master的方式 。第二 ，设计并开发了一套用于管理Jenkins集群的调度系统 。
五 、底层 Jenkins 工具部署方案
不采用目前单master的搭建方案 ，采用多master的搭建方案 ，master下不进行挂载slave机器，任务直接有master进行处理，master之间的关系 、任务分配 、离线、插件安装等由调度系统进行管理 。这样由于vivo Jenkins Scheduler系统为高可用的 ，解决了目前Jenkins的单点问题。
六 、系统架构图
七 、系统说明
7.1 API-Gateway主要提供系统的外部请求 ，网关系统 ，功能包含 ：
权限校验 ：校验用户发送集群管理系统的请求的权限 。智能路由 ：接收外部一切请求 ，并转发到后端的外服上去 。限流 ：与监控线程配合（当构建请求达到某个阈值时） ，进行限流操作 。API日志统一收集 ：类似于一个aspect切面 ，记录接口的进入和出去时的相关日志 。数据处理：对请求的参数进行数据的转换处理。7.2 事件中心是整个系统通信调用的主要模块 ，采用的是Spring的Event机制实现 ，主要核心事件如下 ：
Jenkins注册事件（EVENT_REGIST_JENKINS）：
Jenkins启动后，通过自定的插件会向系统发送注册请求时，系统接收到后会触发Jenkins管理模块将Jenkins的信息注册至调度系统中。Jenkins宕机事件 (EVENT_DOWN_JENKINS):
监控管理轮询检查Jenkins状态 ，当发现有Jenkins宕机的情况会触发该事件 ，Jenkins管理模块处理将Jenkins的信息状态设置为不可用状态 ，从而是任务不能分配至该台jenkins 。任务从分配事件 (EVENT_JOB_REDO):
当Jenkins宕机后 ，如果该台jenkins上存在未执行完的任务时候 ，由job监控模块触发 ，job管理莫管处理 ，会对该Jenkins上未执行的job进行重新分配 。任务接受事件 (EVENT_JOB_RECIVE):
当job管理模块接受到创建请求 ，会触发该事件 ，由job管理模块放入Redis执行队列 。任务执行事件 (EVENT_JOB_EXECUTE):
job管理模块中的执行线程(10s执行一次 ，会从Redis队列中弹出任务)，弹出任务后触发该事件，由调度中心选取合适的jenkins进行执行 。7.3 调度中心是整个系统的核心模块 ，主要的功能是进行执行job时候能选取合适的jenkins进行处理任务 ，包含两个核心算法：
7.3.1 Jenkins分组算法
每台jenkins都可以使用标签的方式 ，打上多个标签 ，比如jenkins可以构建java程序 ，使用的构建工具可以是maven和gradle ，这个时候我们就可以给其打上java 、maven 、gradle三个标签 。
标签的维度主要有以下几个 ：
标签配置 ： 判断构建配置是否配置了标签 ，根据标签选择对应标签的Jenkins ，比如配置了（docker等） 。构建语言： 根据构建配置的语言 ，比如Java 、C++ 、Python 、Go等 。构建工具和版本 ： 比如Maven 、gradle 、Ant，Cmark 、Blade等。JDK版本 ：比如JDK7 、JDK8等 。Go语言版本 ：比如1.15.x. 、1.16.x等 。GCC版本 ：如6.x 、4.x等 。Python版本 ：2.x 、3.x等。是否存活：判断Jenkins是否存活 ，如果宕机直接过滤 。（可选策略）选择执行过该job的Jenkins ，减少下载代码的过程 ：（第一次构建还是会比较慢 ，可以采用预执行的方式 ，在配置构建配置的时候，就预先执行一次 ，这样在用户执行的时候就使用该job执行过得workspace ，减少代码下载的时间） 。（可选策略）根据job的构建的平均构建时长 ，如果构建时长达到某个配置阈值时 ，优先选择构建器空闲多的Jenkins进行执行，并指出Jenkins的锁定功能 。其他的job不允许分配上来 。如果我们给Jenkins打上标签 ，那么我们就可以使用标签为维度将Jenkins进行分组 ，并且存入至Redis中缓存 ，方便后续选取Jenkins用来执行任务 ：
7.3.2 Jenkins选取算法
当Jenkins分组好了后 ，我们接受到执行的job的信息就可以使用Jenkins选取算法进行快速的选取合适的Jenkins进行处理job，如下图所示 。
其中label子线程 、语言子线程……就是我们上面的Jenkins分组的维度 ，有多少维度 ，那么这里就会有多少子线程处理 。
构建任务进入主线程 ，然后主线程会按照分组维度分组操作并进行过滤 ，然后获取到每个分组中合适的Jenkins ，再进行取交集（这个时候就获取到可以执行该构建任务的Jenkins了） ，在判断是否需要经过可选策略 ，最终得到Jenkins。
调度系统中的的任务接受采用的是队列的方式实现 ，当系统请求量达到阀后 ，系统将不会进入Redis队列 ，会将请求持久化至MySQL 。后续如果有请求过来 ，job管理模块会检查数据库MySQL中是否有请求 ，如果有请求 ，会将请求放入Redis队列 ，如果没有请求就会将当前请求放入Redis队列 ，具体流程如下:
其中基于Redis实现的消息队列的时序图如下:
该模块主要是监控任务的状态 ，当任务开始执行 、中断执行 、执行成功 、执行失败的时候进行通知业务并存储数据 ，用于保存构建记录 ，方便后续数据的统计 ，用来完成数据的可视化 。
八 、实施效果
目前该系统已经投入生产环境运行 ，Jenkins任务已采用调度系统进行调度执行 ，运行稳定 ，运行效果 。
九、后续展望
随着vivo Jenkins 调度系统的功能慢慢完善 ，Jenkins的机器也越来越多，目前还大多数运行在虚拟机上 ，从资源利用率和业务发布效率来看 ，未来的业务发布形态将会是以容器为主 。目前公司也在大力发展k8s的容器生态建设 ，
所以我们希望将Jenkins工具后期进行容器化 、池化 ，在提高资源利用率和发布效率的同时也可以为用户提供可靠的 、简洁的 、稳定调度执行 。