集中式架构的优势：TeamCity 如何解决 Jenkins 的扩展性难题

本文由 draft.dev 的 Aykut Bulgu 提供。

当 Jenkins 安装环境开始显得迟缓时，第一个征兆通常是构建队列。构建任务的排队时间过长，反馈无法及时传达给开发人员，CI 系统开始需要平台团队投入超出预期的精力进行维护。

这种模式对于那些早期采用 Jenkins 并随着业务扩展不断增加规模的团队来说并不陌生。Jenkins 确实具备扩展能力，但在大规模使用时，通常需要谨慎地规划控制器（Controller）规模、管理插件，并且在许多组织中，还需要部署多个控制器来分担负载。这样做虽然可行，但也增加了运营负担。

对于 DevOps 工程师和架构师而言，这种负担至关重要。CI/CD 是交付链路的一部分，当平台变得难以维护时，工程团队会迅速感受到影响。

在本文中，我们将探讨团队在使用 Jenkins 时常遇到的扩展挑战，以及 TeamCity 的服务器-代理（server-agent）架构如何帮助减轻这些运营负担，同时支持从少数几个流水线到数百个流水线的业务增长。

Jenkins 的扩展挑战

从宏观上看，Jenkins 使用的是控制器-代理模型。中央控制器负责管理配置、调度和协调，而代理则负责执行实际的构建任务。TeamCity 同样使用中央服务器和构建代理，因此在高层模式上两者相似。区别在于这两个系统在规模化运行和扩展时的典型方式。

在 Kubernetes 上运行 Jenkins 可以改善代理的配置并使突发容量的管理变得更容易，但这并不能消除管理控制器负载、插件兼容性以及系统治理的需求。

控制器可能成为瓶颈

随着团队、代码库和流水线的增加，Jenkins 控制器承担的工作越来越多：

管理作业（Job）和流水线配置
调度构建并协调代理
提供 UI 界面并处理 API 请求
维护插件状态和运行时行为

在负载较重的情况下，控制器可能成为瓶颈。Jenkins 的文档和生态系统指南通常会引导大型组织采用多控制器策略来分担负载。这虽然有效，但引入了关于治理、版本对齐以及跨团队可见性的额外工作。

水平扩展不仅仅是添加代理

增加更多的 Jenkins 代理可以提高执行能力，但不能解决控制器端的协调和配置挑战。随着团队的壮大，他们往往需要应对：

不同控制器之间插件版本不一致
作业定义和规范不统一
管理凭据、共享库和策略执行时的重复性劳动

到了这一步，扩展 Jenkins 通常意味着需要运营一组控制器、维护共享库，并构建内部流程以保持一切的一致性。

插件依赖增加了运营风险

Jenkins 的灵活性很大程度上源于其插件生态系统。这是它的优势之一，但在规模化时也带来了运营权衡。插件繁多的环境可能会：

产生升级链，即一个插件的更新影响到其他插件
在控制器上增加性能或内存开销
使故障排查变得更加困难，因为行为分布在插件特定的日志和扩展点中

在许多 Jenkins 环境中，平台团队最终会花费大量时间来验证插件更新、检查兼容性以及排查组件之间的交互问题。

TeamCity 的服务器-代理架构

TeamCity 也使用中央服务器和构建代理，但该平台的设计旨在保持配置的集中化，同时让执行能力向外扩展。

TeamCity 服务器负责编排。它存储配置、构建历史和制品元数据，管理队列和依赖关系，并提供 UI 和 REST API。对于生产环境，TeamCity 支持外部数据库，这是扩展大型安装环境的重要组成部分。

[LOADING...] 图片由 Aykut Bulgu 提供

构建代理负责执行。它们检出源代码、运行构建步骤和测试、发布制品和报告，并将结果发送回服务器。

代理是安装在物理机或虚拟机上的独立软件。它们保持与服务器的连接并接收工作分配，这简化了在入站网络受限环境中的部署。

这种分离在实践中非常重要。代理可以进行水平扩展（包括在云环境中），而平台则保留了集中的配置和可见性。

TeamCity 的内置可扩展性功能

除了核心的服务器-代理模型外，TeamCity 还包含了一些功能，帮助团队在无需不断重新设计 CI 系统的情况下进行扩展。

弹性代理与云集成

TeamCity 支持在物理机和云托管机器上运行代理，并可以通过内置云集成和官方支持的插件按需启动云代理。这使得在不永久增加容量的情况下处理需求激增变得更加容易。

想象一个团队通常使用十个本地代理，并在正常工作周内保持构建时间可预测。在大量合并请求被合并后，队列会急剧增长。通过配置云配置文件，TeamCity 可以启动临时云代理，在高峰期减少队列长度，并在需求下降时移除这些临时容量。

从开发者的角度来看，重要的结果是一致性：即使构建量发生变化，反馈速度依然保持合理。

可视化构建链，而非复杂的流水线逻辑

TeamCity 的构建链允许您定义通过快照和制品依赖连接的构建序列和图表。这使得建模流水线变得更加容易，其中工作流的相关部分共享一致的 VCS 快照。

构建链可以模拟如“构建 -> 测试 -> 打包 -> 部署”等工作流，在可能的情况下并行运行依赖构建，并重用制品以避免冗余工作。由于构建链是 TeamCity 的核心概念，团队无需拼接多个扩展程序即可获得依赖可见性，从而能够模拟复杂流程。

Jenkins 流水线确实通过 Jenkinsfile 原生支持多阶段工作流，但在大型安装中，团队通常会将流水线与共享库、控制器特定的约定以及用于编排、可见性或环境处理的额外插件结合使用。TeamCity 的方法则更加明确且集中。

以一个由共享库、后端 API 和前端 SPA 组成的产品为例。在 TeamCity 中，您可以定义一个构建链：首先运行共享库构建，然后分支为后端和前端构建，最后汇总到一个依赖于两者的打包或部署构建中。

该依赖图在 UI 中可见，并作为平台的一部分进行管理，而不是由几个独立的碎片拼凑而成。

智能代理选择

TeamCity 根据需求和能力将构建任务匹配给代理。这有助于资源利用，并减少了随着环境变得更加专业化而带来的手动调度开销。

例如，一个组织可能拥有：

带有 Docker 和 Java 21 的 Linux 代理，用于后端服务
带有 .NET SDK 的 Windows 代理，用于遗留应用程序
带有 Xcode 的 macOS 代理，用于移动端构建

每个构建配置都可以声明其需求：操作系统、已安装的工具链或自定义参数（如 docker.server.osType = linux）或特定的版本要求。

当构建进入队列时，TeamCity 会将其路由到满足这些要求的代理。这使得调度规则保留在配置中，而不是依赖于口头传授的知识或本地约定。

可靠性和可维护性优势

扩展性不仅仅关乎吞吐量，还关乎随着项目数量的增长，保持平台稳定所需的精力。

更少的活动部件

TeamCity 对许多常见工作流提供了开箱即用的支持，因此团队对核心 CI/CD 行为的第三方扩展依赖较少。测试报告、并行测试执行支持、不稳定性测试检测和可视化依赖管理等功能都是产品的一部分。这通常能带来更可预测的升级，并减少因扩展交互而导致的意外。

集中式配置

在拥有多个控制器的 Jenkins 环境中，团队往往会在不同实例间重复配置模式、凭据管理和作业约定。在 TeamCity 中，项目、模板和构建配置都位于单个服务器或少数几个服务器下，这使得在团队间标准化质量门禁、权限和可重用设置变得更加容易。

这种集中化使得治理更易于一致地实施。

简化的升级与更低的停机风险

插件繁多的 Jenkins 环境会将升级变成一项漫长的验证工作。使用 TeamCity，团队通常处理的第三方关键依赖较少，服务器和代理的升级路径更清晰，并且对版本控制拥有集中掌控权。升级仍然需要规划，但运营的覆盖面通常较小。

对 DevOps 工程师和架构师的实际益处

在实践中，这带来了以下几点好处：

降低运营开销： 扩展更多是关于增加或调整代理、审查队列行为和标准化配置，而不是增加更多的控制器并验证庞大的插件组合。
更好的开发反馈循环： 可视化构建链、并行执行和详细报告帮助团队更快地理解失败原因，并保持队列时间的预测性。
更易于管理增长： 随着组织增加服务、语言和交付目标，TeamCity 为平台团队提供了一种无需从头重建治理体系即可增加 CI/CD 容量的集中化方式。

Jenkins 与 TeamCity 对比

下图提供了 Jenkins 和 TeamCity 在大规模运行时的对比概览。