Categories
程式開發

快手前端發展:前端中台化、前端智能化,我們一直在追趕什麼?


從2016年開始招募第一名前端、從0開始搭建快手前端整體技術服務和腳手架,到前端團隊貢獻一份力量、支撐快手完成春晚任務:春晚紅包互動總量達639億次;紅包站外分享次數達5.9億次。快手春晚直播間累計觀看人次7.8億,最高同時在線人數2524萬。在短短的4年時間裡,快手前端團隊經歷了什麼?快手App訪問量的快速增長對前端團隊帶來哪些挑戰? InfoQ記者在 GMTC 全球大前端技術大會(深圳站)2019 期間採訪了快手前端技術專家宋雲路,一探究竟。

InfoQ:能否先請介紹一下快手 App 前端業務的發展歷程、期間一些重要的節點?

宋雲路:快手是2016年前後才開始招募專職的前端工程師的,之前前端工作都是由全棧工程師來完成。我也是2016年年中入職到快手的,2016年起我們用小而精的團隊從0開始搭建快手前端的整體技術服務和腳手架。

在2017年到2018年的時候,快手的業務量和DAU迅速增長,公司也逐漸孵化出一些產品矩陣,就像孵化器一樣,“我們先孵化一個孩子,養大點就送出去獨立闖蕩了”。快手前端也從最開始的僅一個團隊逐漸分化為近十個團​​隊,從最初的幾人,發展到目前近200人。

如果說其間的一些重要發展節點,2018年起,我們逐漸開始做一些運營類的業務,然後前端訪問量就逐漸開始變大。 2018年春節之前,快手App H5業務突破了億級日訪問量;到了2019年春節的時候,已經達到十億級別的訪問量;今年2020年春晚快手成為春晚紅包獨家合作夥伴,春晚紅包活動中有一部分功能就是由前端負責實現的,我們也在用盡全力去保障前端業務的高可用性。

InfoQ:快手App訪問量的快速增長,對您的團隊會有哪些挑戰?

宋雲路:我們團隊建立的時候沒有什麼歷史包袱,最開始就是基於Node.js 中間層做前後端分離的,後端只提供類Restful API接口,其他都由前端負責。從這個角度來講,前端承擔的職責是比較廣的,包括Node.js開發、DevOps等一些常規的頁面端和服務端的事情都需要去處理。

一方面我們會去借鑒業界的一些優秀實踐經驗,另外會劃分出一部分精力來做常規前端不太擅長的知識的沉澱和提升。比如高訪問量Node.js服務和純前端服務的穩定性保障等方面,我們通過每年春節活動等重大活動的驗證,最高支持了十萬級QPS前端項目的穩定運行,已經積累了一些非常成熟的經驗。

InfoQ:回到前端中台化,當時為什麼會決定要做這個事情?背景是什麼樣的?

宋雲路:前端中台化的前提首先是快手從公司層面有一個整體的中台戰略,它會從公司層面提供一套整體的中台通用技術服務,比如賬號類、日誌類、通用工具類的技術服務等。有了中台通用技術服務的支撐,我們就可以在上層去做具體業務中台化的嘗試。

我們啟動前端中台化的起因就是,伴隨我們孵化的新業務越來越多,發現新業務中很多業務流程以及運營活動和主App的功能基本上99%都是相同的,然後不同點可能是樣式方面會有些不同。另外因為涉及端能力的調用,在不同客戶端調度能力有差異。所以我們遇到的主要問題就是,對於有端能力需求的H5業務,如何讓它無縫地運行在不同客戶端裡面,這就是最開始的背景。

起初我們的處理方式是抽像一些適配器模塊去做邏輯分支的判斷,但是執行了一段時間發現當邏輯比較多的時候,到後面再改東西會比較難改、或者不敢改,因為我不確定它的影響範圍會是多大。不可能為了改一個小功能,把所有已上線的App全部拿出來重新再回測一遍。

那個時候我們就在想,如何基於公司的中台化戰略,去設計一個更好的通用服務來提高迭代效率?解決方案就是抽像一些H5的業務中台,每個業務中台都有一個C端頁面和對應的後台管理功能。這樣就可以動態的去控制該服務在某個客戶端中的自定義行為表現。對於有客戶端橋依賴的中台,我們會給每個業務中台定義一套JS橋API約定,如果某個業務或者說某個客戶端想接入,它就按照我們這個API約定去開發相應接口來接入就好了。比如運行這個中台需要三個JS橋能力,我們提前把這三個JS橋的名字和調用方式約定好,就是說你要想接入進來,你需要在你的客戶端裡面去支持這三個API才能使用這些功能。

