快手前端通用静态托管服务 KFX 演进历程：从崎岖土路到平坦高速 原创

快手静态部署托管服务（KFX）历经四年发展，经历了三个阶段，一步步从勉强能行车的“崎岖土路”到现在多车道并行的“平坦高速”，这一转变极大地提升了资源利用率和效率，满足业务的实际需要。本文将带你了解其背后的演进历程。

一、KFX 前端通用静态托管服务

KFX 是什么：KFX 是快手前端通用静态托管服务。

为什么要有 KFX？静态托管服务是前端工程化发展的必然结果。快手前端部署的发展大致经历了这三个阶段：

1.直接在物理机上部署 ng 服务

2.构建带有 ng 服务和静态文件的镜像，通过容器上线

3.通过静态托管服务上线 (KFX)

三个阶段分别代表着前端部署虚拟化和静态托管的演化过程，资源利用率和效率都得到极大的提升。有同学看到这就会觉得，怎么能又省资源又提高效率呢，这是不是不符合 space–time tradeoff 啊？实际上是符合的，因为我们有其他的代价：静态托管服务是对前端这种静态资源部署的场景特化支持， 因此牺牲的是灵活性和通用性，即难以扩展到部署的其他场景，但在前端场景，聚焦于静态部署已经足够满足业务前端的部署要求。

简单总结来讲就是，大家不满足于通过容器部署上线 web 服务，发布的时间实在是太慢了，因此 KFX 出现来解决了这一问题：一条土路建成了。

二、KFX 平台演进过程

初始情况

2022 年春，KX 平台基础的静态托管能力已初步建成，支持静态服务路由/版本变更、回滚操作。集群数 1 个，应用数不到 100 个。

2.1 崎岖山路

土路，意味着能通车了，但是崎岖不平、问题多多。

面临的问题

土路的最大问题就是土。KFX 最初仅支持最核心的静态托管能力，解决大家最痛的效率问题， 把上线时间从容器的分钟级缩短到了秒级，这也是我们最开始的口号。然而崎岖土路的问题可太多了，有时候人家走了一遍，踩到坑里去了，甚至想回去绕远路。具体来说：

问题 1：不好走

土路路面不平整，能达到目的地, 但是走起来真的很费劲。服务总会出现奇奇怪怪的问题导致不好用, 能走但是不好走的问题体现在：

• 业务发布风险高，每次只能全量发布。
• 分布式集群，通信策略设计有问题，偶发出现版本不一致。
• 业务总会因为各种各样的原因上线失败。
• 上线没有审批功能，想什么时候上就什么时候上。
• 应用无权限隔离控制等

这些问题大多是架构设计不合理、功能不健全导致的，就像是路还没修特别好，就开始通车了，出问题也是在所难免的。

问题 2：车道少

土路路面狭窄，难以承载大量或重型车辆，限制了运输效率。KFX 对于多应用，并发大的场景，还没有合适的预案和降级策略。2022 年有一次线上压测问题，就是由于高并发下磁盘写入速度瓶颈问题导致的。从来都没有跑过大车，突然就来了装满水泥的混凝土搅拌车，直接就陷在泥里出不来了。

问题 3：维护成本高

土路需要频繁的维护和修补，尤其是在恶劣天气后。KFX 最初服务稳定性不好，会出现概率性的 OOM， 数据库偶发连接失败等问题。为了临时缓解问题，我们甚至有一段时间设置了凌晨四点固定重启服务🥲。 很多用户反馈的问题并不是用户自己操作的问题，而是平台自身的问题。这也就意味着，在用户自身正确操作的情况下，我们还是会有接不完的 oncall。

解决方案

这一阶段我们的核心工作是“建”，通过对不合理的架构设计进行重构升级，对缺失的核心能力进行补全。

包括重新设计了心跳检测方案、重构了服务发现机制， 接入公司的星环平台，打通了服务目录和权限控制，同时通过接入流程中心提供了审批能力。其中最重要的是，在 pluto 灰度服务的加持下，kfx 具备了灰度发布功能，包含白名单、百分比、泳道等各种小流量发布策略，这是历史性的一步，从此大家发布应用不再是一把梭哈了。

