技術的成熟度源自大規模的實踐，在 Java 領域，阿里將自身的實踐源源不斷的反哺給微服務技術體系；在 Node.js 領域，阿里正掀起了前所未有的前端革命浪潮，將實踐反哺給 Serverless 技術體系，並逐漸拓展到其他多語言體系和後端 BaaS上。

Serverless 雲研發平臺作為阿里巴巴集團前端委員會發起的一體化雲研發平臺，底層基於函數計算 FC，是整個 Node Serverless 體系中的研發入口，承接了淘寶、飛豬、ICBU、考拉、高德、文娛等研發、交付和運維工作。目前，集團已經有上千位前端和客戶端的工程師使用 Serverless 雲研發平臺進行業務的開發工作，包括但不限於營銷導購、中後臺、行業前臺等規模化場景。

從今年雙 11 整體的大盤數據來看， 僅淘系 Node Serverless 的支撐流量就已經從去年的 2K QPS 峰值增加到今年的 30K QPS 峰值，峰值流量增加了近15倍，集團整體更加是從近 5.8K QPS 到達今年的 50K QPS峰值。

解決方案上，我們定製了面向更多場景的能力，包括考拉 Dart 解決方案的落地，以及一些面向導購的模型驅動解決方案；運維上，我們優化了大促態和日常態流程，讓開發者在應對更高 QPS 規模時，精力花費降低至少 50%；在研發體驗側，打造解決方案體系，降低研發門檻，支持前端快速入場，提升研發效率 39%；在底層 Serverless 基座上，我們適配了多個 Serverless 平臺，支持多平臺的實時切換，以應對單一平臺的不確定性。

本文將介紹 Serverless 雲研發平臺是通過提供哪些能力保障各租戶業務的快速開發和安全交付的。

研發的本質

大家可能都在「人員協同、服務可靠性」上支付著高額的人力成本，但研發的本質是交付「業務功能」。

今天，我們從傳統的「前端開發者」慢慢走向「應用研發者」，摸爬滾打不容易，除了需要去思考「什麼是真正的按需付費」、「彈性」等底層運維相關的命題之外，還需要去考慮「研發效能」相關命題，這也是為什麼有更高效的協同模式、組織關係的變化，甚至整個前後端協同的生產關係都在發生變化的原因，今天我們談「雲端一體」，本質是從用戶的視角去思考問題，用更高效的方式去解決業務問題。

如今，軟件開發對於成本的控制要求越來越高，單位時間的產能會慢慢成為衡量一個團隊是否高效的標準。

因此從研發的本質，我們來看看 Serverless 雲研發平臺要解決的命題：

• 讓業務開發變輕，聚焦業務邏輯；
• 讓業務開發變快，提升產研效率；
• 讓基礎設施變厚，提升穩定性。

Serverless 雲研發平臺架構圖

Serverless 方案定製能力來完善雲端一體研發者市場，提供開發者更多選擇、打造雲端一體的研發集成閉環來提供業務更快的交付速度、以及業務低成本的使用基礎 BaaS 服務能力以及業務 BaaS 成為研發平臺的核心抓手。

Serverless 研發平臺

▐ Serverless 業務解決方案

我們定義的解決方案 ：即解決某一橫向或縱向領域的，貫穿創建、研發、交付、運維階段的一系列能力的集合。為什麼當時需要定義解決方案的定製能力，核心原因是面向今天雲端一體化的場景，不同事業部的業務同學有著不同的定製需求。

我們調研了幾個事業部，包含 AE 、考拉、淘系等，起初的 Serverless 雲研發平臺的定製開發能力偏弱，無法很好的承接業務訴求，我們需要讓平臺有一定的開放定製能力，例如淘系面向研發面板的 low code 的定製能力，考拉麵向函數的資損風險等級和應用風險等級錄入等需求。

但是開放能力會涉及創建、研發、交付、運維這幾個階段，每個過程能提供什麼定製能力、開放到什麼程度是要由平臺根據收集到的需求和平臺自身管控要求去綜合考慮的，所謂「人挪活，樹挪死」，結構化了幾個關鍵能力之後 Serverless 雲研發平臺開放解決方案的定製能力在當時多個租戶的調研下產生了。

上圖為結構化幾個可定製節點以及多個場景的調研情況

通過上圖結構化的信息，我們定義瞭解決方案元數據相關信息，示例為中後臺一體化解決方案相關元數據信息。

{
  "name": "ICE-FaaS",
  "display_name": "Web 端一體化",
  "description": "傳統 Web 一體化解決方案，解決中後臺開發需求（ICE、React等），同時支撐中後臺前端頁面和 FaaS 的研發",
  "owner": "*",
  "generator": {
    "id": 30
  },
  "depserver": [],
  "page": {},
  "widget": {},
  "baas": {},                         
  "ide_plugin": ["midway-helper"],     
  "checkConfig": {
    "cf": true,
    "cr": true,
    "fone": true
  },                       
  "flow": {
    "id": 1                          
  },                        
  "ops": {                       
    "resource": [{
      "type": "faas"
    }, {
      "type": "assets"
    }]
  }
}

