傳統業務在開發上線的過程中，需要團隊合作，每個人開發一部分，合併程式碼，開發聯調，然後進行資源評估，測試環境搭建、線上環境搭建、測試上線、運維。但是在 Serverless 時代下，開發者只需要開發自己那部分功能/函式，然後部署到測試環境、線上環境即可，後期很大一部分運維工作都不用考慮和擔心。
今天大家對是不是該用 Serverless 存在疑問，很大程度上是因為缺少成功的案例和最佳實踐。今年雙11，阿里雲實現了國內首例 Serverless 在核心業務場景下的大規模落地，扛住了全球最大規模的流量洪峰，創造了 Serverless 落地應用的里程碑。
如何讓更多企業和開發者將 Serverless 應用到業務場景中，也就是讓 Serverless 從理念到落地，是一個棘手的問題。
例如傳統專案如何遷移到 Serverless，同時保障遷移過程業務連續性，在 Serverless 架構下如何提供完善的開發工具、有效的除錯診斷工具，如何利用 Serverless 做更好的節約成本等，每一個都是難題。尤其涉及到在主流場景大規模的落地 Serverless ，更是並非易事。正因為這樣，業界對於核心業務場景規模化落地 Serverless 最佳實踐的呼喚更加迫切。
接下來我們來看看 Serverless 在落地過程中會遇到的痛點。
Serverless 落地之痛痛點1：冷啟動耗時長
快彈是 Serverless 天然自帶的屬性，但是快彈的條件是要有極致的冷啟動速度去支撐。在非核心業務上，毫秒級別的延時，對業務來說幾乎不受影響。但是，對於核心業務場景，延時超過 500 毫秒已經會影響到使用者體驗。雖然 Serverless 利用輕量化的虛擬技術，不斷的降低冷啟動，甚至某些場景能降低到 200 毫秒以下。
但這也只是理想的獨立執行場景，在核心業務鏈路上，使用者不僅是執行自己的業務邏輯，還要依賴中介軟體、資料庫、儲存等後端服務，這些服務的連線都要在例項啟動的時候進行建立連線，這無形中加大了冷啟動的時間，進而把冷啟動的時間加長到秒級別。對於核心線上業務場景來說，秒級別的冷啟動是不可接受的。
痛點2：與研發流程割裂
Serverless 主打的場景是像寫業務函式一樣去寫業務程式碼，簡單快速即可上線，讓開發者在雲上寫程式碼，輕鬆完成上線。然而在現實中，核心業務的要求把開發者從雲上拉回到現實，面對幾個靈魂拷問：如何做測試？如何灰度上線？如何做業務的容災？如何控制權限？當開發者回答完了這些問題，就會變的心灰意冷，原來在核心業務上線中，“函式正常執行”只佔了小小的一環，離上線的距離還有長江那麼長。
痛點3：中介軟體的連通問題
核心線上業務不是獨立函式孤立執行的，需要連線儲存、中介軟體、資料中後臺服務，獲取資料後再計算，進而輸出返回給使用者。傳統中介軟體客戶端需要打通和客戶的網路、初始化建連等一系列操作，往往會使函式啟動速度下降很多。Serverless 場景下例項生命週期短、數量多，會導致頻繁建連、連線數多的問題，因此針對線上核心應用常用的中介軟體的客戶端進行網路連通最佳化，同時對呼叫鏈路進行監控資料打通，幫助 SRE （Site Reliability Engineer ）從業者更好的評估函式的下游中介軟體依賴情況，對於核心應用遷移上 Serverless 非常重要。
痛點4：可觀測性差
使用者大多數的核心業務應用多采用微服務架構，看核心業務應用的問題也就會帶有微服務的特性，比如使用者需要對業務系統的各種指標進行非常詳盡的檢查，不僅需要檢查業務指標，還需要檢查業務所在系統的資源指標，但是在 Serverless 場景中沒有機器資源的概念，那這些指標如何透出？是否只透出請求的錯誤率和併發度，就可以滿足業務方的需求？
實際上，業務方的需求遠不止這些。可觀測性做的好壞還是源於業務方是否信任你的技術平臺。做好可觀測性是贏得使用者信任的重要前提。
痛點5：遠端除錯難度高
當核心業務出現線上問題時，需要立即進入調查，而調查的第一要素就是：現場的保留，然後登入進行除錯。而在 Serverless 場景中沒有機器層面的概念，所以如果使用者想登入機器，在現有的 Serverless 基礎技術之上是很難做到的。當然原因不僅限於此，比如 Vendor-lockin 的擔心等。
上面幾大類痛點的概括，主要是針對開發者的開發體驗，對於實際的開發場景中，是否真的是"提效"，而不是新瓶裝舊酒。目前仍有大部分核心應用開發者對 Serverless 還是持有觀望狀態，當然也不乏一些質疑觀點，認為 FaaS 只適合小業務場景以及非核心業務場景。
果真如此嗎？
Serverless 的雙11 “大考”2019 年 12 月諮詢公司 O'Reill釋出 Serverless 使用調研中，已有 40% 的受訪者所在的組織採用了 Serverless。2020 年 10 月，中國資訊通訊研究院釋出的《中國雲原生使用者調研報告》指出：“Serverless 技術顯著升溫，近 30%的使用者已在生產環境中應用。”
2020 年，越來越多企業選擇加入 Serverless 陣營，翹首以待更多 Serverless 規模化落地核心場景的案例。
面對 Serverless 開發者數量的穩步增長的現狀，阿里巴巴年初就制定了“打造 Servrelss 雙11”的策略，目的不只是單純的去抗流量、打峰值，而是切實的降成本，提高資源利用率，透過“雙11 技術鍊金爐”把阿里雲 Serverless 打造成更安全、更穩定、更友好的雲產品，幫助使用者實現更大的業務價值。
與過去 11 年的雙11都不同的是，繼去年天貓雙11核心系統上雲後，阿里巴巴基於數字原生商業作業系統，實現了全面雲原生化，底層硬核技術升級帶來了澎湃動力和極致效能。以支撐訂單建立峰值為例，每萬筆峰值交易的 IT 成本較四年前下降了80%，Serverless 也迎來了首次在雙11 核心場景下的規模化落地。
場景一：前端多場景
2020雙11，阿里巴巴集團前端全面擁抱雲原生 Serverless，淘系、飛豬、高德、CBU、ICBU、優酷、考拉等，共同落地了以 Node.js FaaS 線上服務架構為核心的雲端一體研發模式。今年雙11在保障穩定性、高資源利用率的前提下，多業務線的重點營銷導購場景實現了研發模式升級。前端 FaaS 支撐的雲端一體研發模式交付平均提效 38.89%。依託 Serverless 的便利性和可靠性，淘寶、天貓、飛豬等 雙11 會場頁面快捷落地 SSR 技術，提高了使用者頁面體驗，除了保障大促以外，日常彈性下也較以往減少 30% 計算成本。
場景二：個性化推薦場景
Serverless 天然的彈性伸縮能力，是“個性化推薦業務場景”選擇由 Serverless 實現的最重要原因，數以千計的異構應用運維成本一直是這個場景下的痛點。
透過 Serverless 化進一步釋放運維，讓開發者專注於業務的演算法創新。目前這個場景的應用範圍越來越廣，已經覆蓋了幾乎整個阿里系 APP：淘寶，天貓，支付寶，優酷，飛豬等等，因此我們可以對機器資源利用率方面做更多的最佳化，透過智慧化的排程，在峰值時的機器資源利用率達到了 60%。
場景三：中、後臺場景
2020年，世紀聯華雙11基於阿里雲函式計算（FC）彈性擴容，在大促會場 SSR、線上商品秒殺、優惠券定點發放、行業導購、資料中臺計算等多個場景進行應用，業務峰值 QPS 超過 2019 年 雙11 的 230%，研發效率交付提效超過 30%，彈性資源成本減少 40% 以上。
當然，適用於 Serverless 的場景還有很多，需要更多行業的開發者們共同豐富。總的來說，今年 FaaS 的成績單非常耀眼，在 雙11 大促中，不僅承接了部分核心業務，流量也突破新高，幫助業務扛住了百萬 QPS 的流量洪峰。
阿里雲如何擊破 Serverless 痛點？那麼，面對行業共有的Serverless落地之痛，阿里雲是如何克服的呢？
1. 預留模式 + 按量模式消除冷啟動
在 2019 年的 Serverless 2.0 重大升級中，阿里雲函式計算率先支援了預留模式，接著 AWS Lambda 幾個月後，也上線了類似的功能。
為什麼阿里雲會率先要解決這一難題？
阿里雲 Serverless 團隊不斷探索真實業務的需求，按量模式的按需付費模式，雖然非常的誘人，但是冷啟動時間過長，因此把核心線上業務拒之門外。接下來阿里雲著重分析了核心線上業務的訴求：延時小，保證資源彈性。那如何解決呢？
請看下圖，這是一個非常典型的業務曲線圖，用預留模式方式滿足底部固定的量，用彈效能力去滿足 burst 的需求。針對 burst 擴容，我們利用兩種擴容方式結合進行滿足：按資源擴容與按請求擴容，比如使用者可以只設置 CPU 資源的擴容閾值為 60%，當例項的 CPU 達到閾值後就會觸發擴容。此時的新請求並沒有立即到擴容例項，而是等待例項準備好後再導流，從而避免了冷啟動。同理，如果只設置了併發度指標的擴容閾值為 30（每一個例項承載的併發度），同樣滿足這個條件後，也會觸發同樣流程的擴容。如果兩個指標都進行了設定，那麼先滿足的條件會先觸發擴容。
透過豐富的伸縮方式，阿里雲函式計算解決了 Serverless 冷啟動的問題，很好的支撐了延時敏感業務。
2. 核心業務研發提效 38.89%
“提升效率”本應該是 Serverless 的優勢，但對於核心應用來說，"快" = "風險大"，使用者需要經過 CI 測試，日常測試，預發測試，灰度部署等幾個流程驗證，才能確保函式的質量。這些流程是阻礙核心應用使用 FaaS 的絆腳石。
針對於這個問題，阿里雲函式計算的策略是“被整合”，把研發平臺的優勢與阿里雲函式計算進行結合，既能滿足使用者的 CI/CD 流程，又能享受到 Serverless 的紅利，幫使用者跨過使用 FaaS 的鴻溝。
阿里集團內部透過暴露標準的 OpenAPI 與各個核心應用的研發平臺進行整合，經過雙十一業務研發的驗證，研發效率大大提高了 38.89 %。在公有云上與雲效平臺整合，把研發流程與 FaaS 結合的更緊密、更順暢，幫助集團外的業務提高人效。
3. 中介軟體連通
核心應用離不開上下游的配合，一旦核心應用使用了函式計算，又該如何與中介軟體相配合？
傳統應用開發需要整合各類中介軟體的 SDK，進行打包上線，但對於 Serverless 的函式來說，程式碼包的大小就是一個硬傷，這個問題將將直接影響冷啟動的時間。阿里雲函式計算經過兩個階段的發展，第一個階段我們透過搭建中介軟體 Proxy，透過 Proxy 去打通中介軟體，函式只用單一的協議與 Proxy 進行互動，從而 offload 掉中介軟體的 SDK 的包袱。
第二個階段：隨著中介軟體能力的下沉，一些控制型別的需求也被提上了議程，比如：命令下發，流量管理，配置拉取等等，期間阿里雲擁抱了開源元件 Dapr，利用 Sidecar 的方式 Offload 中間的互動成本。上述的方案，是基於阿里雲函式計算的 Custom Runtime，以及 Custom Container 功能完成的。
4. 極致的開發體驗
遠端除錯、日誌檢視、鏈路追蹤、資源利用率，以及完善周邊工具鏈是開發者的必備能力，阿里雲函式計算同時啟動了不同的攻關小組。
首先與 Tracing/ARMS 結合，打造清晰的鏈路追蹤能力，與 SLS整合打造了全面的業務資料監控。因此，業務可以根據需求進行自定義，並且擁抱開源產品 Prometheus 暴露出資源利用率，支援遠端除錯能力的 WebIDE。
再加上阿里雲近期剛開源的重磅武器：Serverless-Devs ，一個無廠商繫結的、幫助開發者在 Serverless 架構下實現開發/運維效率翻倍的開發者工具。開發者可以簡單、快速的建立應用、專案開發、專案測試、釋出部署等，實現專案的全生命週期管理。
Serverless 初始的痛點有很多，為什麼阿里雲卻能把 Serverless 落地到各行各業？首先，阿里雲提供了所有云廠商中最完整的 Serverless 產品矩陣，包括函式計算 FC、Serverless 應用引擎 SAE、面向容器編排的 ASK、以及面向容器例項的 ECI。豐富的產品矩陣能夠覆蓋不同的場景，比如針對事件觸發場景，函式計算提供了豐富的事件源整合能力和百毫秒伸縮的極致彈性；而針對微服務應用，Serverless 應用引擎能做到零程式碼改造，讓微服務也能享受 Serverless 紅利。
其次， Serverless 是一個快速發展的領域，阿里雲在不斷拓展 Serverless 的產品邊界。例如函式計算支援容器映象、預付費模式、例項內併發執行多請求等多個業界首創的功能，徹底解決了冷啟動帶來的效能毛刺等 Serverless 難題，大大拓展了函式計算的應用場景。
最後，阿里經濟體擁有非常豐富的業務場景，可以進一步打磨 Serverless 的落地實踐。今年，阿里經濟體的淘系、考拉、飛豬、高德等都在雙11核心業務場景使用了阿里雲函式計算 FC，並順利扛住了雙11的流量高峰。
Serverless 引領下一個十年“勞動生產力的最大激進，以及運用勞動時所表現的更大熟練、技巧和判斷力，似乎都是勞動分工的結果。”
這是摘自《國富論》的一段話，強調的是“勞動分工” 的利害關係，任何一個行業，市場規模越大，分工將會越細，這也是著名的“斯密定理”。
同樣，這一定理也適用於軟體應用市場行業。隨著傳統行業進入了網際網路化階段，市場規模越來越大，勞動分工越來越細，物理機託管時代已經成為了歷史，被成熟的 IaaS 層取代，隨之而來的是容器服務，目前也已經是行業的標配。
那麼，接下來的技術十年是什麼呢？答案是：Serverless。
Serverless 抹平了研發人員在預算、運維經驗上的不足，在對抗業務洪峰的情況下，絕大多數研發也能輕易掌控處理，不僅極大地降低了研發技術門檻，同時大規模提升了研發效率，線上預警、流量觀測等工具一應俱全，輕鬆做到了技術研發的免運維。
可以說 Serverless 是更細粒度的分工，讓業務開發者不再關注底層運維，只關注於業務創新，以此大大提高了勞動生產力，這就是“斯密定理”效應，也是 Serverless 成為未來必然趨勢的內在原因。
當下，整個雲的產品體系已經 Serverless 化，70% 以上的產品都是 Serverless 形態。物件儲存、訊息中介軟體、API 閘道器、表格儲存等 Serverless 產品已經被廣大開發者熟知。而下一個十年， Serverless 將重新定義雲的程式設計模型，重塑企業創新的方式。