作者 | 林昱(蘇河)
來源|
阿裡巴巴雲原生公衆号技術的成熟度源自大規模的實踐，在 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 研發平台
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