螞蟻金服 Node.js 落地實踐,從零搭建 Node 基礎設施征途

@貫高,目前負責螞蟻體驗技術部的基礎服務團隊

作爲『那些年的體驗技術部』一文的親歷者,螞蟻體驗技術承載了我們的夢想,走過了十年,經歷了風雨,也收穫了掌聲,但這都只是波瀾壯闊的互聯網發展史中的小小縮影。

下一個十年會發生什麼?我們無法預測,但我們正在嘗試給出答案。在本文中,我將展開闡述下體驗技術部中的基礎服務組的過去、現在和未來。

初創時期

螞蟻體驗技術部起源於基礎技術,當年玉伯從淘寶轉崗到支付寶,開啓了基礎技術的新徵程,那時的團隊更像一個創業公司,開源的工作方式、異步溝通協作、做基礎技術的同時懷揣着產品夢。

早期的基礎技術和大部分前端團隊一樣,主要 focus 在前端組件庫和工具領域。

在那個時候,前端不被視爲

螞蟻組件庫經歷了從 YUI 到反覆推翻自己的 Arale,工具也從 antx、maven 到反覆推翻自己的 spm。

這一時期主要還是解決溫飽問題,還談不上工程化,僅僅是通過一些自動化的手段來加速前端的開發。

隨着前端的飛速發展,npm 包極速增長,webpack 生態越做越大,前端框架也成三足鼎立的之勢,玉伯決定基於 React 重新打造一套組件庫,不過那就是另外一個故事了。

在這過程中我們積累了不少 Node.js 工程實戰經驗,基礎技術逐漸下沉爲體驗技術的底盤,關注如何把各種新興技術進行民用化、工程化,爲上層的創新業務提供炮彈支援,擴大前端能力、提升前端效能,成爲我們的初心和責任。

破土而出

隨着前後端的演進,前端爲了更好的提效,需要把 API 聚合層掌控在自己的手裏,越來越重視 Node.js 這利器。

然而,在那個年代的阿里技術架構中,Java 一家獨大。新生的語言,要想立足,難度非常巨大。

那時 Java 提供的中間件服務、通訊協議、SDK 完全不考慮跨語言,我們需要自行實現大量的中間件 Node SDK。

螞蟻的 LDC 架構也導致我們需要自行實現很複雜的路由規則等。

同時在運維上的挑戰也不小,研發平臺只支持 Java,我們只能作爲非標應用接入,需要自行實現很多腳本來僞裝爲 Java 應用,方能適配日誌採集等運維能力。相比阿里集團的同機部署方案,我們採用的 Node 獨立部署方案受到了非常大的挑戰,在沒有說清楚 Node 這層能做什麼的時候還在鏈路上新增了一層調用,"耗費性能又無法提升

然而站在前端的視角,我們堅信,這是最佳的前後端分層方案:由前端來提供頁面所需的 UI Model,Java 提供領域模型。

640?wx_fmt=png

這一年前後,蘇千、不四等 Node 社區的活躍成員先後轉崗螞蟻,蘇千在原來的業務線已經使用 Node 做生產服務了,他也是

第一個使用 Chair 的應用是『我的支付寶』,當時算是流量比較大的前臺應用了。正如上面所說,當時 Node 中間件體系並不完善,百廢待興,Node 還無法支持一個複雜業務的所有能力,所以當時 Node.js 側重點在和前端側的研發模式結合上,對後端的結合則使用一個 Java 應用作爲透明代理,通過直連的方式調用下游的服務。支付寶第一個 Node 應用平穩經歷了當年的雙十一,驗證了這種模式的可行性。

嶄露頭角

隨着 Chair 框架的完善和前後端分層理念在整個集團乃至社區的傳播,這種模式也迎來了一個新名詞

這期間餘化、湯堯、不四、宗羽、自成、孝達紛紛加入了基礎技術,在這羣人的碰撞下,Chair 飛速發展。

  • 湯堯的 jar2proxy 創新性的把 Jar 解析爲對應的 Node RPC 類,解決了 API 定義和協作問題。

  • 宗羽支持了絕大部分的中間件 SDK 研發,掃清了 Node 走向更強大的全棧應用的障礙。

  • 樸靈的 Alinode 使得我們再也不用擔心內存泄露和 CPU 問題,放心的上線。

  • 蘇千不四的 tnpm 解決了 npm 龜速問題,以及私有庫的管理。

等等等。。。

2015 年 9 月,Chair 1.0 正式發佈,這是非常重要的歷史節點。1.0 發佈了插件機制,從一個單體框架抽出了 37 個插件(現在的 Chair 擁有將近 100 個插件),成爲了後續開源 Egg 的基礎。

