你們都關注的Serverless，阿里怎麼作的？

本文是阿里巴巴前端技術專家-張挺，在 JSConf China 「中國開發者大會」上分享的《面向傳統，Serverless 進化之路》，主要講述阿里集團內部逐步遷移到 Serverless 體系的過程以及思考。

背景

自 GMTC 以來，國內各個公司在 Serverless 投入都有所變化，騰訊和阿里雲都鉚足了勁在上面發力，提出了各自的解決方案，騰訊推出了 Serverless 2.0，以及幾天前阿里雲推出的預留模式，都是對 Serverless 愈來愈重視的表現。

本文主要介紹兩部分，第一是阿里在近期作的前端研發升級，爲拓展前端的邊界和職能，嘗試作了一次和 Serverless 結合，第二是在這其中，咱們嘗試對現有的體系作了思考，但願能將傳統應用快速遷移到 Serverless 體系，享受到 Serverless 紅利。

現狀

阿里的 Node.js 應用很是多，1600+ 的數量讓維護和治理都變的很麻煩，每一次升級都要推行好久，這無論對框架開發仍是平臺治理都是不利的。

不少 Node.js 應用都是 BFF 應用，內部平臺等，這些應用常年大多都處在負載低（10%如下），沒有流量的狀態，並且維護者大多處在離職或者不積極的狀態，一方面形成了資源浪費，另外一方面也給治理形成了困難。

其次，在集團開發傳統應用，須要申請，整個研發流程比較長，須要業務瞭解預算和資源，牽扯到不少細節。

爲此，咱們開始了 前端研發升級 這個大項目。

整個前端研發模式升級的目的有兩個，一是爲了「前端賦能」，二是爲了「前端提效」。

所謂的「前端賦能」，是由於咱們但願前端可以打破現有的技術壁壘，朝着更底層，面向數據的地方去深刻探索，在這之中能夠從面向 UI，視圖自己變的更加了解業務，從更面全面的視角來理解現有的體系。

而「前端提效」，則是但願讓 Serverless，用更輕量化的方式進行業務研發，下降整個前端參與業務交付的門檻，同時，在開發期間，也能減小人力總成本，讓前端減負，業務小步快跑成爲可能。

可是阿里的 Serverless 之路很是困難，不像外界已經有成熟的體系，目前一些緣由沒法使用公有云上開放的產品，阿里雲也沒法直接對內部提供服務，同時，內部的中間件在外部都沒有，都須要跨團隊來從新建設。

Node.js 基礎團隊的使命，就是爲集團 Node.js 生態提供各類基礎能力，包括但不限於框架，中間件包等，而在 Serverless 體系中，咱們要負責框架、工具鏈、運行時、發佈系統，同時也須要和周邊的網關，監控系統等對接。

收益

去年 10 月開始，咱們開始進行調研 Serverless 以及瞭解相關知識，到如今爲止，也已經取得了必定的階段性成果，將淘寶和飛豬兩道 BU 的導購鏈路整個遷移到了 Serverless 體系，而且承載了導購鏈路的千萬級流量。

同時，內部系統也進行了必定程度的 Serverless 升級嘗試，無論是重寫仍是傳統應用遷移，咱們都有了必定的沉澱。

咱們最初的目的是但願能下降成本，按照網上 Serverless 的下降成本率能達到 90% 以上，不過導購業務比較特殊，流量比較大，不像那些須要彈性的應用，根據咱們的測算，單進程下函數的性能很是不錯，可是因爲大促要提早預留一些資源，總體機器成本只下降到了平時的 70%，而在非大促期間，不須要預留這些資源，就能更低，降到 40% 如下。

如今都說 DevOPS，而 Serverless 最大的好處是減小運維，減小固定服務器資源，不須要用戶關心調度等，同時也簡化了開發的代碼，專一了邏輯，晚上睡覺會更加的放心，再也不擔憂機器容量不足而報警。

另外一邊，對於咱們應用治理的人來講，以前會考慮各類版本碎片化的問題，node 的多版本，框架的多版本，以及啓動腳本、依賴等等問題，而使用 Serverless
以後，咱們將這些都固化了，用戶也不關心這些，一切都變的簡單了，咱們也只須要治理運行時一個版本便可。

