近期又有几个朋友看了俺的文章询问。怎样让Jenkins能做到分布式。我解释了非常久，发现这也是个非常好的topic，就来博客继续念叨念叨。
这个非常easy，所以这篇文章也就介绍简单点。
首先说下Jenkins能支持的几种build框架：
1.我构建，我收集的Master only框架。
Master only 框架主要就靠Jenkins本身运作在Server上（数据库在server上或不在都属于该框架），利用Server本身的硬件资源进行build（编译，做包。測试等）。
它能做到的事情：
a:可以让job执行在Master上。
b:可以让job写数据到database。
c:可以让job更新/计划数据并展示。
2.你构建，我收集的Master-单slave框架。
该框架是用于解决单一server又执行Jenkins又编译，影响Jenkins的正常运作的情况。该框架让Jenkins的Agent常驻在另外一台服务器，让它变成Jenkins的slave。由slave来执行job.Master就用来收集数据，传递数据。展示数据。
3.你们构建。我收集的Master-多slave框架。
改框架主要攻克了单台slave同一时候编译多branch的软件的时候的效率低下问题。由N个Jenkins Agent常驻于N个server，由Master统一调度job执行在不同的Slave上。从而达到不同的branch编译不会相互影响的情况，加速编译、做包速度。
而Master 仅仅用于收集数据、展示数据。
4.你们构建，我们各收集各的多Master-多slave框架。
该框架用于解决因为Jenkins 的负载太重导致的Jenkins性能问题，由多个Jenkins作为不同的Master，指派Job到不同的Slave上build.各个master负责的Job领域、类型不同。比方Master 1是SCM做包的，Master2专门管编译，Master 3用于自己主动化測试。而Master们还是用于收集数据，展示信息。
这个框架便是下一步的Cloud build的基础。
5.Cloud Build
该框架是一个动态的框架。处于1-4的框架中的一种。所以这里就没有配图了。
当任务不多的时候。可能为1-2.
当任务非常多的时候，可能为3.
当任务巨大的时候，可能为4.
由于有了Cloud。server资源能够任意调配。那么能够在Cloud上申请几个instance做为Master，同一时候申请几千个CPU的slave做编译。编译完释放instance的所用资源。
而Master还是仅仅做数据收集、展示数据。
当这个Master完毕任务的时候，该instance也能够释放所用资源。
Cloud build框架用于节约HW的资源。一个Cloud服务的公司能够提供非常多其它公司来用它的服务，从而降低了总的HW数量。而几千个cpu的编译速度，不是一般server能比的。
说了这么多，看官您云（晕）了没？