冰火交融：蚂蚁集团通过平台工程加速互联网和金融服务创新

大家好，欢迎大家参加 PlatformCon 2024，我是王子剑，来自蚂蚁集团的平台工程与技术风险部。是的，你没有听错，蚂蚁集团为了把平台工程战略落到实处，特地成立了这样一个部门。在这个后疫情的时代里，推动公司业务的增长和创新变得尤为重要，而我们通过建设自服务开发者平台来提升开发者效率，以加速公司的创新。我目前是公司 PaaS 团队的 Leader，负责内部开发者平台的建设。

蚂蚁集团起步于 2004 年诞生的支付宝，源于一份为社会解决信任问题的初心，经过近二十年的发展，已成为世界领先的互联网开放平台。我们的平台上承载着多元化的业务场景，包括数字支付、数字互联、数字金融，数字科技，以及全球化五大业务集团，我们拥有超过 10000 名的软件开发人员，基于横跨全球的多个地域的基础设施上构建软件，为了保障这样一个复杂而庞大的软件生产体系的高效运作，我们集团在各业务线之下成立了平台技术事业群，而平台工程与技术风险部则在这个组织中腰部的位置，向上支撑业务应用，向下协同计算与 AI 基础设施，为各业务提供高效、安全、且具备技术风险保障的平台技术产品与服务。

这其中最重要挑战源自蚂蚁集团的多元业务场景，我们拥有超过 10 亿用户以及 8000 万商家，每天通过支付宝 App 完成数亿笔交易，同时蚂蚁的数字金融业务服务着中国超过 2000 家金融机构，已累计为超过 5000 万小微经营者提供数字信贷服务。

所以对于蚂蚁的开发者来说，一方面需要考虑互联网业务的高效迭代、快速创新与试错，同时又要考虑数字金融业务的极致稳定、安全与风险防控，而这个本身是一个类似冰与火的矛盾。

同时当前云原生技术生态的繁荣发展，多云基础设施的复杂性也全面暴露给开发者，并伴随着 DevOps、左移运动的发展，也让开发者的责任和认知负荷爆炸，降低了开发者的生产力与效率，并进一步影响公司的创新。

为应对这个挑战，调和冰与火的矛盾并降低开发者的认知负荷，蚂蚁集团制定了平台工程的实施战略，核心包括三点，分别是：统一 PaaS、能力下沉、以及开放协同。

首先，我们建设了服务全业务集团的统一 PaaS 平台产品：九州，统一的控制平面与应用架构约束是全局风险、安全机制落地的必要保障，从服务的用户来说，它最早是蚂蚁的运维平台，主要服务运维和 SRE，而随着 DevOps 运动的发展，我们的用户有 7 成左右是业务应用开发者，所以我们也升级了我们的平台产品策略，将九州升级为 IDP，即内部开发者平台，将开发者作为平台的最终用户，通过构建一站式开发者门户，去持续提升与改善开发者体验，帮助开发者实现软件的高效开发、运维、以及交付，去加速 Time To Market。

其次，与左移运动将复杂性与职责转移给开发者不同，我们通过基于 Kubernetes 与以及云原生技术栈构建我们的平台，持续将风险、安全、可信能力下沉至我们的云原生平台，让这些金融业务需要的更高能力保障与业务应用解耦，尽量做到让业务开发者只关注业务本身，以平衡冰与火的矛盾。

最后，原生内置众多能力以及管理全站所有应用的大一统平台产品，往往会演变成所有客户需求排期的瓶颈，多样化的业务诉求与统一的平台能力很难得到兼顾，部分快速创新的业务场景所需要的平台需求，从全局视角考虑可能不一定是最重要的，但这些局部创新的萌芽也可能代表未来发展的无限潜力。所以开放是统一和下沉之后最重要的战略，我们构建了基于 X as Code 的代码化可编程平台能力界面，并允许 SRE 与平台工程师快速的基于代码化的平台能力，为开发者铺设针对特定场景的黄金路径，在复用平台核心能力的同时，尽可能的满足多元业务发展的需要。

