微服务构建场景下，单台Jenkins slave理想并行构建数是多少？

嘿，我来帮你拆解这个问题——你碰到的核心矛盾其实是「开发的清理需求」和「并行构建隔离性」的冲突，先解决这个，再谈并行数的事儿会更清晰。

先搞定.m2清理的坑：别全局删！ #

开发要求“每次构建前清理.m2仓库”大概率是个误解——他们真正要的应该是清理当前项目的构建产物（比如target目录），而非整个本地依赖仓库。直接删~/.m2/repository绝对会搞砸同一slave上的并行构建，因为其他正在跑的构建可能正读取依赖包，中途被删直接报错。给你几个替代方案：

• 常规操作：只清项目构建产物：用Maven的mvn clean目标就够了，它只会删除当前项目的target目录，完全不影响全局.m2仓库，这才是构建前清理的正确姿势。
• 强制更新快照依赖：如果开发是担心快照包缓存导致构建不一致，用mvn clean install -U就行，-U参数会强制Maven更新快照依赖，不用删仓库。
• 极端场景：独立本地仓库：如果确实需要彻底隔离每个构建的依赖（比如某些特殊项目必须完全干净的环境），可以在Jenkins构建配置里给每个构建分配专属仓库：
  配置Maven的MAVEN_OPTS添加：-Dmaven.repo.local=/var/jenkins_home/repos/${BUILD_ID}
  这样每个构建都有自己的.m2副本，清理互不影响，但要记得定期清理旧的仓库目录（比如用Jenkins的定时任务删7天前的），避免磁盘爆掉。

单Jenkins Slave的理想并行构建数：没有绝对数，看这3个维度 #

这个得结合你的硬件、项目特性来调，给你几个参考方向：

1. 硬件资源是基础 #

• CPU核心数：一般建议并行数不超过CPU核心数的1.5倍。比如8核的机器，先设6-8个执行者——因为Maven构建既有CPU密集的编译，也有IO密集的依赖下载，适当超一点能利用空闲资源，但太多会导致CPU上下文切换过载，反而变慢。
• 内存：每个微服务构建大概占512MB-2GB内存（取决于项目大小、有没有测试/扫描）。比如16GB内存的机器，扣掉系统和Jenkins本身用的2-4GB，剩下的12GB可以跑6-12个构建（按1GB/个估算）。
• 磁盘IO：如果是机械硬盘或者共享存储，并行数别开太多——依赖下载和文件读写会互相抢IO，拖慢所有构建；用SSD的话可以放宽不少。

2. 微服务的构建特性要考虑 #

• 构建复杂度：如果你的微服务大多包含单元测试、集成测试、Sonar扫描这类耗资源的步骤，并行数要少点（比如4核机器设2-3个）；如果只是简单打包编译，多开几个没问题。
• 依赖缓存率：如果很多项目都是首次构建或者频繁更快照，磁盘IO压力大，并行数不宜过多；如果大部分依赖已经缓存（不管是全局仓库还是独立仓库），可以适当增加。

3. Jenkins配置小技巧 #

• 在Slave节点配置里，通过「Number of executors」（执行者数量）来设置并行数，这就是单slave的最大并行构建数。
• 给Slave打标签（比如low-resource、high-resource），把资源占用低的微服务分配到low-resource节点，高负载的分配到high-resource节点，这样能更高效利用资源。

总结下来的实操步骤 #

1. 先跟开发对齐：把全局清.m2改成mvn clean或者mvn clean install -U，从根源避免并行冲突。
2. 先按「CPU核心数的1倍」设置并行数（比如4核设4个），跑一周观察CPU、内存、磁盘的负载——如果负载经常超80%就减，空闲多就加。
3. 长期来看，建议搞容器化构建（比如Jenkins Docker插件），每个构建在独立容器里跑，自带独立.m2仓库，完全隔离，并行数可以最大化利用硬件，也不用再担心清理冲突。

内容的提问来源于stack exchange，提问作者sam