实际情况

2022 年冬，KFX 平台支持灰度发布功能，完成了核心架构的升级。入驻星环平台，作为官方静态部署产品。集群数 3 个，应用数超过 400+，主要覆盖 5 个部门。

2.2 柏油马路

马路，跑的车越来越多，问题也越来越多。

经过大约一年的建设，我们补全了灰度发布功能，支持了白名单、百分比、泳道等各种小流量发布策略。完成了核心架构的升级，从根源上避免了 版本不一致、服务间接性 OOM 等问题。土路的不平整基本上被改造完全, 该填平的填平，该硬化的硬化，KFX 进入了柏油马路阶段。

路好了，车就更多了。2023 年这一年是 KFX 规模化扩张最快的一年，也带来了复杂度的快速提升：我们从 3 个集群，400+个应用，到 23 年底一共 6 个独立的部署集群，1400+个应用。

面临的问题

规模增长，需求也随之增长， 功能不断增加， 为了满足各种功能的自动化需求，我们先后提供了 5 个 流水线 插件，适配了风驰平台（快手前端一站式平台），支持了 html 能力增强 ，支持了 域名容灾、CDN 域名调度、KConf（快手分布式配置中心） 注入、环境标识等功能。规模增长、功能增加，带来的是架构的复杂度不断增加，以及...更多的线上问题。怎么个多法呢，从 23 年 2 月到 7 月，几乎月均一个线上故障。一个复盘文档没写完，就要赶另外一个复盘文档了。一次故障的改进项没做完，下一次就来了😵‍💫😭。

解决方案：稳

路是修宽了点，车多了，故障也上来了，痛啊，怎么办呢？不要紧，总会有办法的。

这一阶段我们的核心工作是“稳 ”，23 年我们启动了 KFX 整体稳定性治理。

（一）KFX 整体稳定性治理

一说到稳定性治理，大家都知道按照事前、事中、事后拆，但是事前事中事后具体要做什么呢？结合 KFX 当前的实际情况，我们整体的规划从规范、架构、工程化和运维四个维度出发，结合事前、事中、事后拆解如下， 共计 20+ 重要事项：

这里展开讲讲 kfx 的自动化 e2e 测试， e2e 测试是我们稳定性建设的核心内容，在今天看起来，也是非常有价值的。

（二）KFX 自动化 e2e 建设

为什么 e2e 测试对于 KFX 服务尤其重要？

1、多种使用场景与复杂的用户行为：

KFX 发展至今，支持了 halo 平台，halo 流水线、kdev 流水线、风驰平台， 多个流水线插件，这些平台和流水线都可以以任何组合方式进行上线部署操作，单个模块或者功能的正确性已经无法保证整体逻辑的正确。一个具体的例子就是 在 2023 H5 容灾域名未替换故障里，就是业务方通过 风驰平台上线，发现问题后使用平台（跨入口操作）进行了快速回滚导致的。  

2、回滚链路稳定性差：

在 KFX 的发布 SOP 中，我们会将新功能先发布至 staging 集群，用户在这里发布自己的 staging 服务（用于业务提测等），大部分功能缺陷支持了 halo 平台，halo 流水线、kdev 流水线、风驰平台，多流水线插件，均可任意组合操作。在这个阶段被发现并及时修复，但往往不包括回滚。因为在 staging 环境下 用户几乎不会使用回滚。但是， 回滚链路不是高频使用链路，但是是核心关键链路，可以说是生命线。用户不用怎么办，我们来找机器人用，因此 e2e 就是一个很好覆盖核心且低频链路的方案。

3、外部依赖与复杂配置：

KFX 集群有 3 个独立部署的服务，服务的上下游除了内部之间通过 ksn/内网域名依赖外，还有上游的网关、终端 cli、流水线、各平台，下游的 blobstore，数据库，kconf 等， 不同急缺依赖的情况还有各自差异化的地方。单个功能的验证正确，并不代表就不会存在其他的潜在影响。e2e 能在 prt 环境对整体集群进行模拟，尽可能的将问题更早的暴露出来。

综上，建设 KFX 的 自动化 e2e 测试是稳定性治理的必然路径。

整体的 e2e 测试架构图如下：

这里核心说明三个点：

（一）全量 case 交叉覆盖：

首先我们枚举了所有用户从所有平台的可能路径，所有的策略类型、变更类型、增强功能。最全的情况是对每一种操作之间进行笛卡尔积，但是这样 case 的数量将会超过三位数，会导致每次运行的时间过长，因此，我们对 case 之间的耦合情况进行划分，相互耦合的 case 需要固定出现，而相互独立的 case 情况则可以作为随机 case 出现。

举一个例子：

版本变更和路由变更是会有耦合的，所以版本（不变/增加/回滚） x 路由（不变/新增/删除/编辑） 这 12 种情况一定需要出现。  然后 kconf 注入功能和 版本路由变更是相互独立的，所以 版本（不变/增加/回滚）x 路由（不变/新增/删除/编辑） x kconf（注入/不注入）不是 24 种情况，而仍然是 12 种情况， 只需要在前 12 种情况中，分别一次注入和不注入，剩下的随机即可。按照这个思路优化，我们得出了核心链路 P0 共 68 个 case。

（二）预发环境混合场景测试

KFX 不是只有一个服务而是多个服务，每次上线的时候 会经历 “新 A 旧 B”的过渡状态，然后才到“新 A 新 B” 的过程， 其中的过渡态也是非常重要的，往往可能会暴露出各种兼容性问题，因此我们在 e2e 的链路上也考虑了这种场景，来做混合测试。如下图所示：

（三）复合链路交叉测试

单条链路的稳定并不能保证整个系统的链路稳定，因为应用是有状态的，链路之间是存在耦合的，上面说的 H5 容灾域名未替换故障里，就是因为 KFC 发布 + 平台回滚导致的问题。因此我们做了链路间的交叉测试，比如对于 流水线发布+默认策略+版本变更的 case， 跑完后在此基础上执行 平台发布+默认策略+版本回滚，之后可以再随机其他的场景 case，通过这样的方式来验证链路间可能的耦合情况。

实际情况

2023 年冬，KFX 平台做了 kfx-api 架构精简化， 建设了自动化 e2e、全链路日志、多集群维度监控等核心功能，保障了服务的稳定性。集群数 6 个，应用数超过 1400+，主要覆盖 10 多个部门。

2.3 高速公路

高速公路比起马路，跑的车又多又快，但是逃不掉的是维护成本

面临的问题

经过一年的稳定性建设，到 24 年，KFX 已经逐步建设成为稳定的公路了，同时朝着高速公路的方向努力。高速公路的特质是高并发、稳定，同时并发量越大，车越多，维护成本就越高，因此有效的控制和降低维护成本也是一个重要的方向。想要建设成为高速公路，做到像高速公路一样又多又稳的跑车，KFX 还需要从下面几个方向做能力扩展，总结来看就是以扩为主要方向，以稳和控为约束方向：

【扩】高吞吐量：支持更多的部署场景，支持更大的并发能力。

【稳】稳定性赋能：除了系统本身的稳定性，作为部署域的解决方案，有责任为业务提供稳定性保障。

【控】运维成本降低：在扩张的前提下，维护成本不能线性增加，我们希望整个系统能够稳定又低成本的运行。

解决方案

这一阶段我们的核心工作是 “扩”：扩宽部署域更多的场景，横向上扩宽部署能力，能支持除静态部署之外的应用，在纵向上，扩展支持线下环境部署，建设更快更好用的测试环境部署方案。

多场景建设（扩）

实施背景：

①测试环境标准化部署

KFX 的静态部署在线上环境的建设，到今天为止已经相对成熟了。但直接将线上环境的方案迁移到测试环境使用，则还是会出现诸多问题，线上环境第一要素是“稳”，测试环境第一要素是“快”。

• 测试环境需要支持快速发布、预览、测试， 直接使用线上的流程会让测试环境变得效率不那么高。
• 测试环境有高频率/高并发/并行的特征。
• 测试环境会复用代理服务，甚至有直接使用 mock 代理后端服务的场景，比如白屏检测、性能检测。

②SSR 场景、node 场景扩展

