支撑 1300 万月活的幕后真相：Figma 是怎么把核心服务搬上 EKS 的？

本文由 CloudPilot AI 编译，转载请联系marketing@cloudpilot.ai

近日，设计软件新贵 Figma 正式递交 IPO 申请，有望成为 2025 年规模最大的科技上市案。
2024 年，Figma 实现营收 7.49 亿美元，同比增长 48%；2025 年 Q1 收入达 2.28 亿美元，延续 46% 的高速增长。其平台被广泛应用于 Google Maps、Uber 等知名产品，月活用户超过 1300 万，其中 70% 的收入来自企业级大客户。
作为近年来全球增长最快的 SaaS 公司之一，Figma 在短短四年内营收增长近百倍。凭借在线协同设计的创新模式，它曾吸引 Adobe 抛出 200 亿美元的收购报价。
本文由 Figma 的基础设施团队撰写，解析他们是如何进行技术选型与架构迁移，从而支撑千万级用户访问，保持平台的高性能与高可用性的。
引言

在一家高速成长的公司里，资源显得尤为宝贵。
在 Figma，无论是面向用户的功能还是后端基础设施，我们必须确保所做的每一个决策都能让平台比原先变得更好。
工作流越大、资源需求越高，我们就越需要有信心确保这项工作能够在合理的时间内完成，并且不会对用户造成停机影响。
因此，经过深思熟虑，我们决定将核心服务迁移到 Kubernetes 。以下是我们整个评估、定义范围并执行迁移过程的回顾。
关于 Figma 的计算平台

到 2023 年初，我们已经完成了将所有服务容器化的艰巨工作。
当时我们使用的是 AWS 的 Elastic Container Service（ECS）作为容器编排平台——这是一种开箱即用、能快速启动容器化工作负载的优秀编排平台。
为了扎实地建设这块关键基础设施，我们还组建了专门的团队，并开始系统性地思考如何规划接下来的技术路线，为长期发展打下基础。
也正是在这个阶段，我们开始重新思考下一代“计算平台”的构建方向——也就是支撑 Figma 各团队拥有并运维自己服务的那套底层系统。
我们考虑过在 ECS 的基础上构建新系统，但那样做会让我们难以实现许多长期目标中的关键功能。于是我们开始反思：我们是向一个“局部最优”的路径迭代，还是应该追求“全局最优”？
从更宏观的角度上说，Figma 并不是一家以微服务为核心架构的公司，也无意成为那样的公司。
虽然在某些场景下，比如为了性能隔离或独立部署的需要，我们确实会引入新的服务（比如构建服务用于管理对多个 AI 推理引擎的调用），但整体而言，我们拥有一套强大的核心服务体系，这些服务天然具备模块化与流量隔离的能力。
这意味着我们通常可以通过在现有服务中添加逻辑来支持新产品，而不必创建新的服务。
正因为如此，迁移到 Kubernetes 的想法也变得更加可行：我们并不需要迁移数以千计的微服务，而是在一套相对稳定、可控的核心服务体系上完成架构升级。
ECS 缺失的 K8s 功能

那么，ECS 有哪些局限性呢？
首先，随着服务复杂度的提升，各个服务负责团队不得不投入越来越多的工程时间，去绕过 ECS 平台本身的一些能力瓶颈。
其中最典型的例子，就是我们试图在 ECS 上运行 etcd （一种强一致性的分布式共识数据存储）。
由于 ECS 不支持 Kubernetes 中的 StatefulSets（允许 Pod 拥有持久标识的一种控制器），我们不得不通过在 etcd 的启动流程中嵌入自定义代码，用以动态更新集群成员信息。
这个方案不仅复杂，而且极易出错，维护成本也非常高。
而在 Kubernetes 中运行 etcd，就可以直接使用 StatefulSet 提供的固定网络标识机制，方式更稳定、社区支持也更成熟。
另一个限制是，ECS 无法很好地支持通过 Helm chart 启动一组服务。

Helm 是 Kubernetes 社区中广泛使用的软件打包与分发工具，特别适用于安装开源软件（OSS）。

Figma 内部越来越多的团队希望部署如 Temporal（一个专为现代分布式系统设计的工作流编排平台）这类开源服务，但在 ECS 上安装和运维这些服务会非常困难。
因为我们不得不将每一个 Helm Chart 服务手动转写迁移成 Terraform 模块，用基础设施即代码的方式重写部署逻辑，这在实践中是非常繁琐低效的。
我们还遇到许多令人头疼的小问题，比如：在 ECS on EC2 模式下，当某个 EC2 实例出现问题时，我们很难优雅地移除该节点。
而在 Amazon 的 Elastic Kubernetes Service（EKS）中，这个过程就简单得多：你只需将该节点标记为不可调度（cordon），API 服务器就会将 Pod 安全地迁移至其他机器，同时确保 Pod 的关闭流程被妥善执行。
接入 CNCF 开源生态

除了上述的功能缺失，运行在 ECS 上也让我们错失了云原生计算基金会（Cloud Native Computing Foundation，CNCF ）中丰富的开源技术资源。
当我们开始关注下一代计算平台时，弹性伸缩成为我们优先关注的能力。
那时，我们的容器化服务几乎都没有启用弹性伸缩机制，为了应对高峰期的流量，即使是在夜间或周末流量较低的时候，我们仍然保持所有服务的满负载配置，从而产生了大量不必要的资源浪费和成本开销。
虽然 ECS 提供了一定的自动伸缩支持，但相比之下，Kubernetes 生态拥有更成熟的开源方案，例如 KEDA（Kubernetes Event-driven Autoscaler）。
KEDA 不仅支持基于 CPU 利用率等简单触发条件，还能基于 AWS SQS 队列长度，甚至是来自 Datadog 的自定义指标来触发伸缩，灵活性远远优于 ECS。
除了自动伸缩，我们还预见未来可能会引入某种形式的服务网格（Service Mesh） 。
当时我们是通过 AWS 的应用型负载均衡器 ALB 和网络型负载均衡器 NLB 实现服务之间流量路由的。
这些方式存在一些痛点，例如在 NLB 上注册新目标或移除旧目标可能需要数分钟时间，这会显著拖慢我们应急部署的速度，进而拉高故障修复的平均时间（MTTR）。
相比之下，Envoy 更灵活、更可定制，支持运行自定义过滤器来实现精细化流量控制。
我们其实已经为某个核心服务搭建了一组独立的 Envoy 实例，作为前置代理，用于在故障期间根据定制逻辑进行流量熔断（load shedding）。
因此我们推测，从长远来看，我们将更倾向于在整个平台范围内全面引入 Envoy 构建服务网格。
在 EKS 的世界里，这样的需求并不陌生，开源社区早已有了丰富的解决方案，比如 Istio 等。
而在 ECS 上，我们若想实现同样的功能，就只能“自己动手，丰衣足食”，不仅过程繁琐，还容易埋下技术债。
除了上述自动伸缩和服务网格这两个典型例子，CNCF 生态仍在不断演进和完善。
我们相信，无论是 Kubernetes 本身，还是其周边工具与平台生态，在未来几年内所获得的关注与投资，将远远超过 AWS 对 ECS 的投入。
这背后的根本原因在于：Kubernetes 拥有广泛、开放、去中心化的用户基础。
使用主流平台的优势

我们一向尽量避免成为任何服务或软件的“最大用户”。因为这样的用户，往往最先遇到隐藏的 bug、架构瓶颈以及各种扩展性挑战。
而在使用 Kubernetes 这件事上，我们距离“最大用户”还远着呢。
实际上，很多大型公司都在 Kubernetes 上运行着庞大的计算平台，这让我们更有信心：他们已经帮整个社区踩过不少坑，替我们降低了平台风险，尤其是对于像我们这样运行相对中等规模集群的公司来说。
此外，运行在 Kubernetes 上还能有效避免供应商锁定（vendor lock-in）。
从长期来看，如果你的计算平台足够灵活，具备跨云迁移能力，那么你就能始终为自己争取到更好的供应商选择和更优的价格方案。
Amazon EKS 在这方面提供了一个不错的折中方案：我们既能享受到 AWS 提供的托管控制面带来的便利，又由于我们的服务全部以标准 Kubernetes 接口开发，未来无论是迁移到其他云厂商的 Kubernetes 平台，还是搭建自托管集群，迁移成本都不会太高。
最后，虽然我们相信自己的团队可以快速上手任何技术栈，但事实证明，具备 Kubernetes 实战经验的工程师更加容易找到。
这使他们能够在入职后迅速进入状态，为我们带来成熟的技术背景和决策参考，帮助我们少走弯路。
总之，这不仅是一次技术选型，更是一场“降低未来复杂度、提升团队能力”的战略投资。
确定迁移范围

我们坚信，如果操作得当，这次迁移将显著提升 Figma 的计算平台能力。接下来，我们需要验证的是——能否在一个合理的时间范围内完成这次迁移。
这其中的关键，是对迁移范围的定义要非常谨慎。
对于一次大型迁移来说，最稳妥的做法是：仅替换核心底座系统，并尽可能保持平台用户侧的抽象不变。
也就是说，所有服务仍然以原有方式运行、部署、交互，只是它们的运行环境从 ECS 转为 EKS。
之所以要如此严格，是因为哪怕是看似“非功能性”的小改动，通常也会引发连锁反应，而这些连锁效应，往往才是拖慢整个大迁移进度的元凶。
当然，这条规则也有两个例外：

• 如果为了让新系统具备与旧系统相同的表现或功能，需要投入额外的精力去搭建和适配，可能得不偿失。
  在这种情况下，与其耗费资源伪装旧系统，不如接受一些必要的变化，直接迭代更新。
  幸运的是，我们这次并未遇到太多这类问题，因为 EKS 的功能在很大程度上是 ECS 的超集，原有的大部分功能都能自然承接，无需太多重写或兼容层。
  
• 有些决策属于一锤定音的“单向门”，一旦选定，未来修改将代价极高。 这类情况值得我们在一开始就引入新的设计，而不是严格照搬旧系统。
  

即便我们已经将迁移范围控制得足够精简，这项工作依然需要投入大量时间与资源。
因此，在真正启动迁移之前，我们先明确了一些能够通过此次迁移实现的关键收益，确保整个项目在投入与产出之间具备足够的合理性。
纳入迁移范围的优化事项

<strong>
来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除