在此基礎之上,我們會發現我們H5業務中台在實際接入的過程中,還是會需要每個業務做一些適配聯調工作,或者說需要做一些接入層面的開發工作。基於一些開發和迭代成本的考慮,又設計了一個H5容器的技術中台,我們期望這些業務中台全都運行在這個H5容器中台裡面。這樣的話,只要在H5容器中台裡面支持了這些通用中台橋依賴,剛才我說的每個業務自己去實現API就不用再做了。還有一個好處是,通過H5容器中台,我們可以很容易讓新業務集成H5開發常用的端能力集合,比如離線包能力,動態鑑權能力,數據統計能力等。最終就實現了通過業務中台+技術中台組合的方式讓前台業務以最快速度去接入相關的通用服務,最大化提高我們開發和迭代的效率,為業務賦能。

InfoQ:您認為前台中台化最大的挑戰是什麼?

宋雲路:首先就是要明確中台化的邊界:哪類業務要做中台化?哪些不需要中台化?其次,就是業務中台、技術中台的職責如何劃分,最常見的就是端能力的依賴問題。比如一個JS的API,我是在中台裡面去實現,還是在業務中自己去實現,這個邊界需要考慮;另外,前端中台化可參考的經驗並不是特別多,我們相當於也在摸索中前進。

InfoQ:現在快手前端中台化做的怎麼樣?

宋雲路:從業務中台方面,目前已經有接近十個業務中台的抽象,有的業務中台已經運行在大約20多個客戶端裡面了。技術中台是我們2019年的目標,比如H5容器中台我們從2019年年初開始開發,下半年開始上線,目前已經上線了包括快手在內的約10個客戶端業務。

不過倒過來往回看,這裡邊還是有很多可以優化的空間的,主要是在協作分工上。因為前端主要承擔的是表現層的邏輯,做中台的話要涉及到一些與客戶端、後端的職責劃分和解藕,所以其實有的中台功能是前端主導,有的是客戶端主導,也有的是後端主導。

在我看來,理想的前端中台化,每個客戶端只是一個載體,沒有能力上的差異,各個業務功能都可以通過中台化的方式去獨立運行,它們之間也可以非常靈活的組合,實現最大化的能力上的複用。

InfoQ:您認為中台這件事兒人的問題是否會成為瓶頸?

宋雲路:其實是有可能的,因為中台不是開發完成就完事了,往往是一個需要長期支持的項目,所以其實這個里邊就涉及到中台到底應該由誰來做的問題。可能有的公司會有一個中台的團隊去負責所有中台的產出,有的公司會從組織架構上有劃分。如果是從組織架構上沒有劃分清楚,一般我們建議就由最大的業務方去負責中台的孵化。這樣的話就能保證中台的設計能夠滿足最複雜應用場景。因為如果是讓一個比較小的業務方負責中台,很有可能他考慮的場景不夠全面。所以在快手,主App相關團隊承擔的中台孵化和抽象相對多些。

InfoQ:您覺得前端中台化接下來會是大勢所趨嗎?
宋雲路:前端中台化只是中台化里面的一個分支,還是要看業務體量,所以不一定適用於所有公司。如果說業務還沒有成型,復用場景還沒有那麼多,說​​明不確定性還比較多,可能就不適合做前端中台化。

InfoQ:快手的前端中台化,接下來的最大挑戰是什麼?
宋雲路:我認為挑戰還是在與端結合的一些能力的抽象、復用和體驗優化上,比如說如何處理端內H5功能與客戶端能力的耦合關係等。對於我們C端業務,端內的H5頁面總是免不了和客戶端去打交道,那如何把H5和客戶端結合起來去提供統一的、一致的,可擴展的能力,並且能夠讓業務使用得比較舒服,讓我們升級迭代順暢,這個是我們後面要去優化的。

InfoQ:除了中台,您的團隊近期還有哪些正在探索中的工作?
宋雲路:我們在2019年進行過Flutter方面的探索,Flutter現在在快手的幾個業務線上都得到了落地。

從業務層面,因為我們已經實現了H5容器的端能力的統一,於是我們目前就在基於這個H5容器,探索中台之間服務打通的解決方案,讓我們的業務方能夠比較容易的去集成公司層面的整體服務。目前第一個落地的就是我們的H5+客戶端全鏈路性能監控,從客戶端的行為,到H5的行為,再回到客戶端的行為,我們會把性能的一些指標做統一封裝,做一個更完整的監控解決方案。同時會通過數據分析,實現自動報警、自動預警。

InfoQ:2020年的大前端領域,您最看好哪些技術趨勢?
宋雲路:除了Serverless和Flutter等已經非常火熱的概念以外,我個人會傾向於通過前端智能化減少重複勞動的相關解決方案。像服務的監控報警,如何讓我們基於數據分析更智能的去做這個事情,而不是每次上線新業務都要寫一堆報警條件、去人工檢查等;另外比如如何通過Low Code / No Code的解決方案,幫助前端工程師節省簡單頁面的開發時間等也是我所關注的。

嘉賓介紹:

宋雲路,快手前端技術專家,2016 年加入快手,親身經歷了快手從千萬級 DAU 到億級 DAU 的前端架構演進全過程,目前主要負責快手主 App 相關的前端業務開發和架構優化。對前端中台、前端高可用性,前端性能監控、 Node.js 開發運維等方面有比較豐富的實踐經驗。