Jenkins 刚开始搭建的时候，我们惊叹，这也太方便了吧？功能还这么强，慢慢的，我们会发现对方的缺点了，嗯，恋爱的味道，不对，似乎扯远了，还是说回来Jenkins了。
Jenkins没有数据库？
我们很难想象Jenkins，这么庞大的一个应用，居然没有数据库。那配置在哪保存呢？运行日志了？构建数据了？等等这些都是需要保存的啊。
没错，这些都保存在 master节点所在的
~/.jenkins目录下，有node配置，有job配置记录等等，因此，我们使用过程中，导致了如下问题:
1. 访问卡顿，没有负载均衡
当jenkins job数量达到一定量级，访问量大时候，会非常卡顿，仿佛回到了零几年的时候，网页那么卡。
查原因我们会发现瓶颈在 I/O。因为jenkins每次访问，都需要读取配置，都需要读写日志，这些都是以文件方式写入磁盘的，是所有slave节点和一台master通信。
可是我们是没有办法做负载均衡的
2. 没有冗余，容灾
当我们部署后端服务时候，肯定做LB(负载均衡), Jenkins master因为只能单节点，啊，挂了master，所有slave都掉链子了。
3. 日志，构建产物的存储
配置 存储 master节点磁盘，嗯，还好，比较小
构建日志 存储在master节点磁盘，这个，百万行代码的编译日志几百M大小，每天N个业务构建M次，存储在master，哈哈，每天上班第一件事清磁盘？
构建产物 存储在master节点磁盘，这个，占磁盘，不安全
针对这种情况了，日志用ELK，产物放到到对象存储
Jenkins 调度这么笨？
调度，一个好高深的话题，教材上学过操作系统对进程的各种调度算法，什么先入先出，最短耗时，最高优先级(PRI,NI)等等，而类似的集群调度， k8s可能是最常见的了，但是Jenkins对于任务调度这块，实际来讲，确实很弱, 虽然调度也是Jenkins的核心能力之一
k8s里面有 node节点概念，Jenkins也有
k8s里面有 pod概念，Jenkins没有，类似的，Jenkins是限制node的最大并行个数
k8s 里面有调度器， 进行Predicates 和 Priorities两个过程， Jenkins 算法很简单，默认就是调度到最近一次成功节点上。
这样会带来一个比较严重的问题，会导致部分机器处于极度打满，部分机器确空转，资源利用率严重两级分化。
针对这点，我们其实有两种小的补救。
一种是降低node节点并行数量，比如原来是最大限制是10，下降到2后，第三个任务，比如调度另一个节点了，缺点就是可能造成更多排队情况
一种就是利用插件了，比如插件throttle-concurrents会比较均匀分配 https://plugins.jenkins.io/throttle-concurrents
总体而言，调度这块，Jenkins确实有很长路走
Jenkins 流水线
微服务相比单体应用似乎高大上了很多，我们把服务抽象出来，只专注于某一部分，然后各个部分串联起来。
Jenkins里面，一次构建，我们可能会写一个长长的脚本，举例子来说，我们需要构建一个移动端产物apk/ipa， 我们需要
clone code -> 更新依赖库 -> 编译 -> 产物保存 -> 分发到商店
传统上，我们可以把这一串代码都写到job配置里面，但更好的做法，我们是把每一步抽象出来，每一步都是一个服务(一个job)
怎么串联起来呢？ 没有流水线之前，是Jenkins 上下游任务关联, 哈哈，当任务量多了，我们发现，调用链很难捋清楚了，当然微服务里面有自己的解决办法 - 链路追踪，网关
流水线，可以帮我们把这些串联起来，我们最后需要管理的只是流水线
小思考，不足之处，欢迎交流