截止目前，Serverless 雲研發平臺通過共建一共沉澱了 14 個解決方案，包括 5 個通用解決方案和 9 個面向不同租戶的定製化解決方案。

接下去介紹 3 個典型的解決方案。

一體化解決方案

一體化應用解決方案是基於 Midway Hooks 提供的上層業務雲端一體解決方案，藉助 Serverless + Hooks + “零” API 調用的特性，開發者在研發流程中僅需關注業務邏輯，即可高效完成應用的交付。

一體化應用在使用時，具有諸多的優勢：

• 易於開發，前後端同倉庫，無縫融合一體開發
• 易於部署，前後端一同發佈與部署
• 易於維護，後端代碼使用Serverless 部署，運維難度低

而在開發時，我們也提供了諸多的功能來幫助開發者加速研發。

“零 API 調用”

Hooks 支持

在阿里內部，我們提供了中後臺一體化與搭建模塊一體化兩種解決方案。其中，中後臺一體化應用在內部已經落地了 300+ 應用，快速且高效的支撐了各個 BU 的中後臺需求。

淘系模型驅動解決方案

模型驅動是淘寶導購業務開發過程中沉澱的一種開發方式，面向導購大量的召回補全展現需求。通過配置面板，將模型、數據來源、插件配置組合，最終生成業務邏輯代碼，供業務消費。

整個操作面板的核心關注點在右側的流程畫布上，我們希望使用固定的流程來解決這一類業務問題，這些邏輯遵從預定義的操作路徑。在雲市場輕應用外包介入開發的模式中，由內部同學生成物料，外包同學開發模塊和選擇業務字段並串聯流程，幫助內部同學節省了大量流程串聯和模塊聯調成本，相比傳統的開發方式整體提效10%左右。這也是一種創新的協同模式，物料豐富後會有更大的提升空間。

數據源（召回） --> 模型（補全） --> 擴展邏輯（插件）

模型驅動解決方案在淘寶很好的解決了業務問題，但是面臨更多的場景需要的是更加靈活的模板定製能力，因此未來模型驅動會在靈活的模板配置化上發力、對節點物料的沉澱上建立更加完善的機制、支持Web IDE等插件，並在更多的場景上支持業務的落地，讓不同的業務場景可以更加便利的建立自己的“三板斧”。

考拉 Dart 一體化解決方案

考拉大前端自 2020 年 3 月份開始嘗試 Flutter 的應用，部分客戶端和前端同學均參與進 Flutter 的開發，對於 Dart 相對熟悉，所以 Dart 一體化解決方案最初目的主要是考慮幫客戶端同學解決開發提效的問題。考拉之前主要在使 Node.js Runtime 的 Serverless 方案，相比於 Java Script，Dart 對於客戶端同學也更友好一些，同時也不斷有客戶端同學提出 Dart Serverless 的訴求。

在函數計算 FC 研發團隊的幫助下，考拉基於 Dart Runtime 的前期測試版本，快速完成了考拉 App 今日活動 Tab 的改造重構，並已於 9 月底灰度上線。10 月中下旬，基於 Dart Runtime 開始和 DEF 平臺對接，最終 DEF Serverless 創建面板，會透出 Dart 純函數解決方案，目前和 FC 側基本流程已調通，即將上線 Dart 的純函數解決方案。

除了已上線的 Dart Ast 生成服務，考拉將基於 Dart Serverless 方案推出更多的業務場景，如 App 端數據模型的動態下發、業務邏輯的動態配置、Flutter 動態化嘗試，以及 App 跨端搭建能力等。

除了以上 3 個解決方案，ICBU 團隊研發的 EaaS 微應用級別的解決方案，天貓行業團隊研發的面向輕店場景的原生小程序一體化 解決方案等，這裡不展開一一介紹了。

▐ 函數穩定性保障

最開始的時候，我們關注的重點是如何用 Node 完成業務邏輯，比如數據怎麼組織、 Java 二方包怎麼調用、怎麼結合阿拉丁鏈路、線上 bug 怎麼快速修復。現在有了這麼多線上運行的業務，我們關注的重點已經從怎麼完成業務需求，轉變成如何高效地、穩定地完成業務需求。

線上穩定性，本質上是對問題的治理。從問題出發，可以分為以下幾個主要環節：預防問題、發現問題、定位問題和解決問題。

在預防問題上，要儘可能降低問題發生的概率和縮小影響面，做好上線卡口，以及做好對應的預案。發現問題上要儘可能實現全鏈路監控，以及實現合理有效的報警分發機制。定位問題上，要儘可能縮短問題的定位時間，在報警元信息的基礎上，做一些機器的輔助分析，關聯上下文，從而做到半自動定位或提供更多有邏輯的上下文，來縮短人為定位問題的時間。在解決問題上，要保證解決方案的有效，安全以及快速。

