Serverless 奇點已來，下一個十年將駛向何方？_阿里巴巴中介軟體

引言：

以前構建應用，需要買 ECS 例項，搭建開源軟體體系然後維護它，流量大了擴容，流量小了縮容，整個過程非常複雜繁瑣。

用了 Serverless 服務以後，這些問題都簡化了，從半托管到全託管，所有服務 API 化，無限容量充分彈性，可以組裝使用，生產力大幅改變。同時推動軟體研發模式升級，組裝式研發將成為主流。

基於阿里雲全面 Serverless 化的經歷，阿里巴巴研究員、阿里雲智慧雲原生應用平臺總經理丁宇（叔同）闡述了企業應用架構的演進歷程，以及 Serverless 興起帶來的行業變化。

本文整理自 QCon 上海站 2022 丁宇（叔同）的演講內容。

過去十年，上雲成為確定性的趨勢。

在上雲階段，企業關注點在於如何實現平滑上雲，因此雲廠商將雲託管（Cloud-Hosting）作為核心策略。雲的主要形態是資源型服務，以虛擬機器的形式為企業提供海量的算力。

對開發者而言，虛擬機器的功能和使用方式和 IDC 中的物理伺服器沒有區別。原有的應用、技術棧不需要改變就可以平滑上雲。雲託管的策略很好地滿足了企業在上雲階段的核心訴求，因此取得了成功。

隨著越來越多的企業上雲，甚至很多企業系統第一天就是在雲上構建，企業的核心關注點轉變為如何更好地利用雲的能力，將產品快速推向市場，從而實現業務成功。

這促使雲在下一階段發展的主要目標轉變為利用雲自身的優勢，解決大規模複雜應用的開發和運維挑戰。但是，如果算力的呈現形式仍然是伺服器這樣的資源形態，它的使用門檻依然很高。算力和業務相隔太遠，企業需要有一整套支撐應用的基礎設施來用好算力。

如何讓算力像電力一樣的普及，雲端計算需要新的形態。

雲服務的角色將發生巨大的變化，不再是單純的提供資源，而是要成為企業構建應用的新平臺，要幫助企業儘可能減小機器運維等低價值重複工作，聚焦於業務的創新。

下一個十年，是雲演進自身能力，幫助企業用好雲的階段，而云廠商的核心能力就是 Serverless 雲服務。

為什麼選擇 Serverless

Serverless 服務是全託管的。

雲廠商可以通過儲存計算分離，軟硬協同優化等底層技術，大規模提高服務的資源效率和效能。以阿里雲端儲存服務為例，自 2018 年開始大規模使用 RDMA 技術，自研了 Solar-RDMA 協議，以及 HPCC 流控和端網融合技術。

通過網路和儲存的協同設計，結合 FPGA 硬體加速壓縮演算法等能力，實現了穩定的微秒級的讀寫效能。企業只需要呼叫服務 API，就能使用雲廠商在相關領域的專業能力，享受到技術紅利。

Serverless 服務具備自適應彈性， 讓企業的應用更平穩的應對業務負載不可預測或者突然爆發的情況。

一個典型的業務系統可劃分為應用層、接入層、資源層。資源型的雲服務只提供了資源層面的彈效能力，企業還需要實現接入層和應用層的彈效能力，才能做到業務的全鏈路彈性。

架構設計階段，根據各個元件的依賴關係，制定彈性伸縮和限流降級方案。對於關係型資料庫等幾乎沒有彈效能力的服務，一般需要預測未來3年對資料庫的寫入和讀取規模，進行分庫分表。
資源規劃階段，權衡各個元件的擴縮容難易度、伸縮速度、業務負載變化速度等因素，通過冗餘資源實現相應的彈效能力。接入層資源佔比在整個系統不高，維持較高冗餘資源成本不高，也比較容易擴容。應用層的資源規劃最具挑戰。應用層是資源消耗大頭，一般不允許通過很高的冗餘資源來扛住負載峰值，此外應用層的擴縮容牽扯上下游鏈路，複雜度很高。最後，應用層不同服務的流量規模不同，需要梳理清楚，重點做好熱點鏈路的冗餘資源規劃。
線上執行階段，通過完整的可觀測能力，建立量化鏈路的流量，檢測熱點，進行動態擴縮容，再量化熱點鏈路流量，再判斷是否進行動態擴縮容的閉環。此外，完整、及時的監控報警也是十分必要的，為不同元件設定不同的熱度閾值，檢測到熱度流量後，系統要及時的廣播給關聯元件的開發、運維人員，根據預定方案進行處理。

可見，在資源層的彈效能力上構建整個業務的彈效能力複雜度非常高。Serverless 服務的自適應彈性目標就是為了簡化複雜度，幫助企業更容易實現業務彈性。

首先雲廠商會將大量中介軟體、資料庫、大資料等 BaaS 化的服務 Serverless 化。以資料庫為例，不但提供 NoSQL 等天然具備高彈效能力的資料庫服務，也將傳統的關係型資料庫 Serverless 化。

