本文從目前業(yè)界實(shí)現(xiàn)Jenkins的高可用的實(shí)現(xiàn)方案，分析各方案的優(yōu)缺點(diǎn)，引入vivo目前使用的Jenkins高可用方案，以及目前Jenkins資源的調(diào)度方案的設(shè)計(jì)實(shí)踐和目前的落地運(yùn)行效果。

一、前言

現(xiàn)在的企業(yè)很多都在用Jenkins做持續(xù)集成，各個(gè)業(yè)務(wù)端都依靠Jenkins，vivo Devops也是使用Jenkins來(lái)進(jìn)行持續(xù)構(gòu)建，部署Jenkins服務(wù)時(shí)如何保障服務(wù)的高可用變得尤為重要。

下面是目前Jenkins存在的一些問(wèn)題。

Jenkins本身是單體的，即只能有一個(gè)Jenkins Master。雖然你也可以在多臺(tái)機(jī)器上部署多個(gè)Jenkins Master，但這些Master之間沒(méi)有聯(lián)系，都是各自把任務(wù)交給手下的slave去執(zhí)行，沒(méi)有任何交集。
也許某個(gè)master下的slave很忙，而另一個(gè)master下的slave卻很閑，資源得不到充分利用。

當(dāng)其中一個(gè)slave宕機(jī)之后，該slave上的運(yùn)行的job任務(wù)沒(méi)有版本重新進(jìn)行分配，需要用戶重新執(zhí)行。并且slave節(jié)點(diǎn)離線之后沒(méi)有通知管理員。

當(dāng)系統(tǒng)業(yè)務(wù)量比較大的時(shí)候業(yè)務(wù)請(qǐng)求集中在Jenkins Master上，會(huì)對(duì)Jenkins造成壓力，甚至的造成Jenkins服務(wù)不可用。

當(dāng)有job任務(wù)在jenkins Master上隊(duì)列排隊(duì)的時(shí)候，Jenkins Master宕機(jī)后，隊(duì)列任務(wù)不可持久化。

Jenkins Workspace沒(méi)有自動(dòng)清理功能，會(huì)導(dǎo)致磁盤(pán)空間不足，任務(wù)執(zhí)行不了的情況。

基于以上情況，vivo Devops對(duì)Jenkins的部署架構(gòu)進(jìn)行優(yōu)化搭建，并且配套了一套Jenkins資源調(diào)度系統(tǒng)用于管理Jenkins資源。

二、業(yè)界實(shí)現(xiàn)

目前業(yè)界也包含一些Jenkins 高可用的設(shè)計(jì)方式，但是并不能完全的滿足解決上述問(wèn)題，比如：

2.1 方案一 Gearman + Jenkins

這是OpenStack團(tuán)隊(duì)使用的方案。這個(gè)方案使用了gearman， gearman是個(gè)任務(wù)分發(fā)框架。

需要在每個(gè)Master上安裝好gearman的插件，并配置好能連接到gearman server，同時(shí)在每個(gè)Master必須建立相同的job。

之后運(yùn)行任務(wù)的流程如下：

gearman worker運(yùn)行在各個(gè)Jenkins Master中等待gearman server分發(fā)任務(wù)；

gearman client向gearman server發(fā)出運(yùn)行job的請(qǐng)求；

gearman server通知各個(gè)gearman worker有任務(wù)拉，第一個(gè)閑著的worker會(huì)接受任務(wù)，如果所有的worker都忙，則放入gearman的任務(wù)隊(duì)列，得worker空閑時(shí)再分配；

gearman worker閑下來(lái)后會(huì)從任務(wù)隊(duì)列里取job來(lái)執(zhí)行，執(zhí)行完之后，將結(jié)果發(fā)回給gearman server;

gearman server將結(jié)果返回給 gearman client。

優(yōu)點(diǎn)：

這樣各個(gè)salver資源可以得到充分利用，某個(gè)master掛掉另外的master可以繼續(xù)服務(wù)。

弊端：

每個(gè)master的slave必須配置一致，否則會(huì)造成job調(diào)度錯(cuò)誤，同時(shí)會(huì)造成一些資源的浪費(fèi)。當(dāng)一個(gè)master出現(xiàn)問(wèn)題，該master的任務(wù)不會(huì)進(jìn)行自動(dòng)重新分配。

2.2 方案二 改造Jenkins的文件存儲(chǔ)方式

目前Jenkins的配置文件都是直接在硬盤(pán)上以文件形式存儲(chǔ)的，你在JENKINS_HOME的個(gè)文件夾下能看到各種.xml文件。