早在 2014-15 年，蚂蚁集团就为了满足运维和技术保障的需要，创建了第一代 PaaS 平台产品：九州 1.0。但随着各多元化业务的飞速发展，不同业务线下的小型平台也开始自发形成，这在全公司范围内形成了许多独立的“烟囱式”架构。这些分散的平台导致了能力水位的不统一，尤其是在处理全局的架构问题上，比如技术风险能力的构建和推广，变得既低效又困难，给业务发展带来了麻烦。

因此，蚂蚁随后启动了 PaaS 平台产品的升级计划，也就是九州 2.0 的建设。它的一大亮点是建立了全局统一的控制平面，不仅实现了从全局应用的元数据管理、发布运维变更的统一，还使各个业务都能享受到统一而高质量的技术风险能力，保障了互联网金融业务的快速发展。但很快，这种统一的平台能力也让业务发展失去了多样性。

所以我们制定了平台工程的战略推进，持续将 PaaS 平台产品升级到了 IDP 内部开发者平台。这一次，我们主要以提升开发者效率为目标，为开发者提供覆盖软件开发生命周期的各类自助服务能力。同时在组织层面，我们升级了 SRE（Site Reliability Engineering，站点可靠性工程）的工作职责，形成了专门的平台工程师团队，这个团队不仅负责风险，也致力于提升效率。平台建设方面也被划分为上下两个部分：底层依托于云原生的核心能力，打造出适用于各种业务场景的通用能力，比如身份、权限、元数据、发布变更、配置和容量等；上层则为 SRE 和平台工程师提供了 Golden Path Builder，使得服务各业务线的 SRE 和平台工程师团队能够基于这些平台核心能力，为不同业务线构建所需的“黄金路径”，满足多元化业务开发者的需求。最终，我们形成了一个分层架构，即平台加上 SRE 和平台工程师共同服务于全蚂蚁的开发者(DEV)，加快了蚂蚁集团全局业务交付的速度（Time To Market）。

在构建了统一的平台的同时，我们致力于将各种技术能力下沉，而运维变更作为软件开发生命周期（SDLC）中的一个重要环节，通过 Kubernetes 的 Operator 机制，重新实现了原有平台的传统运维操作，将这些操作以声明式方式开放给开发者。这样的转变极大地简化了运维流程，有点像自动驾驶：用户只需声明他们想要的目的地，剩下的过程交给汽车，也就是平台去自动完成。

显然这是一种理想情况，所以与社区的各类 K8S Workload 不同，我们开发了自己的工作负载及云原生资源扩展，例如 CollaSet，PodDecoration 与 OperationJob，他们分别用来管理应用 Workload、Sidecar 以及传统的过程式的运维命令，这些被统一抽象为 Kubernetes 资源进行管理，并且与蚂蚁的技术风险体系相结合，实现了技术风险能力的下沉，包括水位保护、变更规则和熔断机制。

对于 Pod 的生命周期管理，我们通过 PodOpsLifecycle 进行了扩展，将 Pod 和容器的状态管理内置于所有工作负载中。这使得平台开发者能够在 Pod 操作的关键阶段实施必要的控制，实现更细致的自动化管理。例如，在执行 Pod 操作之前，从流量路由中移除 Pod 的 IP 以保证操作的平滑进行，并在操作完成后将其重新添加，以此来保证服务的连续性和防止流量丢失。

从稳定性的角度来看，蚂蚁集团大约 60% 的故障都是由变更引起的。而全局统一的声明式运维变更，不仅提高了开发者的工作效率，还为统一的技术风险保障提供了极佳的切入点。因此，我们开发了云原生变更防御产品：Alter Shield。

一方面，我们定义了 Open Change Management Specification（开放变更管理规范）协议，以标准化变更信息，并通过平台进行定义和管理。另一方面，平台实现了一个跨多环境 SDLC 的统一变更 Pipeline，自动化地将规模化的变更分批处理和金丝雀发布，并在每个变更批次的前后添加 Hook。这些 Hook 与变更 Policy 相连，能够执行变更影响面分析、变更阻断以及检查业务和系统指标。