其次， Serverless 計算服務通常具備百毫秒到秒級的例項啟動速度，每秒鐘啟動數千甚至上萬例項，以及高度自動化的彈性伸縮能力，配合 Serverless 化的 BaaS 服務，將實現全鏈路的業務彈性。

最後，Serverless 服務通常內建了限流降級的能力，讓企業資源可控，更容易應對系統雪崩的問題。

如何高效的利用好資源，是企業面臨的一個普遍的難題。業界資料中心的統計資料表明，企業整體平均資源利用率是不高的，一般小於 15%。要提高資源利用率，企業一般面臨以下挑戰：

各個業務部門資源使用相互獨立，沒有資源並池，沒有統一排程。
出於對效能、負載峰值以及業務未來發展保障等因素的考慮，業務部門一般傾向於多申請資源，通常是實際使用資源的 3-5 倍。
非核心應用碎片化的資源消耗導致了大量資源浪費。大量非核心應用為了滿足高可用的要求，至少需要 2-3 臺機器，而這些應用很多時候是長尾、低頻呼叫的，甚至業務下線但伺服器忘了釋放，造成資源浪費。在阿里巴巴集團，非核心應用消耗的資源甚至超過了核心應用。
不同性質的應用沒有共享資源，沒有削峰填谷，叢集整體資源利用率不高。

容器化是提高資源利用率的有效手段，但實施的複雜度較高。阿里巴巴集團通過全棧容器化，統一排程和離線上混部來提升資源的整體利用率，涉及到容器效能的優化、租戶隔離、底層伺服器算力歸一化、定製的資源統一排程和離線上混部等等。

Serverless 的目標讓企業用更簡單的方式提高資源利用率，降低成本。

以函式計算為例，企業不需要為閒置資源付費，而是根據實際使用的資源付費。這意味著大量測試、預發甚至生產環境，大量非核心應用碎片化資源的使用場景，使用 Serverless 後資源利用率會非常高。

如果從效能角度考慮，需要預留一些資源，函式計算的閒置資源費用也比伺服器更低。函式計算內建了多 AZ 容災能力，企業不需要為容災準備冗餘資源。函式計算支援百毫秒級別的彈性伸縮速度和豐富的伸縮規則，企業不需要為峰值負載預留資源。

當雲服務演進為 Serverless 形態後，企業的使用門檻大大降低，Serverless 將讓算力像電力一樣普及。

Serverless 引領下一代應用架構驅動研發模式升級

應用架構和研發模式的演變主要是由企業的業務發展訴求推動的。企業總是期望能夠更敏捷的應對業務規模和複雜度的增長，更快的將產品推向市場，加快業務創新的速度，這就要求技術能支援大規模、複雜軟體的快速迭代。

傳統的企業級應用架構，通常是單體的，所有模組都耦合在一起，同時釋出。這種單體架構應用在一開始是易於管理的，但隨著業務發展，會帶來巨大的複雜度。這種強耦合的架構帶來開發、測試和運維過程中大量的衝突，拖慢了整個迭代速度。

例如整個應用的開發要求所有模組採用統一的語言和框架技術棧，如果一個基礎庫被多個模組共享，其中一個模組想要升級到新版本，則需要說服所有人同時升級，即便其他人並不需要新版本。所有模組的釋出節奏被強行拉齊，一個模組的問題會影響整個應用的釋出。

想要快速修復某個模組的線上問題也變得非常困難，因為這需要和其他模組正在進行中的變更合併，解決衝突，重新發布整個應用，執行所有測試，才能重新發布上線。單體應用架構已經不能滿足軟體研發效率的要求，被以微服務為主要特徵的網際網路分散式架構取代。

採用微服務架構後，應用程式由獨立的服務組成。這些服務是鬆耦合的，通過 API 呼叫、事件觸發或者資料流的方式互動。每個服務都完成一個特定的功能，獨立開發、執行和釋出。

微服務解決了單體架構的研發效率瓶頸，但是對應用的基礎設施提出了非常高的要求。

例如，為了確保獨立開發的微服務能夠按預期協調配合，需要進行詳盡的整合和端對端測試。測試環境中的應用部署次數通常是生產環境的 10 倍。如果應用基礎設施不能快速提供獨立的測試環境，那麼大量的測試時間將消耗在環境穩定性問題的解決上。

根據阿里巴巴集團的研發統計資料，1 人日的研發，通常對應 5-7 人日的測試。測試環境已經成為阿里巴巴集團研發提效的最大痛點。

微服務的鬆耦合，也對資料庫使用、狀態管理、問題診斷、應用交付流水線帶來了很大的挑戰。關於微服務的複雜度以及解決方案，業界已經有非常多的討論，這裡不再贅述。

以微服務為核心的網際網路分散式架構，實施的複雜度較高，必須有很好的工具、平臺的支撐，這是業界的共識。