有些公司在Jenkins上進(jìn)行二次開(kāi)發(fā)，將Jenkins的數(shù)據(jù)存儲(chǔ)方式改為數(shù)據(jù)庫(kù)存儲(chǔ)，這樣前端可以起多個(gè)Jenkins服務(wù)，后端連相同的數(shù)據(jù)庫(kù)即可。數(shù)據(jù)庫(kù)也有比較成熟的高可用方案。

優(yōu)點(diǎn):

可以達(dá)到Jenkins的高可用也就是某個(gè)master掛掉另外的master可以繼續(xù)服務(wù)。

弊端：

需要對(duì)Jenkins進(jìn)行二次開(kāi)發(fā)，使用數(shù)據(jù)庫(kù)會(huì)降低讀取資源效率下降。

2.3方案三 最簡(jiǎn)單的Jenkins一主一備模式

平時(shí)讓Jenkins A機(jī)器提供服務(wù)，并使用SCM Sync configuration plugin保存數(shù)據(jù)，JenkinsA機(jī)器修改配置后觸發(fā)Jenkins B更新配置，一旦Jenkins A出現(xiàn)問(wèn)題掛掉后，切換到備機(jī)Jenkins B上。

優(yōu)點(diǎn):

可以達(dá)到Jenkins的高可用，當(dāng)master宕機(jī)后會(huì)進(jìn)行切換到備機(jī)上。

弊端:

會(huì)有一批Jenkins備機(jī)存在資源浪費(fèi)，切換master時(shí)間過(guò)長(zhǎng)，會(huì)導(dǎo)致有段時(shí)間Jenkins服務(wù)不可用。

三、vivo Jenkins Scheduler系統(tǒng)目標(biāo)

由于目前業(yè)界的一些實(shí)現(xiàn)還不能完全的滿足我們目前的需求，所以我們進(jìn)行了vivo jenkins scheduler系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。該系統(tǒng)需要達(dá)到如下的目的：

提升整個(gè)構(gòu)建服務(wù)可靠性時(shí)長(zhǎng)。

保證jenkins集群的高可用，解決目前master-slave的單點(diǎn)問(wèn)題，保證整個(gè)構(gòu)建服務(wù)的可靠性時(shí)長(zhǎng)。

降低災(zāi)難時(shí)服務(wù)恢復(fù)時(shí)長(zhǎng)。

①提供精準(zhǔn)流控方式，在jenkins構(gòu)建出現(xiàn)請(qǐng)求量過(guò)高的時(shí)候可以進(jìn)行流控和持久化操作，減少對(duì)目前系統(tǒng)的沖擊。

②當(dāng)系統(tǒng)壓力減少后，放開(kāi)流控可以快速的對(duì)堆積的請(qǐng)求進(jìn)行分配執(zhí)行。

有效分配任務(wù)至各個(gè)子節(jié)點(diǎn)，保證資源的有效利用。

能保證災(zāi)難時(shí)的及時(shí)切換任務(wù)至可用節(jié)點(diǎn)上，同時(shí)能快速的通知管理員進(jìn)行處理。

能進(jìn)行數(shù)據(jù)的可視化分析，能提供一系列幫助改善開(kāi)發(fā)效率的視圖，比如構(gòu)建時(shí)長(zhǎng)報(bào)表、構(gòu)建量報(bào)表等。

四、 vivo Jenkins Scheduler設(shè)計(jì)

該系統(tǒng)我們從兩大部分進(jìn)行了設(shè)計(jì)，首先，我們不采用原生的Jenkins部署方案，而是采用全master的方式。第二，設(shè)計(jì)并開(kāi)發(fā)了一套用于管理Jenkins集群的調(diào)度系統(tǒng)。

五、底層 Jenkins 工具部署方案

不采用目前單master的搭建方案，采用多master的搭建方案，master下不進(jìn)行掛載slave機(jī)器，任務(wù)直接有master進(jìn)行處理，master之間的關(guān)系、任務(wù)分配、離線、插件安裝等由調(diào)度系統(tǒng)進(jìn)行管理。這樣由于vivo Jenkins Scheduler系統(tǒng)為高可用的，解決了目前Jenkins的單點(diǎn)問(wèn)題。

六、系統(tǒng)架構(gòu)圖

七、系統(tǒng)說(shuō)明

7.1 API-Gateway

主要提供系統(tǒng)的外部請(qǐng)求，網(wǎng)關(guān)系統(tǒng)，功能包含：

權(quán)限校驗(yàn)：校驗(yàn)用戶發(fā)送集群管理系統(tǒng)的請(qǐng)求的權(quán)限。

智能路由：接收外部一切請(qǐng)求，并轉(zhuǎn)發(fā)到后端的外服上去。

限流：與監(jiān)控線程配合（當(dāng)構(gòu)建請(qǐng)求達(dá)到某個(gè)閾值時(shí)），進(jìn)行限流操作。

API日志統(tǒng)一收集：類似于一個(gè)aspect切面，記錄接口的進(jìn)入和出去時(shí)的相關(guān)日志。

數(shù)據(jù)處理：對(duì)請(qǐng)求的參數(shù)進(jìn)行數(shù)據(jù)的轉(zhuǎn)換處理。

7.2 事件中心

是整個(gè)系統(tǒng)通信調(diào)用的主要模塊，采用的是Spring的Event機(jī)制實(shí)現(xiàn)，主要核心事件如下：

Jenkins注冊(cè)事件

（EVENT_REGIST_JENKINS）：

Jenkins啟動(dòng)后，通過(guò)自定的插件會(huì)向系統(tǒng)發(fā)送注冊(cè)請(qǐng)求時(shí)，系統(tǒng)接收到后會(huì)觸發(fā)Jenkins管理模塊將Jenkins的信息注冊(cè)至調(diào)度系統(tǒng)中。

Jenkins宕機(jī)事件

(EVENT_DOWN_JENKINS) :

監(jiān)控管理輪詢檢查Jenkins狀態(tài)，當(dāng)發(fā)現(xiàn)有Jenkins宕機(jī)的情況會(huì)觸發(fā)該事件，Jenkins管理模塊處理將Jenkins的信息狀態(tài)設(shè)置為不可用狀態(tài)，從而是任務(wù)不能分配至該臺(tái)jenkins。

任務(wù)從分配事件 (EVENT_JOB_REDO) :

當(dāng)Jenkins宕機(jī)后，如果該臺(tái)jenkins上存在未執(zhí)行完的任務(wù)時(shí)候，由job監(jiān)控模塊觸發(fā)，job管理莫管處理，會(huì)對(duì)該Jenkins上未執(zhí)行的job進(jìn)行重新分配。

任務(wù)接受事件 (EVENT_JOB_RECIVE) :

當(dāng)job管理模塊接受到創(chuàng)建請(qǐng)求，會(huì)觸發(fā)該事件，由job管理模塊放入Redis執(zhí)行隊(duì)列。

任務(wù)執(zhí)行事件 (EVENT_JOB_EXECUTE) :

job管理模塊中的執(zhí)行線程(10s執(zhí)行一次，會(huì)從Redis隊(duì)列中彈出任務(wù))，彈出任務(wù)后觸發(fā)該事件，由調(diào)度中心選取合適的jenkins進(jìn)行執(zhí)行。

7.3 調(diào)度中心

是整個(gè)系統(tǒng)的核心模塊，主要的功能是進(jìn)行執(zhí)行job時(shí)候能選取合適的jenkins進(jìn)行處理任務(wù)，包含兩個(gè)核心算法：

7.3.1 Jenkins分組算法

每臺(tái)jenkins都可以使用標(biāo)簽的方式，打上多個(gè)標(biāo)簽，比如jenkins可以構(gòu)建java程序，使用的構(gòu)建工具可以是maven和gradle，這個(gè)時(shí)候我們就可以給其打上java、maven、gradle三個(gè)標(biāo)簽。

標(biāo)簽的維度主要有以下幾個(gè)：

標(biāo)簽配置： 判斷構(gòu)建配置是否配置了標(biāo)簽，根據(jù)標(biāo)簽選擇對(duì)應(yīng)標(biāo)簽的Jenkins，比如配置了（docker等）。

構(gòu)建語(yǔ)言： 根據(jù)構(gòu)建配置的語(yǔ)言，比如Java、C++、Python、Go等。

構(gòu)建工具和版本： 比如Maven、gradle、Ant，Cmark、Blade等。

JDK版本：比如JDK7、JDK8等。

Go語(yǔ)言版本：比如1.15.x.、1.16.x等。

GCC版本：如6.x、4.x等。

Python版本：2.x、3.x等。

是否存活：判斷Jenkins是否存活，如果宕機(jī)直接過(guò)濾。

