写在开头
Jenkins是非常流行的开源的持续交付平台，拥有丰富的插件、文档与良好的社区。是国内大多数公司私有持续集成方案CI/CD服务器的选型。开发者可以快速的通过Jenkins搭架符合自己业务场景的pipeline，结合大量的开源插件，可以轻松的满足不同语言、不同平台、不同框架的持续集成场景。无论是风头蒸蒸日上的Gitlab-CI或者是在开源领域广受好评的travis.ci,都无法替代Jenkins在持续集成领域的地位。但是再高大的建筑也无法遮住阳光下的影子，Jenkins虽然有各种各样的优势，它的问题也足以令人扼腕。本系列的初衷是通过源码的方式学习Jenkins，改造Jenkins。
Jenkins的罪与罚
高可用性
作为持续集成领域多年的Top one，Jenkins的所有的数据存储竟然都是以xml文件的方式进行持久化的。在Jenkins启动的时候需要指定存储源数据的目录，可以通过JENKIN_HOME这个目录进行配置。JENKINS_HOME的目录结构如下：
1.4M ./updates
180M ./plugins
147M ./cache
4.0K ./.docker
60K ./secrets
124K ./.java
508K ./logs
4.0K ./fingerprints
8.0K ./init.groovy.d
21M ./monitoring
260K ./users
44K ./nodes
12K ./.ssh
45G ./jobs
74M ./war
8.0K ./userContent
45G .其中users中存放了和Jenkins用户相关的配置信息；jobs中存放和Jenkins的任务相关的信息，包括构建历史、构建配置等等；在nodes中存放了Jenkins子节点的相关配置信息。这就意味着，Jenkins的Master的水平无状态扩展成为了不可能，虽然Jenkins支持的Master/Slave的架构，可以支持一台Master并发数百个Slave，但是单台的Server的可靠性与稳定性都面临巨大的挑战。面对这样的情形，社区的开发者们提出了2种解决的方案：
分片+冷备的Jenkins企业版HA方案
这个方案是Jenkins的最大维护公司Cloudbees提出的，Cloudbees开发并提供Jenkins的企业版的支持，提供Jenkins Cloud，面向公有云、私有云、大型企业用户提供付费的Jenkins服务。针对于大型企业Jenkins集群的场景，Cloudbees提出了如下的解决方案：
Cloudbees并非直接扩展Jenkins，而是在Jenkins的上层做了一个独立的系统，叫做Jenkins Operations Center(简称CJOC),CJOC是一个Jenkins集群的管理工具，是一个统一接入层，用户的身份认证（oauth或者ldap）在CJOC进行处理，然后分配到不同的Jenkins Master；集群的Slave节点资源池由CJOC进行分配；Master节点宕机，任务的重试由CJOC进行分发。可以说CJOC是Jenkins集群的资源、任务调度系统，不同的任务通过CJOC会调度到不同的Jenkins Master上。`
Jenkins Master在CJOC中是成对存在的，两个Master会通过共享存储的方式同步元数据信息，通过haproxy将两个节点挂载到一个虚拟IP下，当一个Jenkins Master宕机的时候，会再另外一台机器上启动起Jenkins Master实现宕机切换，原来在当前Master上运行的任务会通过CJOC再重新下发，分配到新的节点上。
采用Gearman插件实现伪Jenkins集群
Openstack项目使用Jenkins作为所有模块的持续集成方案，每天共计需要运行超过8000个JOB，而单个Master的方案无法满足自身的需求，因此Openstack的团队开发了一款Jenkins的Gearman插件，用来承载更多的任务，大致的架构图如下：
Gearman插件是运行在Jenkins Master上的，此时Jenkins Master就可以看做一个Gearman的 worker。
Gearman插件会监听Gearman Server的事件，并将Gearman的Job转换为Jenkins的Job，并使用Jenkins Master的Slave进行Job的执行。也就是说Gearman并不是Jenkins的job的scheduler，而只是借助Jenkins的Slave的环境来执行任务。
Openstack团队通过Gerrit的自动触发，将任务触发给Gearman Server，Gearman Server将任务推送到消息队列中，在Jenkins Master中的Gearman worker监听到消息，通过Jenkins Job Builder，将项目转换为一个Jenkins Job，然后再下发到Jenkins的Slave中。
如上图所示，Openstack的Jenkins集群方案之所以称为伪集群，是因为此时用户不是直接使用Jenkins来实现相关的功能，而是通过自动触发Gearman的方式将定制好的持续集成任务转换为Jenkins Job实现的。这种方式对于大多数开发者而言，搭建和改造的成本过大，而且缺乏页面的支持，对于很多业务繁多复杂的企业而言，是无法接受的。
对于大型的Jenkins集群而言，目前尚没有特别的好方案，特别是在高并发、多租户的场景下，Jenkins的集群SLA还是有很大的提升空间的。
性能
由于Jenkins采用xml文件的方式实现数据的存储，在long run的Jenkins项目中，需要持久化的数据是惊人的，而这也导致了单个Master可以创建的Job和长连接的Slave的数目受到了巨大的限制,下面是社区中开发者对Jenkins的性能测试的讨论。
- Number of plugins.Plugins cause performance issues for builds (because of hooks) and UI (because they adds stuff to it). Do not add too many plugins and anyway - evaluate them thoroughly.
- Number of jobs. Jenkins gets slow (at least in UI) with 1000+ jobs. Moving jobs to several masters (manual static sharding) helps. E.g. one master - for builds, another - for tests.
- Number of slaves. There is “X1K initiative” - goal for Jenkins developers to assure smooth operation of master with 1000 executors on all slaves. It is still a challenge. Somewhere around 250 slaves and lots of builds slave connections start getting broken in the middle of a build.
Number of executors per slave. Increasing number of executors over the slave capabilities decreases overall throughput - due to clashes, IO congestion or RAM swapping. Leverage RAM, CPU cores and build type. RAM should be enough for maximum number of builds at maximum memory setting + file cache. CPU should be enough to work below 100% utilization, taking IO into account - IO releases some CPU time. Have less than 1 executor per CPU core for single-thread builds. Consider IOPS limit - to avoid disk IO being a bottleneck. Generally if 15 min Load Average more than the number of cores, the number of executors should be decreased. There is a suggestion - 1 executor per slave for isolation. It is reasonable in cloud but for dedicated hardware the same isolation can be achieved by lightweight containers.
总结而言，Jenkins Master中需要尽可能少的加载插件，单个Master的Job数量最好不要超过1000，单个Master的Slave数目最好不要超过250个，每个slave上面的excutor需要更具项目来判断，设置合理的阈值。这些指标对于Jenkins而言有非常大的优化空间，这也是为什么本系列带大家一起学习Jenkins的原因。
扩展性
从某种意义来讲，Jenkins的扩展性是非常强的,支持非常多的扩展点，开发者可以通过扩展点开发插件来实现各种想要的功能，甚至Jenkins支持Jython或者Jruby的方式来扩展Jenkins。但是这样的灵活性是基于Jenkins的框架之上的。也就是说如果开发者想要去修改Jenkins core中的代码的时候，就要非常小心，因为有可能依赖的插件也同样扩展了core中的代码的扩展点，导致插件的不可用。而且插件和插件之间也是可以相互依赖的，这就导致了有可能开发者只是修改了一个扩展点中参数的类型，一连串的插件可能都无法使用。因此在扩展Jenkins的时候，尽可能的使用插件的方式会是更好的选择，可是插件越多Jenkins的性能损耗就越大，这就陷入了一个难以走出的循环泥淖，开发者需要抉择是选择性能，还是选择扩展的风险。
历史包袱
Jenkins本身的源码具有非常强大的扩展性，Jenkins拥有非常丰富的扩展点，基本上想要扩展的位置都可以通过扩展点的方式实现，这种强大的扩展性带来的好处是开发者可以快速的根据自身的需求来扩展相应的扩展点。但是权限开放的越大，就越难收回来，Jenkins从Hudson 2004年推出开始，在技术架构上面的演进一致被各种历史包袱掣肘着前进，Jenkins的设计放到今天来看也是先进的，但是在一些实现技术和代码的结构上可以发现非常明显的历史包袱和痕迹。自2011年Hudson改名为Jenkins，项目中时至今日，原来Hudson项目的源码还没有完全演进完毕，不得不说这对于想要深入学习、研究、修改Jenkins的开发者而言是一个巨大的挑战。
写在最后
虽然在本文中写了很多Jenkins的问题，但是这些问题大部分针对于希望扩展甚至改写Jenkins的开发者而言的，对于使用Jenkins的持续集成的开放者而言，Jenkins依然是目前最好的选择。在下一篇文章中，我们将正式开始从代码学习Jenkins。
