快手靜態(tài)部署托管服務(wù)（KFX）歷經(jīng)四年發(fā)展，經(jīng)歷了三個(gè)階段，一步步從勉強(qiáng)能行車的“崎嶇土路”到現(xiàn)在多車道并行的“平坦高速”，這一轉(zhuǎn)變極大地提升了資源利用率和效率，滿足業(yè)務(wù)的實(shí)際需要。本文將帶你了解其背后的演進(jìn)歷程。

一、KFX 前端通用靜態(tài)托管服務(wù)

KFX 是什么：KFX 是快手前端通用靜態(tài)托管服務(wù)。

為什么要有 KFX？靜態(tài)托管服務(wù)是前端工程化發(fā)展的必然結(jié)果。快手前端部署的發(fā)展大致經(jīng)歷了這三個(gè)階段：

1.直接在物理機(jī)上部署 ng 服務(wù)

2.構(gòu)建帶有 ng 服務(wù)和靜態(tài)文件的鏡像，通過容器上線

3.通過靜態(tài)托管服務(wù)上線 (KFX)

三個(gè)階段分別代表著前端部署虛擬化和靜態(tài)托管的演化過程，資源利用率和效率都得到極大的提升。有同學(xué)看到這就會覺得，怎么能又省資源又提高效率呢，這是不是不符合 space–time tradeoff ??？實(shí)際上是符合的，因?yàn)槲覀冇衅渌拇鷥r(jià)：靜態(tài)托管服務(wù)是對前端這種靜態(tài)資源部署的場景特化支持， 因此犧牲的是靈活性和通用性，即難以擴(kuò)展到部署的其他場景，但在前端場景，聚焦于靜態(tài)部署已經(jīng)足夠滿足業(yè)務(wù)前端的部署要求。

簡單總結(jié)來講就是，大家不滿足于通過容器部署上線 web 服務(wù)，發(fā)布的時(shí)間實(shí)在是太慢了，因此 KFX 出現(xiàn)來解決了這一問題：一條土路建成了。

二、KFX 平臺演進(jìn)過程

初始情況

2022 年春，KX 平臺基礎(chǔ)的靜態(tài)托管能力已初步建成，支持靜態(tài)服務(wù)路由/版本變更、回滾操作。集群數(shù) 1 個(gè)，應(yīng)用數(shù)不到 100 個(gè)。

2.1 崎嶇山路

土路，意味著能通車了，但是崎嶇不平、問題多多。

面臨的問題

土路的最大問題就是土。KFX 最初僅支持最核心的靜態(tài)托管能力，解決大家最痛的效率問題， 把上線時(shí)間從容器的分鐘級縮短到了秒級，這也是我們最開始的口號。然而崎嶇土路的問題可太多了，有時(shí)候人家走了一遍，踩到坑里去了，甚至想回去繞遠(yuǎn)路。具體來說：

問題 1：不好走

土路路面不平整，能達(dá)到目的地, 但是走起來真的很費(fèi)勁。服務(wù)總會出現(xiàn)奇奇怪怪的問題導(dǎo)致不好用, 能走但是不好走的問題體現(xiàn)在：

• 業(yè)務(wù)發(fā)布風(fēng)險(xiǎn)高，每次只能全量發(fā)布。
• 分布式集群，通信策略設(shè)計(jì)有問題，偶發(fā)出現(xiàn)版本不一致。
• 業(yè)務(wù)總會因?yàn)楦鞣N各樣的原因上線失敗。
• 上線沒有審批功能，想什么時(shí)候上就什么時(shí)候上。
• 應(yīng)用無權(quán)限隔離控制等

這些問題大多是架構(gòu)設(shè)計(jì)不合理、功能不健全導(dǎo)致的，就像是路還沒修特別好，就開始通車了，出問題也是在所難免的。

問題 2：車道少

土路路面狹窄，難以承載大量或重型車輛，限制了運(yùn)輸效率。KFX 對于多應(yīng)用，并發(fā)大的場景，還沒有合適的預(yù)案和降級策略。2022 年有一次線上壓測問題，就是由于高并發(fā)下磁盤寫入速度瓶頸問題導(dǎo)致的。從來都沒有跑過大車，突然就來了裝滿水泥的混凝土攪拌車，直接就陷在泥里出不來了。

問題 3：維護(hù)成本高

土路需要頻繁的維護(hù)和修補(bǔ)，尤其是在惡劣天氣后。KFX 最初服務(wù)穩(wěn)定性不好，會出現(xiàn)概率性的 OOM， 數(shù)據(jù)庫偶發(fā)連接失敗等問題。為了臨時(shí)緩解問題，我們甚至有一段時(shí)間設(shè)置了凌晨四點(diǎn)固定重啟服務(wù)??。 很多用戶反饋的問題并不是用戶自己操作的問題，而是平臺自身的問題。這也就意味著，在用戶自身正確操作的情況下，我們還是會有接不完的 oncall。

解決方案

這一階段我們的核心工作是“建”，通過對不合理的架構(gòu)設(shè)計(jì)進(jìn)行重構(gòu)升級，對缺失的核心能力進(jìn)行補(bǔ)全。

包括重新設(shè)計(jì)了心跳檢測方案、重構(gòu)了服務(wù)發(fā)現(xiàn)機(jī)制， 接入公司的星環(huán)平臺，打通了服務(wù)目錄和權(quán)限控制，同時(shí)通過接入流程中心提供了審批能力。其中最重要的是，在 pluto 灰度服務(wù)的加持下，kfx 具備了灰度發(fā)布功能，包含白名單、百分比、泳道等各種小流量發(fā)布策略，這是歷史性的一步，從此大家發(fā)布應(yīng)用不再是一把梭哈了。

實(shí)際情況

2022 年冬，KFX 平臺支持灰度發(fā)布功能，完成了核心架構(gòu)的升級。入駐星環(huán)平臺，作為官方靜態(tài)部署產(chǎn)品。集群數(shù) 3 個(gè)，應(yīng)用數(shù)超過 400+，主要覆蓋 5 個(gè)部門。

2.2 柏油馬路

馬路，跑的車越來越多，問題也越來越多。

經(jīng)過大約一年的建設(shè)，我們補(bǔ)全了灰度發(fā)布功能，支持了白名單、百分比、泳道等各種小流量發(fā)布策略。完成了核心架構(gòu)的升級，從根源上避免了 版本不一致、服務(wù)間接性 OOM 等問題。土路的不平整基本上被改造完全, 該填平的填平，該硬化的硬化，KFX 進(jìn)入了柏油馬路階段。

路好了，車就更多了。2023 年這一年是 KFX 規(guī)模化擴(kuò)張最快的一年，也帶來了復(fù)雜度的快速提升：我們從 3 個(gè)集群，400+個(gè)應(yīng)用，到 23 年底一共 6 個(gè)獨(dú)立的部署集群，1400+個(gè)應(yīng)用。

面臨的問題

規(guī)模增長，需求也隨之增長， 功能不斷增加， 為了滿足各種功能的自動化需求，我們先后提供了 5 個(gè) 流水線 插件，適配了風(fēng)馳平臺（快手前端一站式平臺），支持了 html 能力增強(qiáng) ，支持了 域名容災(zāi)、CDN 域名調(diào)度、KConf（快手分布式配置中心） 注入、環(huán)境標(biāo)識等功能。規(guī)模增長、功能增加，帶來的是架構(gòu)的復(fù)雜度不斷增加，以及...更多的線上問題。怎么個(gè)多法呢，從 23 年 2 月到 7 月，幾乎月均一個(gè)線上故障。一個(gè)復(fù)盤文檔沒寫完，就要趕另外一個(gè)復(fù)盤文檔了。一次故障的改進(jìn)項(xiàng)沒做完，下一次就來了???????。

解決方案：穩(wěn)

路是修寬了點(diǎn)，車多了，故障也上來了，痛啊，怎么辦呢？不要緊，總會有辦法的。

這一階段我們的核心工作是“穩(wěn) ”，23 年我們啟動了 KFX 整體穩(wěn)定性治理。

（一）KFX 整體穩(wěn)定性治理

一說到穩(wěn)定性治理，大家都知道按照事前、事中、事后拆，但是事前事中事后具體要做什么呢？結(jié)合 KFX 當(dāng)前的實(shí)際情況，我們整體的規(guī)劃從規(guī)范、架構(gòu)、工程化和運(yùn)維四個(gè)維度出發(fā)，結(jié)合事前、事中、事后拆解如下， 共計(jì) 20+ 重要事項(xiàng)：

這里展開講講 kfx 的自動化 e2e 測試， e2e 測試是我們穩(wěn)定性建設(shè)的核心內(nèi)容，在今天看起來，也是非常有價(jià)值的。

（二）KFX 自動化 e2e 建設(shè)

為什么 e2e 測試對于 KFX 服務(wù)尤其重要？

1、多種使用場景與復(fù)雜的用戶行為：

KFX 發(fā)展至今，支持了 halo 平臺，halo 流水線、kdev 流水線、風(fēng)馳平臺， 多個(gè)流水線插件，這些平臺和流水線都可以以任何組合方式進(jìn)行上線部署操作，單個(gè)模塊或者功能的正確性已經(jīng)無法保證整體邏輯的正確。一個(gè)具體的例子就是 在 2023 H5 容災(zāi)域名未替換故障里，就是業(yè)務(wù)方通過 風(fēng)馳平臺上線，發(fā)現(xiàn)問題后使用平臺（跨入口操作）進(jìn)行了快速回滾導(dǎo)致的。  

2、回滾鏈路穩(wěn)定性差：

在 KFX 的發(fā)布 SOP 中，我們會將新功能先發(fā)布至 staging 集群，用戶在這里發(fā)布自己的 staging 服務(wù)（用于業(yè)務(wù)提測等），大部分功能缺陷支持了 halo 平臺，halo 流水線、kdev 流水線、風(fēng)馳平臺，多流水線插件，均可任意組合操作。在這個(gè)階段被發(fā)現(xiàn)并及時(shí)修復(fù)，但往往不包括回滾。因?yàn)樵?staging 環(huán)境下 用戶幾乎不會使用回滾。但是， 回滾鏈路不是高頻使用鏈路，但是是核心關(guān)鍵鏈路，可以說是生命線。用戶不用怎么辦，我們來找機(jī)器人用，因此 e2e 就是一個(gè)很好覆蓋核心且低頻鏈路的方案。

3、外部依賴與復(fù)雜配置：

KFX 集群有 3 個(gè)獨(dú)立部署的服務(wù)，服務(wù)的上下游除了內(nèi)部之間通過 ksn/內(nèi)網(wǎng)域名依賴外，還有上游的網(wǎng)關(guān)、終端 cli、流水線、各平臺，下游的 blobstore，數(shù)據(jù)庫，kconf 等， 不同急缺依賴的情況還有各自差異化的地方。單個(gè)功能的驗(yàn)證正確，并不代表就不會存在其他的潛在影響。e2e 能在 prt 環(huán)境對整體集群進(jìn)行模擬，盡可能的將問題更早的暴露出來。

綜上，建設(shè) KFX 的 自動化 e2e 測試是穩(wěn)定性治理的必然路徑。

整體的 e2e 測試架構(gòu)圖如下：

這里核心說明三個(gè)點(diǎn)：

（一）全量 case 交叉覆蓋：

首先我們枚舉了所有用戶從所有平臺的可能路徑，所有的策略類型、變更類型、增強(qiáng)功能。最全的情況是對每一種操作之間進(jìn)行笛卡爾積，但是這樣 case 的數(shù)量將會超過三位數(shù)，會導(dǎo)致每次運(yùn)行的時(shí)間過長，因此，我們對 case 之間的耦合情況進(jìn)行劃分，相互耦合的 case 需要固定出現(xiàn)，而相互獨(dú)立的 case 情況則可以作為隨機(jī) case 出現(xiàn)。

舉一個(gè)例子：

版本變更和路由變更是會有耦合的，所以版本（不變/增加/回滾） x 路由（不變/新增/刪除/編輯） 這 12 種情況一定需要出現(xiàn)。  然后 kconf 注入功能和 版本路由變更是相互獨(dú)立的，所以 版本（不變/增加/回滾）x 路由（不變/新增/刪除/編輯） x kconf（注入/不注入）不是 24 種情況，而仍然是 12 種情況， 只需要在前 12 種情況中，分別一次注入和不注入，剩下的隨機(jī)即可。按照這個(gè)思路優(yōu)化，我們得出了核心鏈路 P0 共 68 個(gè) case。

（二）預(yù)發(fā)環(huán)境混合場景測試

KFX 不是只有一個(gè)服務(wù)而是多個(gè)服務(wù)，每次上線的時(shí)候 會經(jīng)歷 “新 A 舊 B”的過渡狀態(tài)，然后才到“新 A 新 B” 的過程， 其中的過渡態(tài)也是非常重要的，往往可能會暴露出各種兼容性問題，因此我們在 e2e 的鏈路上也考慮了這種場景，來做混合測試。如下圖所示：

（三）復(fù)合鏈路交叉測試

單條鏈路的穩(wěn)定并不能保證整個(gè)系統(tǒng)的鏈路穩(wěn)定，因?yàn)閼?yīng)用是有狀態(tài)的，鏈路之間是存在耦合的，上面說的 H5 容災(zāi)域名未替換故障里，就是因?yàn)?KFC 發(fā)布 + 平臺回滾導(dǎo)致的問題。因此我們做了鏈路間的交叉測試，比如對于 流水線發(fā)布+默認(rèn)策略+版本變更的 case， 跑完后在此基礎(chǔ)上執(zhí)行 平臺發(fā)布+默認(rèn)策略+版本回滾，之后可以再隨機(jī)其他的場景 case，通過這樣的方式來驗(yàn)證鏈路間可能的耦合情況。

實(shí)際情況

2023 年冬，KFX 平臺做了 kfx-api 架構(gòu)精簡化， 建設(shè)了自動化 e2e、全鏈路日志、多集群維度監(jiān)控等核心功能，保障了服務(wù)的穩(wěn)定性。集群數(shù) 6 個(gè)，應(yīng)用數(shù)超過 1400+，主要覆蓋 10 多個(gè)部門。

2.3 高速公路

高速公路比起馬路，跑的車又多又快，但是逃不掉的是維護(hù)成本

面臨的問題

經(jīng)過一年的穩(wěn)定性建設(shè)，到 24 年，KFX 已經(jīng)逐步建設(shè)成為穩(wěn)定的公路了，同時(shí)朝著高速公路的方向努力。高速公路的特質(zhì)是高并發(fā)、穩(wěn)定，同時(shí)并發(fā)量越大，車越多，維護(hù)成本就越高，因此有效的控制和降低維護(hù)成本也是一個(gè)重要的方向。想要建設(shè)成為高速公路，做到像高速公路一樣又多又穩(wěn)的跑車，KFX 還需要從下面幾個(gè)方向做能力擴(kuò)展，總結(jié)來看就是以擴(kuò)為主要方向，以穩(wěn)和控為約束方向：

【擴(kuò)】高吞吐量：支持更多的部署場景，支持更大的并發(fā)能力。

【穩(wěn)】穩(wěn)定性賦能：除了系統(tǒng)本身的穩(wěn)定性，作為部署域的解決方案，有責(zé)任為業(yè)務(wù)提供穩(wěn)定性保障。

【控】運(yùn)維成本降低：在擴(kuò)張的前提下，維護(hù)成本不能線性增加，我們希望整個(gè)系統(tǒng)能夠穩(wěn)定又低成本的運(yùn)行。

解決方案

這一階段我們的核心工作是 “擴(kuò)”：擴(kuò)寬部署域更多的場景，橫向上擴(kuò)寬部署能力，能支持除靜態(tài)部署之外的應(yīng)用，在縱向上，擴(kuò)展支持線下環(huán)境部署，建設(shè)更快更好用的測試環(huán)境部署方案。

多場景建設(shè)（擴(kuò)）

實(shí)施背景：

①測試環(huán)境標(biāo)準(zhǔn)化部署

KFX 的靜態(tài)部署在線上環(huán)境的建設(shè)，到今天為止已經(jīng)相對成熟了。但直接將線上環(huán)境的方案遷移到測試環(huán)境使用，則還是會出現(xiàn)諸多問題，線上環(huán)境第一要素是“穩(wěn)”，測試環(huán)境第一要素是“快”。

• 測試環(huán)境需要支持快速發(fā)布、預(yù)覽、測試， 直接使用線上的流程會讓測試環(huán)境變得效率不那么高。
• 測試環(huán)境有高頻率/高并發(fā)/并行的特征。
• 測試環(huán)境會復(fù)用代理服務(wù)，甚至有直接使用 mock 代理后端服務(wù)的場景，比如白屏檢測、性能檢測。

②SSR 場景、node 場景擴(kuò)展

目前 SSR 在公司還沒有一套完善的配套設(shè)施，來提供整個(gè)從部署、運(yùn)行到維護(hù)鏈路的解決方案。通常的方案是直接使用容器云，當(dāng)作一般的 api 服務(wù)部署，然而 api 容器部署方案并沒有特殊適配 SSR 的場景，會存在以下問題：

• 部署成本高：直接使用容器云， 部署、上線、運(yùn)維成本相對于 CSR 靜態(tài)部署陡然提升，
• 場景功能缺失：灰度，白名單，CDN 降級功能需要單獨(dú)開發(fā)

具體方案：

我們通過 LED 與 KFX 結(jié)合，提供了測試環(huán)境部署域整體的解決方案：即域名 + 代理 + 路由 + 部署 + 運(yùn)行環(huán)境。

核心功能：

• 一鍵部署：結(jié)合 Gundam 工程生態(tài)，觸發(fā)流水線后能自動分配可訪問域名并部署可用環(huán)境， 完成創(chuàng)建工程后即可部署一個(gè)穩(wěn)定的測試環(huán)境。
• 配置化生成代理：由于項(xiàng)目的代理是跨分支復(fù)用的，因此可以在工程中以配置的方式進(jìn)行維護(hù)，在流水線執(zhí)行部署時(shí)會根據(jù)代理配置自動生成相應(yīng)域名下的代理。
• 自動化泳道模式：根據(jù)插件配置可以切換 主干部署和泳道部署能力， 在泳道模式下，會自動根據(jù)分支來設(shè)置泳道，同時(shí)分配泛域名。此時(shí)通過泛域名訪問無需注入泳道，方便快速分享。

業(yè)務(wù)穩(wěn)定賦能（穩(wěn)）

實(shí)施背景：

KFX 最開始以策略模式作為交互方式，策略模式的功能擴(kuò)展性更強(qiáng)，能適配更多的場景，但很多的用戶都不得不去理解“部署一個(gè)默認(rèn)/灰度策略”是什么意思，為什么一次灰度發(fā)布到推全的過程要去上線好幾次（發(fā)布幾個(gè)灰度策略，再刪除灰度策略，再發(fā)布默認(rèn)策略) 。比起常規(guī)的上線單流程，策略模式顯得不那么容易理解。

具體方案：

因此，伴隨著工程標(biāo)準(zhǔn)化的建設(shè)，我們跟商業(yè)化一起共建了分級發(fā)布的上線模式，并作為標(biāo)準(zhǔn)的能力落地到 KFC 的插件中。

運(yùn)維成本降低（控）

智能 oncall 接入：

oncall 問題一直都是基建工具躲不掉的工作，除了一部分是能從反饋中轉(zhuǎn)化需求做改進(jìn)之外，更多咨詢類的問題只是純純的體力工作。

• 緊跟時(shí)代的浪潮，kfx 也擁抱 ai 智能 oncall。在 24 年 Q3，我們接入了 koncall 服務(wù)，上線了 KFX AI 小助手，結(jié)合 kfx 的實(shí)際情況對 AI 的回答質(zhì)量不斷優(yōu)化調(diào)整。 

報(bào)警治理：

除用戶 oncall 之外，另一個(gè)繁重的問題就是報(bào)警 oncall，我們每天面臨著下面諸多的報(bào)警。報(bào)警治理主要從兩個(gè)方向出發(fā)，首先識別是否是有效報(bào)警。

• 對于有效報(bào)警深入分析原因并盡量從根本上解決：
• mysql 連接偶發(fā)超時(shí)異常，通過數(shù)據(jù)庫從代理改為數(shù)據(jù)源發(fā)現(xiàn)+直連的模式
• 優(yōu)化實(shí)例退出流程，減少服務(wù)請求失敗的概率
• 優(yōu)化 dns 邏輯，防止 dns 丟包阻塞進(jìn)程，導(dǎo)致進(jìn)程 oom
• 對于無效報(bào)警，通過動態(tài)調(diào)整閾值、調(diào)整等級、報(bào)警去重等方案轉(zhuǎn)化為有效報(bào)警。

從之前周峰值 1000+報(bào)警，降低到周均 50 以內(nèi)。

非活躍服務(wù)治理：

kfx 服務(wù)上托管的應(yīng)用隨著時(shí)間在不斷增長，過多的應(yīng)用會拖慢服務(wù)的啟動速度，因此需要對長期無流量的應(yīng)用進(jìn)行識別并下線。

• 建立 KFX 項(xiàng)目數(shù)量管控，常態(tài)化項(xiàng)目退出機(jī)制
• 處理下線項(xiàng)目數(shù)量 469 個(gè)，占直接托管項(xiàng)目數(shù)量 51%

實(shí)際情況

2024 年冬，KFX 平臺支持分級部署，支持 api 代理優(yōu)先模式。集群數(shù) 7 個(gè)，應(yīng)用數(shù)超過 6000+，主要覆蓋 30+個(gè)部門。

三、總結(jié)與反思

從 22 年開始，KFX 從崎嶇土路 一步步走到平坦高速，下面列出了三個(gè)階段的演化。

KFX 的發(fā)展歷程總體來看是按照漸進(jìn)式演進(jìn)的方式發(fā)展，在規(guī)?；默F(xiàn)狀下秉承著穩(wěn)定性優(yōu)先的策略，并結(jié)合標(biāo)準(zhǔn)化和自動化，朝著降低運(yùn)維成本和提高系統(tǒng)維護(hù)性和觀測性的方向做功。

展望未來，KFX 將繼續(xù)持續(xù)演進(jìn)，以“擴(kuò)、穩(wěn)、控”為核心方向，不斷優(yōu)化架構(gòu)，提升系統(tǒng)穩(wěn)定性和運(yùn)維效率，致力于建設(shè)更加智能、高效、穩(wěn)定的服務(wù)平臺，打造一條真正的“高速公路”，讓業(yè)務(wù)在更快、更穩(wěn)、更智能的道路上前行。