做者 | 林昱(蘇河) 來源|阿里巴巴雲原生公衆號前端
技術的成熟度源自大規模的實踐，在 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 雲研發平臺是經過提供哪些能力保障各租戶業務的快速開發和安全交付的。框架
研發的本質
你們可能都在「人員協同、服務可靠性」上支付着高額的人力成本，但研發的本質是交付「業務功能」。less
今天，咱們從傳統的「前端開發者」慢慢走向「應用研發者」，摸爬滾打不容易，除了須要去思考「什麼是真正的按需付費」、「彈性」等底層運維相關的命題以外，還須要去考慮「研發效能」相關命題，這也是爲何有更高效的協同模式、組織關係的變化，甚至整個先後端協同的生產關係都在發生變化的緣由，今天咱們談「雲端一體」，本質是從用戶的視角去思考問題，用更高效的方式去解決業務問題。運維
現在，軟件開發對於成本的控制要求愈來愈高，單位時間的產能會慢慢成爲衡量一個團隊是否高效的標準。ide
所以從研發的本質，咱們來看看 Serverless 雲研發平臺要解決的命題：函數
- 讓業務開發變輕，聚焦業務邏輯；
- 讓業務開發變快，提高產研效率；
- 讓基礎設施變厚，提高穩定性。
圖爲 Serverless 雲研發平臺架構圖
Serverless 方案定製能力來完善雲端一體研發者市場，提供開發者更多選擇、打造雲端一體的研發集成閉環來提供業務更快的交付速度、以及業務低成本的使用基礎 BaaS 服務能力以及業務 BaaS 成爲研發平臺的核心抓手。
Serverless 研發平臺
1. 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 個典型的解決方案。
1）一體化解決方案
一體化應用解決方案是基於 Midway Hooks 提供的上層業務雲端一體解決方案，藉助 Serverless + Hooks + 「零」 API 調用的特性，開發者在研發流程中僅需關注業務邏輯，便可高效完成應用的交付。
一體化應用在使用時，具備諸多的優點：
- 易於開發，先後端同倉庫，無縫融合一體開發
- 易於部署，先後端一同發佈與部署
- 易於維護，後端代碼使用Serverless 部署，運維難度低
而在開發時，咱們也提供了諸多的功能來幫助開發者加速研發。
「零 API 調用」
Hooks 支持
在阿里內部，咱們提供了中後臺一體化與搭建模塊一體化兩種解決方案。其中，中後臺一體化應用在內部已經落地了 300+ 應用，快速且高效的支撐了各個 BU 的中後臺需求。
2）淘系模型驅動解決方案
模型驅動是淘寶導購業務開發過程當中沉澱的一種開發方式，面向導購大量的召回補全展示需求。經過配置面板，將模型、數據來源、插件配置組合，最終生成業務邏輯代碼，供業務消費。
整個操做面板的核心關注點在右側的流程畫布上，咱們但願使用固定的流程來解決這一類業務問題，這些邏輯聽從預約義的操做路徑。在雲市場輕應用外包介入開發的模式中，由內部同窗生成物料，外包同窗開發模塊和選擇業務字段並串聯流程，幫助內部同窗節省了大量流程串聯和模塊聯調成本，相比傳統的開發方式總體提效10%左右。這也是一種創新的協同模式，物料豐富後會有更大的提高空間。
數據源（召回） --> 模型（補全） --> 擴展邏輯（插件）
模型驅動解決方案在淘寶很好的解決了業務問題，可是面臨更多的場景須要的是更加靈活的模板定製能力，所以將來模型驅動會在靈活的模板配置化上發力、對節點物料的沉澱上創建更加完善的機制、支持Web IDE等插件，並在更多的場景上支持業務的落地，讓不一樣的業務場景能夠更加便利的創建本身的「三板斧」。
3）考拉 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 微應用級別的解決方案，天貓行業團隊研發的面向輕店場景的原生小程序一體化解決方案等，這裏不展開一一介紹了。
2. 函數穩定性保障
最開始的時候，咱們關注的重點是如何用 Node 完成業務邏輯，好比數據怎麼組織、 Java 二方包怎麼調用、怎麼結合阿拉丁鏈路、線上 bug 怎麼快速修復。如今有了這麼多線上運行的業務，咱們關注的重點已經從怎麼完成業務需求，轉變成如何高效地、穩定地完成業務需求。
線上穩定性，本質上是對問題的治理。從問題出發，能夠分爲如下幾個主要環節：預防問題、發現問題、定位問題和解決問題。
- 在預防問題上，要儘量下降問題發生的機率和縮小影響面，作好上線卡口，以及作好對應的預案。
- 發現問題上要儘量實現全鏈路監控，以及實現合理有效的報警分發機制。
- 定位問題上，要儘量縮短問題的定位時間，在報警元信息的基礎上，作一些機器的輔助分析，關聯上下文，從而作到半自動定位或提供更多有邏輯的上下文，來縮短人爲定位問題的時間。在解決問題上，要保證解決方案的有效，安全以及快速。
3. 大促穩定性保障手段
大促場景下， C 端場景須要重保，如下的穩定性保障手段經歷數次大促壓測，同時越是大促態，整個穩定性保障也愈發緊張。
穩定性是保障了，可是在以前咱們是對照上述的文檔完成上線流程的，流程冗長無比，最終並沉澱成一個做戰手冊，同時這些內容沒法和應用關聯，離散在文檔角落，整個過程「又臭又長」。
上線流程 -> 做戰手冊一體化
所以，Serverless 研發平臺上但願規範化整個流程，從從 強弱依賴梳理 -> 預案配置 -> 監控報警訂閱 -> 單鏈路壓測 -> 做戰手冊生成，記錄全部函數上線過程，流程可追溯，文檔可沉澱；另外預案、壓測、監控等流程作到半自動化，減小上線時間。咱們將每一個流程節點定義成一個 SOP 單元，這樣根據業務特性能夠進行 SOP 流程的隨意組裝。
發佈 SOP 流程
經過半自動化流程生產的做戰手冊，函數和做戰手冊關聯的硬盤化記錄方式，並結合自動限流和下游依賴分析以及預案生產，例如：經過預發流量錄製的回放，自動分析出函數下游的強弱依賴，並錄入強依賴負責人，方便出現線上問題的時候能夠第一時間找到負責人排查問題；根據不一樣租戶對單元化的需求，平臺能夠幫助用戶進行多機房、多單元部署實現異地多活。這些都可以讓業務的大促態變得更輕鬆一些。
淘系業務做戰手冊
4. 專家應急響應
爲解決線上問題定位慢的痛點，平臺還提供了應急響應系統，當函數成功率下降觸發報警時，平臺會自動拉取函數以及下游多項數據信息，進行錯誤分析，快速產出錯誤報告推送給函數開發者。並引導開發者回到研發平臺進行切流、執行預案等止血操做。例如，下游服務強依賴服務A成功率降低，致使函數自身成功率降低，須要聯繫服務 A 負責同窗。
1）租戶運維
平臺上的每一個租戶都有對應的租戶管理員，對各自租戶的函數穩定性負責，包括租戶下函數的單元化部署規則、大促管控、自建網關配置、容器額度、租戶私有解決方案等，爲此平臺提供了一系列運維工具。
2）租房大盤
幫助管理員更好的觀測到租戶下函數的服務質量，和容器額度使用情況，提供函數錯誤率和 RT 黑榜，而且每週都會有治理週報推送給管理員，幫助其更好的進行運維其租戶下的函數。
3）函數盤點
幫助管理員細緻的觀測每一個函數線上運行的具體狀態，包括函數線上存在的版本、容器數量、 Runtime 版本、灰度、單元部署情況，甚至能夠觀測到函數部署是否均衡。
4）大促管控
平臺還提供針對大促態的運維管控能力，管理員能夠將租戶下參與大促的函數服務一鍵切換到大促態，進行大促態的額外配置，好比大促容量配置，Broker 側限流，網關側統一監控預案等能力，保障大促的穩定。
一些思考
Serverless 雲研發平臺後續將在提高用戶正向和逆向流程的效率上繼續演進，L1 是但願讓用戶低成本的上手，L2 是但願讓用戶低成本的進行研發，讓前端往應用研發更進一步。
如下是基於用戶正向研發鏈路耗時統計的一些分析：
- 技術方案產出的時間較久，佔比總體研發週期 5%，核心緣由是服務物料難以檢索以及服務可用性難以評估，領域模型沉澱不足。
- FaaS 總體研發佔比 25%~30%；模型驅動等可視化編排在物料準備完備的狀況下，可以提效，可是不具有規模化場景。
- 聯調耗時較久佔總體成本 20% 左右，過分依賴預發環境，據統計，完成一個項目須要部署 50 次。
- 壓測成本依然存在，平臺熟悉成本太高。
固然還有監控運維逆向鏈路的一些分析：
- 報警分發不許確，因如今沒法區分報警是底層框架和上層業務的問題，因此每每須要架構組和業務同窗的共同介入。
- 定位問題效率低，如失敗率報警，多是底層架構的問題也有多是下游的問題，還有多是機房或者自身的問題，每每須要去多個平臺逐一排查。
- 缺少對服務質量的統計或總體認知。
- 缺少能針對 80% 線上問題的排查和解決的標準化流程，依賴用戶對問題的定位和解決能力。
最後
Serverless 雲研發平臺通過這半年多的蛻變，已經從簡單的解決工程鏈路的平臺演進成一個面向研發、上線、運維的全生命週期研發平臺，後續要解決的命題會集中在用戶低門檻上。
但願咱們在 Serverless 上的實踐和探索，能給業內其餘公司帶去一些啓發，讓路上的障礙變少，讓應用的研發變輕。
課程推薦
爲了更多開發者可以享受到 Serverless 帶來的紅利，這一次，咱們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。
點擊便可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless