Harness Engineering • LinyingBlog

从架构视角深入解读 Harness 的设计哲学，帮助工程师建立对现代 CI/CD 平台的认知框架

一、Harness 到底是什么#

一句话：Harness 是一个构建在 Kubernetes 之上的、以 Delegate 为核心执行引擎的、SaaS 化的软件交付平台。

这句话里有三个关键词，每一个都值得展开。

1. 构建在 Kubernetes 之上#

Harness 的控制平面（Control Plane）是一组微服务，运行在 Kubernetes 集群中。这意味着：

弹性伸缩是天然能力，不是事后补丁
多租户隔离通过 K8s 的 namespace 和资源配额实现
服务治理依赖 K8s 原生的服务发现和负载均衡

这不是什么了不起的事——几乎所有现代 SaaS 产品都跑在 K8s 上。但关键在于，Harness 把 K8s 的能力向下暴露给了用户：你的 Pipeline 可以直接操作 K8s 集群进行部署，而不是通过一层中间转换。

2. Delegate 是核心执行引擎（重点）#

这是理解 Harness 最关键的一个概念。

Delegate 是一个运行在你基础设施中的进程，负责执行 Pipeline 中的所有任务。它不是 Harness 帮你跑的——它跑在你的环境里。

为什么要这样设计？因为软件交付涉及的操作，绝大多数都需要访问内网资源：代码仓库、制品库、K8s 集群、数据库、云账号。如果这些操作全部由 Harness 的 SaaS 控制平面来执行，就意味着你的内网资源必须对 Harness 开放——这在安全合规层面几乎不可接受。

Delegate 的架构解决了这个问题：

┌─────────────────────────────────────────────────────┐
│                Harness SaaS控制平面                  │
│         (Pipeline 编排、状态管理、UI、API)             │
└──────────────────────┬──────────────────────────────┘
                       │  出站连接（Delegate 主动拉取任务）
                       │  ← 不需要入站端口暴露
┌──────────────────────▼──────────────────────────────┐
│                   你的基础设施                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐           │
│  │ Delegate │  │ Delegate │  │ Delegate │←可部署多个  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘           │
│       │             │             │                 │
│   ┌───▼───┐    ┌────▼───┐    ┌────▼───┐             │
│   │K8s集群 │    │代码仓库 │    │云账号   │             │
│   └───────┘    └────────┘    └────────┘             │
└─────────────────────────────────────────────────────┘

核心设计要点：

出站连接：Delegate 主动向 Harness 控制平面轮询任务，不需要你开放任何入站端口。你的防火墙规则可以保持严格。
任务执行：Delegate 收到任务后，在你的内网环境中执行——访问你的代码仓库、推送到你的 K8s 集群、调用你的云 API。
无状态设计：Delegate 本身不保存状态，可以水平扩展。多个 Delegate 组成一个 Delegate Group，自动负载均衡。
自动升级：Delegate 定期检查新版本并自动更新，不需要手动运维。

这个设计的精妙之处在于：Harness 看到了你的 Pipeline 定义和执行结果，但从未直接触达你的内网资源。所有敏感操作都在你的边界内完成。这满足了大多数企业的安全合规要求。

3. SaaS 化的软件交付平台#

Harness 的默认形态是 SaaS——控制平面由 Harness 团队运维，你只需要部署 Delegate。当然也有 Self-Managed Platform（即私有化部署），但 SaaS 是其主推模型。

这意味着：

你不需要运维 CI/CD 基础设施本身（Jenkins Master 的运维痛点彻底消失）
版本升级对用户透明（对比 Jenkins 的插件兼容性噩梦）
多租户天然支持（团队隔离不需要额外配置）

二、Pipeline 的抽象模型#

理解了 Delegate，再来看 Harness 的 Pipeline 是怎么组织的。

Harness 的 Pipeline 采用四层抽象：

Pipeline（流水线）
  └── Stage（阶段）
        └── Step（步骤）
              └── Step Group（步骤组，可选）

每一层的职责：

Pipeline：一次完整的软件交付流程。通常对应一次代码提交从构建到部署的全过程。
Stage：Pipeline 中的一个逻辑阶段。常见类型有 Build（构建）、Deploy（部署）、Approval（审批）、Custom（自定义）。
Step：Stage 中的一个原子操作。比如"执行 Shell 脚本"、“推送镜像”、“滚动更新 K8s Deployment”。
Step Group：一组可复用的 Step 集合，类似于函数封装。

这个模型和 Jenkins Pipeline 的 Stage → Step 模型很像，但有一个关键区别：Harness 的每一层抽象都有独立的失败策略、回滚逻辑和条件执行控制。你可以在 Stage 级别定义"如果失败则回滚到上一个版本"，而不是在每个 Step 里写 try-catch。

Infrastructure Definition：部署目标的声明式描述#

Harness 有一个独特的概念叫 Infrastructure Definition，它声明式地描述"这次部署的目标环境是什么"。

比如，一个 K8s 部署的 Infrastructure Definition 会声明：

目标集群是哪个（通过 Cloud Provider Connector 关联）
目标 namespace 是什么
Release Name 的前缀是什么

这个设计的好处是：Pipeline 的逻辑和部署目标解耦了。同一个 Pipeline 可以通过切换 Infrastructure Definition，部署到 dev、staging、prod 三个环境，不需要维护三份 Pipeline 配置。

三、Connector 机制：如何连接外部世界#

Harness 需要和很多外部系统交互：GitHub、Docker Hub、AWS、K8s 集群、Slack……这些连接通过 Connector 统一管理。

Connector 的核心设计原则是凭证与使用分离：

Connector 定义：存储在 Harness 控制平面，包含连接 URL、认证方式（SSH Key、Token、IAM Role 等）、连接测试逻辑。
实际连接：由 Delegate 在你的内网环境中执行。Connector 的凭证信息会被传递给 Delegate，但连接动作发生在你的网络边界内。

这意味着：你往 Harness 里存的是"怎么连"的描述，而不是让 Harness 直接连。实际的网络握手在你自己的环境里完成。

常见的 Connector 类型：

Source Code Connector：GitHub、GitLab、Bitbucket，用于拉取代码
Artifact Connector：Docker Registry、JFrog Artifactory、Nexus，用于推送/拉取构建产物
Cloud Provider Connector：AWS、GCP、Azure，用于调用云 API
Kubernetes Cluster Connector：直接关联 K8s 集群的 kubeconfig 或 Service Account
Notification Connector：Slack、Email、PagerDuty，用于发送通知

四、Harness vs Jenkins：架构层面的本质差异#

很多对比文章停留在"Jenkins 有 1800+ 插件，Harness 没有"这种层面。这没有意义。我们需要从架构层面理解两者的本质差异。

4.1 执行模型#

Jenkins：Master-Agent 架构。Master 负责调度和状态管理，Agent 负责执行。Master 是单点——它挂了，整个 CI/CD 就停了。即使配置了 HA，本质上也是 Active-Passive，资源利用率低。

Harness：控制平面是分布式微服务，无单点。执行层是 Delegate，无状态且可水平扩展。不存在"Master 挂了全部停摆"的问题。

4.2 安全模型#

Jenkins：Agent 需要能被 Master 访问（入站连接）。如果 Master 在云上、Agent 在内网，你需要打通网络隧道或暴露端口。Jenkins 凭证存储在 Master 的文件系统上，历史上多次出现凭证泄露漏洞。

Harness：Delegate 主动出站连接，不需要入站端口。凭证存储在 Harness 控制平面（加密），但实际使用凭证的操作在 Delegate 端完成。攻击面显著更小。

4.3 配置管理#

Jenkins：Pipeline 定义用 Jenkinsfile（Groovy DSL）。Groovy 是一门完整的编程语言，这意味着 Jenkinsfile 可以写得极其灵活，也可以写得极其难以维护。没有 Schema 校验，错误在运行时才发现。

Harness：Pipeline 定义用 YAML。YAML 是声明式的，有明确的 Schema，可以在提交前校验。灵活性不如 Groovy，但一致性和可审计性更好。

4.4 插件 vs 原生能力#

Jenkins：核心是一个调度引擎，几乎所有能力都靠插件实现。插件质量参差不齐，版本兼容性是噩梦（Jenkins 升级大版本时，插件大面积挂掉是常态）。

Harness：核心能力（CI、CD、Feature Flags、SLO 管理、云成本管理、安全测试编排、IaC 管理、开发者门户、混沌工程）是平台原生的，不是插件。这意味着版本一致性有保障，但灵活性受限——你不能像 Jenkins 那样写一个自定义插件来扩展能力。

4.5 可观测性#

Jenkins：原生可观测性很弱。你需要额外部署 Prometheus + Grafana 来监控 Jenkins 本身，再用 ELK 来聚合构建日志。

Harness：内置部署可观测性（Service Reliability Management）。Pipeline 的每次执行都有完整的审计日志、执行时间线、失败分析。和外部 APM 工具（Datadog、New Relic）的集成是原生支持的。

4.6 总结对比#

维度	Jenkins	Harness
架构	Master-Agent（中心化）	控制平面 + Delegate（分布式）
安全模型	入站连接，凭证存本地	出站连接，凭证加密存储
配置语言	Groovy DSL（图灵完备）	YAML（声明式）
能力扩展	插件生态（1800+）	平台原生能力
可观测性	需要额外搭建	内置
运维成本	高（Master 运维、插件管理）	低（SaaS 托管、Delegate 自动升级）

五、从 Jenkins 迁移到 Harness：你需要知道的事#

如果你的团队正在考虑从 Jenkins 迁移到 Harness，以下几个点值得提前了解：

5.1 迁移不是 1:1 翻译#