除了微服務架構，企業也廣泛使用反應式架構、事件驅動架構等模式，這些架構都帶來了鬆耦合、敏捷開發等好處，但相應的落地複雜度也變高了。

事實上，業界在應用的構建、編排、執行、BaaS 服務、基礎設施管理等每一方面，都提供了豐富的產品和解決方案，建立了龐大的生態。但企業要整合這些軟體/服務，讓它們彈性、穩定、相互整合良好，加速應用開發迭代，這絕非易事。

而在用好雲的階段，雲的使命就是要消除這種複雜度，帶來大規模複雜軟體開發質的突破，助力企業打破技術鴻溝。

每一個 Serverless 服務都是廠商領域能力的輸出，通過服務 API 透出功能，承諾可靠性、彈性、效能等能力指標，因此他們是高質量的應用構建塊（building blocks）。

例如阿里雲物件儲存（OSS）服務，承載著 EB 級的海量資料，承諾 11 個 9 的資料可靠性，99.95% 的可用性，以及多樣化的資料分級儲存和處理能力。

阿里雲訊息佇列 RocketMQ 歷經雙十一萬億級訊息洪峰的錘鍊，承諾 10 個 9 的資料可靠性，99.95% 的可用性。這些雲服務和企業基於開源軟體自建的系統相比，在彈性、可靠性等方面有明顯的優勢。

不只是雲廠商，大量的開源商業產品也採用了 Serverless 模式，包括 Confluent Cloud、MongoDB Atlas、Snowflake、Databricks 等。

隨著廠商在儲存、計算、中介軟體、大資料等領域推出越來越多的 Serverless 服務，並且這些服務通過事件驅動等方式緊密整合，雲逐漸變成了應用構建和執行的超級平臺，應用的研發模式也升級為組裝式研發。

Serverless 讓雲成為應用構建的最佳平臺

隨著阿里雲提供越來越全面的 Serverless 產品以後，很多雲產品都變成模組化、API 化、服務化，它可以進行組裝，通過拖拉拽的方式就能夠構建應用。

在 Serverless 架構下，研發方式升級為組裝式研發，可以做到流程編排、事件驅動，甚至可以做成視覺化，這就徹底顛覆了原有的軟體研發方式，大幅提升研發效率，靈活應對業務挑戰。根據權威機構調研統計，組裝式研發相比傳統模式，可為研發提效 50% 以上。

從新興的網際網路創業公司，到傳統企業構建大型軟體，都可以使用 Serverless 架構和組裝式研發。

以高德為例，高德的投放業務和使用者生活場景緊密相關，功能多變；推薦的下游業務品類快速增長，投放的業務策略多變；而且整個業務和使用者出行緊密相關，有明顯的峰谷屬性。

隨著業務的增長，投放平臺原有的架構面臨一些明顯的痛點：

重客戶端。卡片處理、導航規劃、頁面展示等邏輯都放在 Web 或者移動裝置上，導致客戶端發版緩慢、程式碼臃腫。
業務功能緊耦合，跟不上業務迭代要求。投放策略多變，每次釋出影響面大。
負載有明顯的峰谷，常駐例項，資源利用率低。

Serverless 架構能很好地解決上述痛點。首先為客戶端瘦身，將端上的邏輯大量的移到 BFF 層（Backends for frontend）。

由於 Serverless 計算零運維，只需要開發業務邏輯，完全由客戶端人員釋出，避免了團隊協作問題。藉助平臺內建的應用平滑釋出的能力，客戶端的人員可以快速迭代，安心釋出。

投放策略等後端服務也解耦為函式的形式，包括規則過濾函式、疲勞提醒函式、內容組裝函式等等。這些函式作為獨立的後端服務開發迭代，每次釋出影響面不大，控制了爆炸半徑。

通過仔細梳理熱點邏輯以及上下游依賴，實現了全鏈路彈性以及介面級流控能力。彈性伸縮不但快速，而且安全，資源用量和負載峰谷匹配，效率高。

目前基於 Serverless 架構的高德業務投放平臺已經承載了 100% 的生產流量，業務規模達到百萬 QPS，功能交付從原來的數天降低到數小時，整體成本降低了 38%。

Serverless 奇點已來

雲端計算的探索者認為，雲端計算的下一個十年預設的計算正規化就是 Serverless 。

2021 年 DataDog 釋出 Serverless 研究報告，資料表明，從雲原生初創公司到大型企業都在關注 Serverless，Serverless 生態已經超越了 FaaS，包含數十種服務，可以幫助開發人員構建更快、更動態的應用程式。

從 2012 年提出 Serverless 到今年 2022 年剛好十年，Serverless 已經成為今天IT開發的主流，也是雲伺服器商提供能力的主流。

我們相信，Serverless 奇點己來，所謂奇點，是由平穩發展轉向高速發展的轉折點，預示著行業落地將開始全面爆發。而我們也將成為見證這個變化的一代技術人。