在早期这些策略，大部分由 SRE 编写，目的是实现全局的风险防控；随着平台工程战略的实施以及开发者效率提升方向的转变，我们也将变更策略开放给开发者去编写，例如，声明策略表示如果在变更过程中遇到某业务指标下滑，平台可以自动回滚变更或采取其他操作，实现变更过程的无人值守，为开发者提供了高效变更的信心保障。

效率、风险和安全共同构成了我们平台核心指标的“铁三角”。在这个体系中，IAM 系统是平台权限和访问控制管理的核心。一方面，IAM 负责管理和颁发全局统一的身份，同时还建立和维护了一套蚂蚁集团的组织和资源拓扑结构，以构建资源图（Resource Graph）。基于这个资源图，我们实现了权限审批的自动化推导，目的是减少开发者申请权限的频次。

同时，在对密钥（Secret）的管理和应用程序权限申请，以及基于策略的访问控制方面，我们也利用了云原生机制实现了这整套能力的下沉。

例如，我们基于 Kubernetes 实现了透明的身份注入机制，在 POD 创建时，为每个容器透明地注入身份，并依托于 Distributed App Runtime Sidecar，将分布式应用的外部调用和互联通信下沉至 Sidecar 与应用解耦。通过这种方式，分布式应用运行时基于注入的身份进行外部服务调用的访问控制和链路加密。值得一提的是，所有这些安全能力对应用来说都是透明的。因此，我们将这套技术体系命名为 Trust-Native，意在强调我们平台的安全可信能力是原生内置的，并实现了效率与安全的平衡。

最终，我们将平台的所有能力进行了代码化，并以 Kusion 平台编排器为核心构建了平台内核能力。我们通过一个可扩展的 Drivers 机制向下连接各类基础设施，不仅限于 Kubernetes，还包括其他各种基础设施。基于CNCF Sandbox 项目 KCL（Kusion Configuration Language）和配置大库，我们为用户提供了一致、高效且安全的可编程接口。此外，各个上层团队可以利用这些可复用的配置代码，构建满足特定场景需求的新配置模型，从而形成了丰富的 KCL 配置生态。

在初始阶段，我们的首要目标是实现蚂蚁基础设施的全面代码化，旨在加快 IaC（基础设施即代码）战略的实施和落地。然而，应用的各类配置都混合在一起，开发者逐渐发现编写基础设施配置代码既困难又低效，我们收到了大量的反馈，并从这些经验中吸取教训，我们基于开发者、SRE和平台工程师之间的日常工作分工和协作，定义并实现关注点的分离。通过借鉴 DCM（Dynamic Configuration Management），我们升级了整个 Kusion 配置模型及平台编排器。

升级后的模型区分了应用配置与部署、环境相关的配置。从分工上，全局配置和环境特定配置，特别是蚂蚁多年来积累的复杂的单元化部署配置，都由 SRE 配置和维护，并选择生效的应用与环境范围。

相应的，开发者仅需定义与应用本身相关的工作负载配置。当配置推送给 Kusion 时，Kusion 会自动根据之前定义的配置生效范围将两者关联起来，并动态生成最终的配置，然后推送给基础设施。这大大降低了开发者对各类领域配置的感知。当然，蚂蚁集团的单元化部署体系历史悠久，深入到基础设施的方方面面，这项工作随着我们平台工程战略的实施持续在进行，最终的目标是让开发者彻底不感知单元化部署相关的配置。

我们已经部分开源了我们的平台能力，这包括 KusionStack 以及 AlterShield 项目。KusionStack 是一个平台工程技术栈，旨在帮助平台工程师构建自己的 IDP (Internal Development Platform）。而 AlterShield 则是蚂蚁集团技术风险体系中变更防御功能的开源实现。未来，我们也计划开源更多平台能力，这里是相关链接，欢迎大家加入我们的社区。

• 网站：
  - https://kusionstack.io
  - https://altershield.io
  

• Github:
  - https://github.com/KusionStack/
  - https://github.com/traas-stack/
  

• Twitter

  @KusionStack

• Slack

  https://join.slack.com/t/kusionstack/shared_invite/zt-2drafxksz-VzCZZwlraHP4xpPeh_g8lg

• 钉钉群

  42753001