目前 SSR 在公司还没有一套完善的配套设施，来提供整个从部署、运行到维护链路的解决方案。通常的方案是直接使用容器云，当作一般的 api 服务部署，然而 api 容器部署方案并没有特殊适配 SSR 的场景，会存在以下问题：

• 部署成本高：直接使用容器云， 部署、上线、运维成本相对于 CSR 静态部署陡然提升，
• 场景功能缺失：灰度，白名单，CDN 降级功能需要单独开发

具体方案：

我们通过 LED 与 KFX 结合，提供了测试环境部署域整体的解决方案：即域名 + 代理 + 路由 + 部署 + 运行环境。

核心功能：

• 一键部署：结合 Gundam 工程生态，触发流水线后能自动分配可访问域名并部署可用环境， 完成创建工程后即可部署一个稳定的测试环境。
• 配置化生成代理：由于项目的代理是跨分支复用的，因此可以在工程中以配置的方式进行维护，在流水线执行部署时会根据代理配置自动生成相应域名下的代理。
• 自动化泳道模式：根据插件配置可以切换 主干部署和泳道部署能力， 在泳道模式下，会自动根据分支来设置泳道，同时分配泛域名。此时通过泛域名访问无需注入泳道，方便快速分享。

业务稳定赋能（稳）

实施背景：

KFX 最开始以策略模式作为交互方式，策略模式的功能扩展性更强，能适配更多的场景，但很多的用户都不得不去理解“部署一个默认/灰度策略”是什么意思，为什么一次灰度发布到推全的过程要去上线好几次（发布几个灰度策略，再删除灰度策略，再发布默认策略) 。比起常规的上线单流程，策略模式显得不那么容易理解。

具体方案：

因此，伴随着工程标准化的建设，我们跟商业化一起共建了分级发布的上线模式，并作为标准的能力落地到 KFC 的插件中。

运维成本降低（控）

智能 oncall 接入：

oncall 问题一直都是基建工具躲不掉的工作，除了一部分是能从反馈中转化需求做改进之外，更多咨询类的问题只是纯纯的体力工作。

• 紧跟时代的浪潮，kfx 也拥抱 ai 智能 oncall。在 24 年 Q3，我们接入了 koncall 服务，上线了 KFX AI 小助手，结合 kfx 的实际情况对 AI 的回答质量不断优化调整。 

报警治理：

除用户 oncall 之外，另一个繁重的问题就是报警 oncall，我们每天面临着下面诸多的报警。报警治理主要从两个方向出发，首先识别是否是有效报警。

• 对于有效报警深入分析原因并尽量从根本上解决：
• mysql 连接偶发超时异常，通过数据库从代理改为数据源发现+直连的模式
• 优化实例退出流程，减少服务请求失败的概率
• 优化 dns 逻辑，防止 dns 丢包阻塞进程，导致进程 oom
• 对于无效报警，通过动态调整阈值、调整等级、报警去重等方案转化为有效报警。

从之前周峰值 1000+报警，降低到周均 50 以内。

非活跃服务治理：

kfx 服务上托管的应用随着时间在不断增长，过多的应用会拖慢服务的启动速度，因此需要对长期无流量的应用进行识别并下线。

• 建立 KFX 项目数量管控，常态化项目退出机制
• 处理下线项目数量 469 个，占直接托管项目数量 51%

实际情况

2024 年冬，KFX 平台支持分级部署，支持 api 代理优先模式。集群数 7 个，应用数超过 6000+，主要覆盖 30+个部门。

三、总结与反思

从 22 年开始，KFX 从崎岖土路 一步步走到平坦高速，下面列出了三个阶段的演化。

KFX 的发展历程总体来看是按照渐进式演进的方式发展，在规模化的现状下秉承着稳定性优先的策略，并结合标准化和自动化，朝着降低运维成本和提高系统维护性和观测性的方向做功。

展望未来，KFX 将继续持续演进，以“扩、稳、控”为核心方向，不断优化架构，提升系统稳定性和运维效率，致力于建设更加智能、高效、稳定的服务平台，打造一条真正的“高速公路”，让业务在更快、更稳、更智能的道路上前行。