同年 10 月,蘇千組建了阿里 Node 虛擬工作組,以這套插件機制爲模板發起全集團共建,並將其取名爲 Egg,有孕育孵化之意,希望各個 BU 可以在共建的基礎上孵化適合各自業務場景的上層業務框架。天豬也是此時作爲 UC 的代表參與到共建,隻身揹着一臺 Mac mini 跑到杭州借個顯示器一起閉關。

短短半年間,各 BU 通力合作,陸續發佈了基於 Egg 的上層業務框架(Nut、Begg、Columbus 等)。Egg 就這樣沒有一點波折的快速成爲了阿里 Node.js 的核心基礎框架。

640?wx_fmt=png

回頭看這段歷史,只能感慨天時地利人和:

  • 各 BU 的 BFF 建設剛起步,沒有太多歷史包袱。

  • 來着五湖四海十幾個 BU 的前端骨幹自下而上的 Open 的心態。

  • 蘇千等人多年在 Node.js 耕耘積累下的幾百個模塊,以及由此帶來的強大的號召力。

  • 莊少、不四等也通過天貓雙十一等場合的業務實踐,用出色的業務實踐,給出了有力的迴應。

次年 9 月,天豬在 JSConf 2016 上正式對外開源 Egg,它對 Node.js Web 應用規範的提煉,完善的插件生態,深入淺出的文檔,在國內的口碑與日俱增,目前已經破萬 Star,各大公司包括騰訊、百度、美團、網易、頭條、小米都有不少團隊使用。

這一階段,我們證明了 Node.js 的能力和價值,並不是 Node 不適合做大項目,而在於基礎設施和實踐的沉澱,需要有團隊踏實的深入進去踩坑,爲後人鋪路,Node 自此在阿里全面開花。

與此同時,我們積極地參與開源,回饋社區,除了 Egg、cnpm 外,我們在 Node 社區發佈了大大小小几百個模塊。希望能一起盤活前端的盤子,促進業界發展。

黃金時代

Chair 在 0.10 時就已經實現了無線網關的功能,無線時代是 BFF 非常好的機會,這也是螞蟻當下最常用的場景。

這一時期前後端分層已經成爲共識,在各個 BU 出現了大量的 BFF 應用,H5 + BFF 已經成了前端團隊的標配,前端這個崗位的職能在不斷的擴大,已經能處理較爲複雜的業務問題,也跳出了一直被詬病的不懂業務的怪圈。Node.js 成爲了阿里技術棧的另一重量級玩家。

然而隨之帶來的研發效率問題,需要我們去直面和解決。

上面提到,阿里的研發平臺等當時都是專爲 Java 服務的,也沒有計劃支撐跨語言,我們依舊需要自力更生。而隨着 Chair 框架的不斷完善,使用 Chair 開發一個全棧應用成爲了可能,我們的武器已經強大起來了。

640?wx_fmt=png

這一時期,前端研發平臺 Basement 出現了。早期的 Chair 應用都是以非標應用的身份來使用 Java 的研發平臺,前端組件發佈也是自己的流程。因此我們需要自己定義前端研發平臺,根據前端的特點定義我們的研發模式,通過技術手段針對性的解決前端研發痛點。如今它服務於螞蟻幾千位 Web 開發者(甚至包括幾百個 Java 中臺開發者)。

這一時期,Dockerlab 出現了。Dockerlab 是基於 Docker 做的一個內部 PaaS 平臺,可以讓開發者非常簡單的在測試環境部署起應用,進一步降低了前端的研發成本。這爲前端創新創造了土壤,離從想法到產品又更近了一步,很多不錯的內部創新中臺都孵化於此。

這一時期,Basement BaaS 出現了。提供了一套快速使用的 API,包括文件上傳、NOSQL 數據存儲、異步任務等服務,結合 Dockerlab 可以快速開發一個應用,極大的降低了前端的研發成本,這也是 小程序 Serverless 雛形。

  • Render:高性能高可用的頁面渲染和託管方案,支持億級 PV,能滿足絕大部分業務場景的動態渲染能力。

  • File:基於 OSS 高度定製化的文件上傳服務,屏蔽底層 OSS 細節,實現文件上傳的開箱即用。

  • DB:NoSQL 數據存儲服務,用於中臺快速迭代期的數據存儲。

  • Task:異步任務,覆蓋高 CPU/MEM、執行週期較長的操作,支撐了螞蟻前端的絕大部分構建任務。

  • Message:消息推送的服務,涵蓋郵件、短信、釘釘、機器人等渠道。

  • 還有 FileSync 文件同步、Redirect 短鏈服務、區塊可視化配置服務等等。