在業務前端方面，帶來的是挑戰和機遇，一方面，前端的工做量增大了，能幹的事情也變多了，成了一職多能的多面手，也更瞭解業務了，另外一方面，傳統的後端能夠從和前端溝通中解放出來，更專一於提供服務。前端從傳統的面向接口編程變成了面向服務編程，因爲集團內都是 RPC 服務，在 RPC 發佈時會有固定的定義和文檔，在調用時有工具輔助生產代碼，大大簡化了調用鏈路。

在流程方面，原來須要在各個環境準備和調研，從一開始申請應用，申請預算，申請環境開始，須要瞭解各個方面的知識，和不一樣部門的人打交道，流程審批也很長，而如今只須要在咱們的統一研發平臺上直接申請函數組，替代了本來的複雜流程，也提高了整個開發體驗。

同時在編碼中也再也不考慮路由，MVC 的事情，這些在網關層配置就好，編寫代碼時會更關注邏輯，和以前的構建發佈不一樣的是，如今增長了雲端集成測試的步驟，因爲函數和前端代碼同樣，是分版本的，也不擔憂修改到線上的正常服務，在測試完畢後，只須要將舊函數的 tag 指向新函數便可，這就完成了整個切流的過程，而一旦碰到問題，把 tag 切回去就行。

這就是咱們前端研發模式升級的思考和收益，帶給咱們的不只僅是變化，更多的是流程、思惟的革新。

思考

在研發模式升級過程當中，咱們針對現有的導購業務進行了重構，能夠說是使用了 Serverless 的方式進行了重寫，而有一些老的應用，若是總體進行改造，這個成本會很是之大。

這個時候開發者就會有很常見的一個疑問：我原來的應用，怎麼遷移到 Serverless 體系？

而咱們的回答是兩種：

• 使用 FaaS + Baas 的方式進行重構，代碼更精簡，就是須要改形成本
• 把整個傳統應用做爲一個函數，雖然不夠優雅，可是能解決遷移的問題

把整個應用遷移到函數會有一些限制，會對代碼結構和模型作一些微調，以符合整個 Serverless 的結構，畢竟新的體系和傳統的代碼模型是有所區別的。

阿里集團採用的是 FaaS + BaaS 的實現方式，而 FaaS 的總體概念和傳統的應用不太同樣。

在概念上，Serverless 比 FaaS 的外延要廣，FaaS 屬於 Serverless 的其中一種實現方式，主要解決的是用戶自定義的代碼邏輯如何作到 Serverless，也能夠叫作 Serverless Compute，同時它也是事件驅動架構的一種。

而 CNCF Serverless 白皮書中也說到，Serverless Compute 是一種粒度更細的部署模型，經過一個或者多個 function，用於響應用戶的需求。能夠說，粒度小，靈活性高是它的最大特性。

在代碼層面，爲了讓用戶更好的理解，咱們把傳統代碼的結構進行了分解，傳統的 MVC 類型的代碼，會分爲幾層。

• HTTP 服務，原框架（koa/midway/egg…)，Node.js 運行時，啓動腳本等，將會變爲函數運行時，固化下來
• 原有的 HTTP Router，Web 中間件等，將會由 HTTP 網關承接
• 原有的 Controller，業務邏輯（調用遠程服務），繼續保留，變爲函數代碼
• 原有的數據庫，消息隊列，RPC 調用等，都做爲 BaaS 服務，用戶只關心對應的服務，使用同一的 BaaS Client 進行調用

這樣分解事後，咱們對新舊兩個體系的代碼結構有了進一步認識，能夠開始嘗試修改部分代碼，變成真正的 Serverless。

遷移

傳統的應用，會暴露出一些對外的服務供外部調用，好比 HTTP,定時任務,RPC 服務等等，這些服務通常咱們會單獨抽離目錄，而且和其餘暴露的服務共享邏輯層代碼，咱們也常常稱這些服務爲「入口」。

在 Serverless(FaaS) 化的過程當中，咱們會根據當前部署平臺的能力（好比阿里雲 FC，騰訊 SCF 都會提供 HTTP 服務，定時任務，消息隊列等等），將這些入口代碼變爲基於事件驅動的函數。

