一
、自研s资前言

现在的源调企业很多都在用Jenkins做持续集成，各个业务端都依靠Jenkins，度系vivo Devops也是统设使用Jenkins来进行持续构建 ，部署Jenkins服务时如何保障服务的计实践高可用变得尤为重要 。

下面是自研s资目前Jenkins存在的一些问题 。

Jenkins本身是源调单体的 ，即只能有一个Jenkins Master。度系虽然你也可以在多台机器上部署多个Jenkins Master，统设但这些Master之间没有联系
，源码下载计实践都是自研s资各自把任务交给手下的slaver去执行
，没有任何交集 。源调

基于以上情况，vivo Devops对Jenkins的部署架构进行优化搭建  ，并且配套了一套Jenkins资源调度系统用于管理Jenkins资源。云计算

二 、业界实现

目前业界也包含一些Jenkins 高可用的设计方式，但是并不能完全的满足解决上述问题 ，比如 ：

这是OpenStack团队使用的方案。这个方案使用了gearman ， gearman是个任务分发框架 。

需要在每个Master上安装好gearman的插件，并配置好能连接到gearman server，同时在每个Master必须建立相同的香港云服务器job 。

之后运行任务的流程如下：

优点：

这样各个salver资源可以得到充分利用，某个master挂掉另外的master可以继续服务。模板下载

弊端：

每个master的slave必须配置一致，否则会造成job调度错误，同时会造成一些资源的浪费 。当一个master出现问题 ，该master的任务不会进行自动重新分配。

2.2 方案二 改造Jenkins的文件存储方式

目前Jenkins的配置文件都是直接在硬盘上以文件形式存储的 ，你在JENKINS_HOME的个文件夹下能看到各种.xml文件。有些公司在Jenkins上进行二次开发，服务器租用将Jenkins的数据存储方式改为数据库存储，这样前端可以起多个Jenkins服务，后端连相同的数据库即可。数据库也有比较成熟的高可用方案
。

优点:   

可以达到Jenkins的高可用也就是某个master挂掉另外的master可以继续服务。

弊端：

需要对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构建出现请求量过高的时候可以进行流控和持久化操作 ，减少对目前系统的冲击 。

四、 vivo Jenkins Scheduler设计

该系统我们从两大部分进行了设计，首先 ，我们不采用原生的Jenkins部署方案 ，而是采用全master的方式 。第二
，设计并开发了一套用于管理Jenkins集群的调度系统。

五 
、底层 Jenkins 工具部署方案

不采用目前单master的搭建方案，采用多master的搭建方案，master下不进行挂载slave机器 ，任务直接有master进行处理 ，master之间的关系、任务分配、离线 、插件安装等由调度系统进行管理
。这样由于vivo Jenkins Scheduler系统为高可用的
，解决了目前Jenkins的单点问题。

六、系统架构图

七、系统说明

主要提供系统的外部请求 ，网关系统，功能包含 ：

是整个系统通信调用的主要模块，采用的是Spring的Event机制实现，主要核心事件如下 ：

：

  : 

: 

:

 : 

是整个系统的核心模块，主要的功能是进行执行job时候能选取合适的jenkins进行处理任务 
，包含两个核心算法：

7.3.1 Jenkins分组算法

每台jenkins都可以使用标签的方式，打上多个标签 ，比如jenkins可以构建java程序，使用的构建工具可以是maven和gradle
，这个时候我们就可以给其打上java
、maven、gradle三个标签。

标签的维度主要有以下几个：

如果我们给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工具后期进行容器化 、池化
，在提高资源利用率和发布效率的同时也可以为用户提供可靠的、简洁的 、稳定调度执行。