這些爲前端量身打造的平臺陸續出現,極大的提升了前端的研發效能。

在這個時期,以框架能力爲中心,開始向研發平臺、BaaS 等方向發展,一方面解決 BFF 研發效率的問題,另一方面繼續擴大前端的能力,先通過自建平臺來滿足自己的需求,再對外開源輸出能力。

潮起潮落

如上面所述,我們通過框架來提升工程師的開發效率,通過平臺來把一部分場景的複雜度消化掉。

理想是美好的,但現實是殘酷的,當我們站在一個山峯的時候,卻發現:

BFF 的增多給前端不可避免帶來額外的治理成本,知識面的拓寬對人的要求變高了,前端不僅僅要了解前端知識還要了解服務端知識,招人和培養的成本也因此變高了。

基礎技術團隊維護的 Node 中間件也逐步增加,而且需要跟着 Java 的變化持續維護,變成了代碼翻譯機器。

技術商業化也成爲了新的課題,開源影響力並無法直接帶來商業的成功,但基礎技術還是繼續探尋框架和 BaaS服務商業化的可能,中間也走了不少彎路。

這一時期,對未來方向的迷茫以及當前現狀的壓力,整個團隊都陷入了低谷。有些同學換了賽道去 Cloud IDE、小程序等去繼續自己的探索,也有新的同學加入到基礎技術來驗證自己的想法。

這一切迫使我們開始不停思考:

中間件的維護,真的需要每個語言獨立維護 SDK,重複實現一套邏輯麼?有什麼新技術可以爲我所用麼?

交付給開發者的,除了框架還能再進一步麼?能否既不增加額外負擔,又能擴大前端的能力呢?

揚帆起航

這是最好的時代,也是最壞的時代。

上一個階段的痛苦和思考,隨着雲原生和 Serverless 領域的興起以及阿里經濟體整體雲化的快速推進,我們找到了新的發力點,繼續爲擴大前端能力和爲前端提效兩個目標而努力。

640?wx_fmt=png

如上圖是螞蟻體驗技術部的矩陣大圖,我們基礎技術負責其中非常重要的兩項:

  • Serverless For Frontend - 螞蟻前端雲化的基礎底盤設施,爲雲鳳蝶,Cloud IDE,語雀等產品保駕護航。

  • 小程序雲 Serverless - 阿里經濟體一朵雲戰略,基於 SFF 對外開放我們的能力來服務外部開發者。

我們重新定義了 BFF,稱爲 SFF (Serverless For Frontend),爲高效的開發人機交互界面提供無感的服務能力。

未來不管怎麼演變,與人機交互界面都需要這層 SFF。大致可以分爲三類,可互相調用:

  • Function (80%):函數,快速開發 Core model 到 UI model 的轉換。

  • Application (20%):全棧應用,主要使用 Node 開發中臺應用。

  • Task (<10%):異步任務,覆蓋高 CPU/MEM、執行週期較長的操作。

SFF 研發模式的核心點在於:不增加額外成本的同時,擴大前端能力。

輕研發、弱流程:讓開發者關注於業務代碼本身,簡化第三方接入流程。

一站式、免運維:貫穿整個研發流程的一站式研發體驗,無需關注運維,系統自動根據流量擴縮容和故障自愈。

雲端一體化:前後端研發模式融合,降低理解成本,自動生成前端 RPC 代碼,Code Once Run Everywhere。

此時此刻,非我莫屬

基礎技術從玉伯到蘇千、再到我們這代,工作職責也從前端框架到 Node,從工程化到 Serverless PaaS,雖然工作範圍更偏服務端,但 爲前端提效 和 擴大前端能力 的初心一直沒有變,這兩個目標總是交替螺旋上升的。

也許外面很多人都在唱衰 Node.js,但我們一直堅信未來十年內,Node 是整個前端的護航者,必不可缺。

我們做了很多事,但有更多的事需要我們去做。活多人少有挑戰,擼起袖子拼命幹。

此時此刻,非我莫屬。你是否希望擼起袖子,一起描繪前端基礎技術的未來。

關於本文作者:@貫高原文:https://www.yuque.com/afx/about/nodejs

❤️ 看完三件事

如果你覺得這篇內容對你挺有啓發,我想邀請你幫我三個小忙:

  1. 點個「在看」,讓更多的人也能看到這篇內容(喜歡不點在看,都是耍流氓 -_-)

  2. 關注我的博客 https://github.com/SHERlocked93/blog,讓我們成爲長期關係

  3. 關注公衆號「前端下午茶」,持續爲你推送精選好文,也可以加我爲好友,隨時聊騷。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章