咱們經過構建機制，在發佈時生成不一樣的包，在共享一份邏輯代碼的同時，部署到不一樣的環境，這個方案最大的優點是複用了原有的邏輯部分，能夠和傳統應用同步開發，而劣勢也有，就是包依賴混在一塊兒，因爲函數對包大小有限制，可能會形成依賴過大等問題。

HTTP 相對於其餘的來講會複雜不少，會有不少限制，這個咱們在講下游方案的時候再說。

針對上面的狀況，對下游的數據調用咱們也有相應的方案。咱們將這些方案取了幾個名字，好比代理模式和網關模式。

▐ 代理模式

首先來看看代理模式。一個傳統的 Web 應用會分爲 Router/Controller，以及邏輯層，在代理模式中，咱們會保留傳統的應用，只將本來的邏輯層部分遷移到了雲函數中，暴露出 HTTP 服務。

這樣的好處是代碼變的精簡，改動適中，也易於服務複用，缺點就是依舊會佔用一個應用資源做爲代理層。

而代理應用通常是經過 HTTP 客戶端代理來實現的只是用戶體感上須要作一些額外的支持，讓開發者在體驗上感受到是調用了遠端服務。

▐ 網關模式

第二種方式是網關模式，這個模式下，全部的代碼都會遷移到新的體系，在 Web 層簡單的時候比較適用。

該模式下，全部傳統的 Web Router 會遷移到 HTTP Gateway 上，本來的路由，會話、鑑權等能力都將被網關所控制，而函數自己不須要關心這些，只須要關心數據便可。

業界現有的 FaaS 模型大可能是這種結構，集團內也採用了這類結構去實踐。

在這種模式下，原有的能力會碰到一些問題，舉一些例子：

• 原有的 Web 中間件（koa middlware），會不知道如何處理，中間件大可能是作請求流的攔截和消費，這個時候大多會拆成兩部分，一部分被網關所處理，另外一部分，只能交給函數自己，若是有共享的需求，也能夠依賴模塊來完成
• 原有的會話維持，一部分平臺會進行透傳 cookie，這個時候你依舊能夠維持一個 sessionId，同時使用第三方來存儲數據，可是若是網關不作這塊，那麼就很麻煩了
• 請求對象和原有的不一樣，因爲函數獲取的是 event，context 參數，或者原始的 request 對象，和現有的 koa 等框架不是很一致，上面的方法不必定有，會致使原有的代碼作出修改和挑戰

▐ 假裝者模式

那麼有沒有不修改代碼的方案呢？咱們嘗試在函數外部進行代碼包裹和數據模擬，讓應用整個跑在函數之上，以一種 「微應用」 的方式繼續存在。

咱們把原有的 Web Server（midway/egg)，啓動起來，在運行時中經過一個固定的端口轉發，把 FaaS 的請求參數包裹成 HTTP Request 對象，而在出口處，也將 HTTP Response 包裹爲函數能讀懂的形式，經過這樣續命的方式來延續傳統應用。而因爲阿里雲上的容器只讀不能寫，目前還沒法直接用這種模式。

這種方式須要調整的是，框架須要使用單進程模型（機器配置，輕量化的要求），應用須要無狀態（函數機制決定），以及沒有長鏈接等高消耗的操做。

總結

關於 Serverless 的問題還有不少，本文也只是介紹了其中一部份內容，從阿里當前的情況講起，分享了從去年到今年的研發模式升級實踐，也介紹了在這其中咱們的一些思考，傳統應用遷移到 FaaS 體系下的方式。後續的整套方案也會在通過雙十一的洗禮，大流量的考驗後，開放給你們。

One More Thing

淘系技術部依託淘系豐富的業務形態和海量的用戶數據，咱們持續以技術驅動產品和商業創新，不斷探索和衍生顛覆型互聯網新技術，以更加智能、友好、普惠的科技深度重塑產業和用戶體驗，打造新商業。咱們不斷吸引用戶增加、機器學習、視覺算法、音視頻通訊、數字媒體、移動技術、端側智能等領域全球頂尖專業人才加入，讓科技引領面向將來的商業創新和進步。

請投遞簡歷至郵箱：ruoqi.zlj@taobao.com

---

本文做者：陳仲寅（張挺）

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。