Jenkinsfile 里的 Groovy 逻辑（条件判断、循环、共享库调用）不能直接翻译成 Harness YAML。你需要重新设计 Pipeline 的抽象层次——哪些是 Stage，哪些是 Step Group，哪些逻辑应该下沉到 Delegate 端的脚本里。

5.2 Harness 不是免费的#

Jenkins 是开源免费的（运维成本除外）。Harness SaaS 是按消费计费的——基于构建分钟数、部署次数、Feature Flag 请求数等维度。你需要评估你的使用量对应的费用，而不是假设"换工具就能省钱"。

5.3 Delegate 的运维成本#

虽然 Delegate 会自动升级，但它仍然跑在你的基础设施上。你需要监控它的资源使用（CPU、内存、网络），确保它不会影响你的业务服务。在大规模场景下，Delegate Group 的容量规划是一个需要认真对待的问题。

5.4 学习曲线是真实的#

Harness 的概念模型（Pipeline/Stage/Step/Infrastructure Definition/Connector/Delegate）比 Jenkins 的概念模型（Job/Stage/Step/Agent）更丰富。团队需要时间来建立新的心智模型。

六、心理认知准备：面对新范式的正确姿态#

6.1 认清范式转移的本质#

CI/CD 工具的演进不是线性的功能迭代，而是范式转移：

第一代：脚本时代。Shell 脚本 + Cron，手动编排。
第二代：自动化服务器。Jenkins 为代表，“一切皆可插件”。
第三代：软件交付平台。Harness 为代表，“一切皆是平台能力”。

每一代迁移都不是"旧工具的升级"，而是思维方式的改变。从 Jenkins 到 Harness，你需要放弃"什么都能自定义"的执念，接受"平台已经帮你做好了大多数决策"的现实。

6.2 工程师的三种认知陷阱#

陷阱一：工具熟悉度 = 工具优越性

用惯了 Jenkins 的工程师会本能地认为 Jenkins “更好”——因为他们已经踩过坑、建立了心智模型、知道怎么绕过问题。但"我熟悉"和"它更好"是两回事。评估新工具时，需要把熟悉度带来的偏见剥离掉。

陷阱二：灵活性崇拜

“Jenkins 什么都能做"是真的，但"什么都能做"也意味着"什么都要自己做”。Harness 的限制性恰恰是它的优势——它帮你做出了大量架构决策，你不需要在 Groovy 脚本里重新发明轮子。

陷阱三：迁移恐惧

“迁移太麻烦了，不如继续用 Jenkins。“这种想法在短期内是理性的，但长期来看，技术债务会累积。Jenkins 的插件维护成本、Master 的运维成本、安全漏洞的修复成本，这些隐性成本往往被低估。

6.3 建立正确的评估框架#

在决定是否迁移到 Harness 之前，建议从以下维度评估：

安全合规需求：你的行业对安全合规的要求有多严格？Delegate 的出站连接模型是否能显著降低你的合规风险？
团队规模：小团队（< 10 人）可能不需要 Harness 的全部能力，Jenkins + 云托管方案可能更经济。大团队（> 50 人）的运维成本和协作复杂度会显著放大 Harness 的价值。
多云/混合云需求：如果你的部署目标跨越多个云平台或混合云环境，Harness 的 Connector 和 Infrastructure Definition 模型会大幅降低管理复杂度。
预算：评估 Harness 的定价模型是否适合你的使用模式。高频率、小规模的 CI 场景可能不划算；低频率、高复杂度的 CD 场景价值更大。

6.4 CNCF 平台工程白皮书的启示#

CNCF 平台白皮书对平台工程的定义是：

平台工程是设计和构建工具链与工作流的学科，为云原生时代的软件工程组织提供自助服务能力。平台工程提供集成产品（通常称为"内部开发者平台”），贯穿软件生命周期的每个阶段。

Harness 的设计哲学与此高度一致：它不是一个 CI 工具或 CD 工具，而是一个平台——它把 CI、CD、Feature Flags、SLO 管理、安全测试、成本管理、开发者门户整合在一起，提供统一的自助服务体验。

理解这一点很重要：你不是在选一个 Jenkins 的替代品，你是在评估一个平台工程战略是否适合你的组织。

总结#

Harness 的架构设计有三个核心支柱：

Delegate 模型：把执行引擎放在用户环境中，解决了安全合规的根本问题
声明式 Pipeline：用 YAML 替代 Groovy，用 Schema 校验替代运行时错误
平台化整合：把 CI/CD 之外的能力（安全、成本、可靠性）纳入同一个平台

这三个支柱共同构成了一个和 Jenkins 截然不同的软件交付范式。理解这个范式，比记住 Harness 有哪些产品模块重要得多。

作为工程师，面对范式转移时最有价值的心态是：不预设结论，但带着框架去评估。 这篇文章给你的框架是架构层面的——Delegate 是怎么工作的、Pipeline 是怎么组织的、安全模型是怎么设计的。带着这些认知去试用 Harness，你会比"看功能清单"更快地判断它是否适合你的团队。