快手靜態部署托管服務（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 將繼續持續演進，以“擴、穩、控”為核心方向，不斷優化架構，提升系統穩定性和運維效率，致力于建設更加智能、高效、穩定的服務平臺，打造一條真正的“高速公路”，讓業務在更快、更穩、更智能的道路上前行。