大促穩定性保障手段

大促場景下， C 端場景需要重保，以下的穩定性保障手段經歷數次大促壓測，同時越是大促態，整個穩定性保障也愈發緊張。

穩定性是保障了，但是在之前我們是對照上述的文檔完成上線流程的，流程冗長無比，最終並沉澱成一個作戰手冊，同時這些內容無法和應用關聯，離散在文檔角落，整個過程「又臭又長」。

上線流程 -> 作戰手冊一體化

因此，Serverless 研發平臺上希望規範化整個流程，從從 強弱依賴梳理 -> 預案配置 -> 監控報警訂閱 -> 單鏈路壓測 -> 作戰手冊生成，記錄所有函數上線過程，流程可追溯，文檔可沉澱；另外預案、壓測、監控等流程做到半自動化，減少上線時間。我們將每個流程節點定義成一個 SOP 單元，這樣根據業務特性可以進行 SOP 流程的隨意組裝。

發佈SOP流程

通過半自動化流程生產的作戰手冊，函數和作戰手冊關聯的硬盤化記錄方式，並結合自動限流和下游依賴分析以及預案生產，例如：通過預發流量錄製的回放，自動分析出函數下游的強弱依賴，並錄入強依賴負責人，方便出現線上問題的時候可以第一時間找到負責人排查問題；根據不同租戶對單元化的需求，平臺可以幫助用戶進行多機房、多單元部署實現異地多活。這些都能夠讓業務的大促態變得更輕鬆一些。

淘系業務作戰手冊

專家應急響應

為解決線上問題定位慢的痛點，平臺還提供了應急響應系統，當函數成功率降低觸發報警時，平臺會自動拉取函數以及下游多項數據信息，進行錯誤分析，快速產出錯誤報告推送給函數開發者。並引導開發者回到研發平臺進行切流、執行預案等止血操作。例如，下游服務強依賴服務A成功率下降，導致函數自身成功率下降，需要聯繫服務A負責同學。

▐ 租戶運維

平臺上的每個租戶都有對應的租戶管理員，對各自租戶的函數穩定性負責，包括租戶下函數的單元化部署規則、大促管控、自建網關配置、容器額度、租戶私有解決方案等，為此平臺提供了一系列運維工具。

租戶大盤

幫助管理員更好的觀測到租戶下函數的服務質量，和容器額度使用狀況，提供函數錯誤率和 RT 黑榜，並且每週都會有治理週報推送給管理員，幫助其更好的進行運維其租戶下的函數。

函數盤點

幫助管理員細緻的觀測每個函數線上運行的具體狀態，包括函數線上存在的版本、容器數量、 Runtime 版本、灰度、單元部署狀況，甚至可以觀測到函數部署是否均衡。

大促管控

平臺還提供針對大促態的運維管控能力，管理員可以將租戶下參與大促的函數服務一鍵切換到大促態，進行大促態的額外配置，比如大促容量配置，Broker 側限流，網關側統一監控預案等能力，保障大促的穩定。

一些思考

Serverless 雲研發平臺後續將在提升用戶正向和逆向流程的效率上繼續演進，L1 是希望讓用戶低成本的上手，L2 是希望讓用戶低成本的進行研發，讓前端往應用研發更進一步。

以下是基於用戶正向研發鏈路耗時統計的一些分析：

技術方案產出的時間較久，佔比整體研發週期 5%，核心原因是服務物料難以檢索以及服務可用性難以評估，領域模型沉澱不足；
FaaS 整體研發佔比 25%~30% ；模型驅動等可視化編排在物料準備完備的情況下，能夠提效，但是不具備規模化場景；
聯調耗時較久佔整體成本 20% 左右，過度依賴預發環境，據統計，完成一個項目需要部署 50 次；
壓測成本依然存在，平臺熟悉成本過高。

當然還有監控運維逆向鏈路的一些分析：

報警分發不準確，因現在無法區分報警是底層框架和上層業務的問題，所以往往需要架構組和業務同學的共同介入；
定位問題效率低，如失敗率報警，可能是底層架構的問題也有可能是下游的問題，還有可能是機房或者自身的問題，往往需要去多個平臺逐一排查；
缺乏對服務質量的統計或整體認知；
缺乏能針對 80% 線上問題的排查和解決的標準化流程，依賴用戶對問題的定位和解決能力。

最後

Serverless 雲研發平臺經過這半年多的蛻變，已經從簡單的解決工程鏈路的平臺演進成一個面向研發、上線、運維的全生命週期研發平臺，後續要解決的命題會集中在用戶低門檻上。

希望我們在 Serverless 上的實踐和探索，能給業內其他公司帶去一些啟發，讓路上的障礙變少，讓應用的研發變輕。

關注「淘系技術」微信公眾號，一個有溫度有內容的技術社區~