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

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

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

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

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

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

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

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

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

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

二、KFX平台演进过程

初始情况

2022年春，KFX平台基础的静态托管能力已初步建成，支持静态服务路由/版本变更、回滚操作。集群数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 工程生态，触发流水线后能自动分配可访问域名并部署可用环境，完成创建工程后即可部署一个稳定的测试环境。
配置化生成代理：由于项目的代理是跨分支复用的，因此可以在工程中以配置的方式进行维护，在流水线执行部署时会根据代理配置自动生成相应域名下的代理。
自动化泳道模式：根据插件配置可以切换主干部署和泳道部署能力，在泳道模式下，会自动根据分支来设置泳道，同时分配泛域名。此时通过泛域名访问无需注入泳道，方便快速分享。