作者 | 陳仲寅
去年開始，阿裡前端及阿裡的多個團隊聯合開始了一項“秘密”任務，使用 Serverless 這一新一代研發架構，希望能大量減少研發人員使用基礎設施和運維的成本。目前這一架構已經實作前端提效 50%，且已在 Github 開源，開源位址見文末。
Midway Serverless
Midway 之前是傳統的 Web 棧架構，和業界現有的 EggJS，NestJS 等解決的是類似的問題，從中背景到移動端應用，前端都廣泛采用了這些架構來建構自己的業務系統。阿裡也不例外，Node.js 應用非常多，但是這些系統有一個共性，大多數伺服器的 CPU 使用率非常低，這無疑是一種資源的巨大浪費。
這種資源浪費的常态以及應用的規模化幾何倍數的增産，讓應用治理的人員頭疼不已。于是，阿裡把目光轉向 Serverless 架構，他們開始去思考，如何有效去減少研發人員使用基礎設施的效率和運維的成本。
Serverless 和 FaaS
FaaS 是 Serverless 架構的其中一種形态，也是這次 Midway 希望解決的場景。在 Midway Serverless 1.0 之前，我們在 FaaS 上投入了許多，但是事實上，Serverless 架構非常龐大，FaaS 隻是其中的一小部分，基于事件驅動的模型，從微服務（MicroService）這種專注于單一職責與功能的小型功能塊演進而來。如今這種更加“代碼碎片化”的軟體架構範式，相比微服務更加細小的程式單元，給業務代碼提供了無與倫比的靈活性。
按照《福布斯》雜志的統計，在商業和企業資料中心的典型伺服器僅提供 5%～15% 的平均最大處理能力的輸出，這無疑是一種資源的巨大浪費。而随着 Serverless 架構的出現，讓服務提供商提供我們的計算能力最大限度滿足實時需求，這将使我們能更有效地利用計算資源。
阿裡目前使用了 FaaS 來作為業務的落地容器，希望能進一步減少容器的規格，降低成本。集團機器的成本目前是按 CPU Core 算的，以 4C8G（4 核 8G）的機器為例，一個中背景應用最少需要 2 台機器，而上了 FaaS，能減少到 1C，乃至 0.5C，這個成本下降的非常可觀。
落地前端
在阿裡“大中台小前台”的趨勢下，前端是最接近使用者且活力迸發的團隊。前端一直希望能夠有機會擺脫“資源”的困境，對整體工種的職能、邊界有更廣泛而清晰的拓展需求，造就了如今前端的範圍不斷衍生，從端側到智能化，無一不是職能擴大的展現。
對前端開發者而言，Node.js 賦予了開疆拓土的能力，自前後端分離開始，從端到全棧，Node.js 已經成為前端學習的标配，而 DevOPS 的提出，也讓前端逐漸走向開發自治，運維自驅的路子。而阿裡在實際實踐中發現，大部分前端的确在朝着那個方向走，但是更多的是在業務和自治之間産生了一些迷惘，這兩者的關系其實很不容易平衡，時間一久也會對業務的規模化産生一些影響。
而 Serverless 的出現，正好讓前端有機會減少整個 OPS 環節，更加聚焦于業務本身；同時，由于整體的代碼量減少以及輕量化開發理念、部署平台能力的增強，讓整個業務的規模化成本越來越低。
之前，有人把 Serverless 比作前端的 3.0，這不無道理。Node.js 的輕量、快速已經得到了業界技術人員的廣泛認可，在 Serverless 時代，容器的快速排程、代碼的快速啟動，都是非常重要的名額，而 Node.js 在這方面的優勢非常明顯。
前端提效 50%
這個數值在我們看來，Serverless 帶來的效能變化的數值可能更大。其中分為 規模化成本 和 傳遞速度 兩個方面。
降低規模化成本
首先是伺服器成本。
從容器本身的角度來看，上文已經簡單演算過，從傳統容器到函數，整個容器資源從固定規格到更加細粒度的規格去逐漸演進，這将更加符合場景的訴求。經過我們一年的跟蹤，中背景應用的機器成本能降低 70% 以上，而實際移動端業務，也達到了 30% 左右。
其次是治理成本。
越是大的公司，曆史包袱越是嚴重，今年的阿裡集團内部，還存留着 Node.js V6 乃至 V4 的代碼。每年的 Node.js 版本更新、架構更新、庫更新都要至少長達幾個月，甚至幾年。
而如今，函數運作時（Runtime）是前端自己編寫的，我們可以将需要治理的 Node.js 版本、架構，乃至中間件都埋入其中，這就需要定制整個運作時及其通用化的能力。
阿裡的内的函數服務有多種，提供了不一樣的基建和網關服務。今天淘系前端能夠使用一套代碼部署在不同的平台之上，就得益于 Midway Sererless 底層的多平台适配能力。同時，這套代碼的防腐層能力也正好能抹平社群的平台差異性。
針對每個平台，Midway Serverless 提供了不同的運作時啟動器，用于抹平各個平台的差異，并且通過這些啟動器，将各個平台的出入參，以及各個 event 結構，網關的傳回格式進行規則化，讓使用者盡可能不感覺底層容器以及協定的差異。
阿裡通過這套方案，将一套代碼部署在不同的函數服務之上，提供出不同協定的服務。是以到社群，阿裡開源的方案也同樣适用于多個平台，比如阿裡雲、騰訊雲或者是未來的 AWS Lambda、Azure 等。
經過這層防腐和定制，整個運作時的更新變的簡單，将傳統應用需要半年起的版本推平工作，在短短一周内就完成了。舉個例子，底層有個和平台的連接配接協定庫有安全性漏洞，從接到安全報告開始，我們就需要做以下兩件事，一是從平台資料拉取受影響的函數範圍，給所有業務方進行了安全性郵件推送，并告知在一定時間之内不做主動申報的，将預設統一自動更新。二是在流量低谷期進行滾動更新，并以告知業務及時關注和測試。經過這樣的流程，整個安全性更新在極短的時間内就統一處理完畢，這在以往的應用場景下，幾乎是不可能的。
最後是安全生産成本，這塊在阿裡内部的訴求較大，但是中小型公司應該不多，這裡就不再詳述了。
通過這三塊的管控和治理，使得在 Serverless 架構下，集團業務規模化成本極速降低。
傳遞速度
除了規模化成本外，另外一塊就是業務傳遞的情況。前端面向的移動端和中背景兩大場景都需要快速的傳遞，以現在的情況來看，前端依舊是研發的瓶頸，在使用了 Serverless 之後，原有的複雜流程已經無法滿足現有的訴求。
去年我們團隊在 GMTC 及 D2 分享中說過，前端自建了一套研發流程和平台，用于滿足在新的場景的測試、灰階和復原。整個研發流程，節點比以往更少，更容易聚焦。
而另一邊，整個研發的效率，也有了不小的提升。
前端開發的效率，得益于前後端的融合，一體化開發和傳遞的速度。傳統的前端研發，需要在前端倉庫和 Node.js 端倉庫多處進行開發，釋出流程也是分離的。而在 Serverless 場景下，Midway Serverless 設計了一體化開發和釋出的方案，這讓前端能将業務在同一個倉庫開發，同一個流程釋出。特别是那些維護多業務的同學，感觸會更深。
除了一體化的開發、調試，部署之外，從代碼角度看，原有的編碼習慣被保留，無需再度學習新的程式設計 API 也是一個方面。Midway Serverless 除了提供基于 TypeScript 和裝飾器的編碼風格之外，也提供了一些傳統應用 Egg 應用遷移的方案，在不同的 BU 中也進行了落地嘗試，效果非常不錯。
經過一年我們在平台測的統計和業務開發方的走訪，新的研發模式對業務整體的傳遞效率有一定的提升，這個提升是普适性的。
以前端完成需求為例，傳統完成業務需求需要後端的介入以及聯調，而新的研發模式在代碼層面會開發更快，雖然單人來看工作量增加了，但是整體的傳遞時間，投入人員以及聯調成本都有明顯的降低。
除了業務感性的傳遞資料外，我們還統計了整體的研發代碼量，送出的代碼頻次以及需求的疊代周期和釋出。經過一年業務跟蹤和資料的測算，我們得出整體前端人效的提升約為 48%，整個核心的算法牽扯到很對内部的資料，抱歉無法提供，歡迎大家入職觀摩。
Serverless 的弊端
任何事物都有兩面性。Serverless 優勢固然的大，但是畢竟是新東西，特别是在企業中落地的時候，難免會遇到一些問題。
一是基建的缺失，傳統的各種用戶端、日志投遞、鍊路追蹤等能力都非常的完善，而函數這些新的事物還需要時間逐漸沉澱，加上彈性容器的影響，整個鍊路都還是新生事物，需要時間去驗證穩定性和可靠性。
二是業務同學的整體理念還是停留在傳統應用的層面，對函數的運作機制，事件觸發的行為了解不深，加上架構做了很多屏蔽的工作，很容易出現某些代碼編寫錯誤或者前期需求評估不到位，能力無法實作的情況。這些都需要慢慢的打磨，相信在不斷的實踐下，整體都會越變越好。
最後
我們可以看到，50% 的計算方式是一個相對感性的數字，但是 Serverless 在其中實實在在的展現出了它的魅力和價值。最後慶祝一下 Midway Serverless v1.0 釋出。通過整個 Midway Serverless 新體系，我們将阿裡的 Serverless 能力逐漸開放，希望整個前端能有不同的思路去承擔更大的業務職能，進入一個嶄新的時代。
開源位址
https://github.com/midwayjs/midway你可能還喜歡
阿裡 Midway 正式釋出 Serverless v1.0，研發提效 50% 關注「Alibaba F2E」
把握阿裡巴巴前端新動向