（可選策略）選擇執(zhí)行過(guò)該job的Jenkins，減少下載代碼的過(guò)程：（第一次構(gòu)建還是會(huì)比較慢，可以采用預(yù)執(zhí)行的方式，在配置構(gòu)建配置的時(shí)候，就預(yù)先執(zhí)行一次，這樣在用戶執(zhí)行的時(shí)候就使用該job執(zhí)行過(guò)得workspace，減少代碼下載的時(shí)間）。

（可選策略）根據(jù)job的構(gòu)建的平均構(gòu)建時(shí)長(zhǎng)，如果構(gòu)建時(shí)長(zhǎng)達(dá)到某個(gè)配置閾值時(shí)，優(yōu)先選擇構(gòu)建器空閑多的Jenkins進(jìn)行執(zhí)行，并指出Jenkins的鎖定功能。其他的job不允許分配上來(lái)。

如果我們給Jenkins打上標(biāo)簽，那么我們就可以使用標(biāo)簽為維度將Jenkins進(jìn)行分組，并且存入至Redis中緩存，方便后續(xù)選取Jenkins用來(lái)執(zhí)行任務(wù)：

7.3.2 Jenkins選取算法

當(dāng)Jenkins分組好了后，我們接受到執(zhí)行的job的信息就可以使用Jenkins選取算法進(jìn)行快速的選取合適的Jenkins進(jìn)行處理job，如下圖所示。

其中l(wèi)abel子線程、語(yǔ)言子線程……就是我們上面的Jenkins分組的維度，有多少維度，那么這里就會(huì)有多少子線程處理。

構(gòu)建任務(wù)進(jìn)入主線程，然后主線程會(huì)按照分組維度分組操作并進(jìn)行過(guò)濾，然后獲取到每個(gè)分組中合適的Jenkins，再進(jìn)行取交集（這個(gè)時(shí)候就獲取到可以執(zhí)行該構(gòu)建任務(wù)的Jenkins了），在判斷是否需要經(jīng)過(guò)可選策略，最終得到Jenkins。

7.4 流控管理&隊(duì)列管理

調(diào)度系統(tǒng)中的的任務(wù)接受采用的是隊(duì)列的方式實(shí)現(xiàn)，當(dāng)系統(tǒng)請(qǐng)求量達(dá)到閥后，系統(tǒng)將不會(huì)進(jìn)入Redis隊(duì)列，會(huì)將請(qǐng)求持久化至MySQL。

后續(xù)如果有請(qǐng)求過(guò)來(lái)，job管理模塊會(huì)檢查數(shù)據(jù)庫(kù)MySQL中是否有請(qǐng)求，如果有請(qǐng)求，會(huì)將請(qǐng)求放入Redis隊(duì)列，如果沒(méi)有請(qǐng)求就會(huì)將當(dāng)前請(qǐng)求放入Redis隊(duì)列，具體流程如下:

其中基于Redis實(shí)現(xiàn)的消息隊(duì)列的時(shí)序圖如下:

7.5 回調(diào)中心

該模塊主要是監(jiān)控任務(wù)的狀態(tài)，當(dāng)任務(wù)開(kāi)始執(zhí)行、中斷執(zhí)行、執(zhí)行成功、執(zhí)行失敗的時(shí)候進(jìn)行通知業(yè)務(wù)并存儲(chǔ)數(shù)據(jù)，用于保存構(gòu)建記錄，方便后續(xù)數(shù)據(jù)的統(tǒng)計(jì)，用來(lái)完成數(shù)據(jù)的可視化。

八、實(shí)施效果

目前該系統(tǒng)已經(jīng)投入生產(chǎn)環(huán)境運(yùn)行，Jenkins任務(wù)已采用調(diào)度系統(tǒng)進(jìn)行調(diào)度執(zhí)行，運(yùn)行穩(wěn)定，運(yùn)行效果。

九、后續(xù)展望

隨著vivo Jenkins 調(diào)度系統(tǒng)的功能慢慢完善，Jenkins的機(jī)器也越來(lái)越多，目前還大多數(shù)運(yùn)行在虛擬機(jī)上，從資源利用率和業(yè)務(wù)發(fā)布效率來(lái)看，未來(lái)的業(yè)務(wù)發(fā)布形態(tài)將會(huì)是以容器為主。目前公司也在大力發(fā)展k8s的容器生態(tài)建設(shè)，

所以我們希望將Jenkins工具后期進(jìn)行容器化、池化，在提高資源利用率和發(fā)布效率的同時(shí)也可以為用戶提供可靠的、簡(jiǎn)潔的、穩(wěn)定調(diào)度執(zhí)行。

審核編輯：劉清