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 奇點己來,所謂奇點,是由平穩發展轉向高速發展的轉折點,預示著行業落地將開始全面爆發。而我們也將成為見證這個變化的一代技術人。
- 如何使用 rust 寫核心模組
- Dubbo 在 Proxyless Mesh 模式下的探索與改進
- 工作一年,我重新理解了《重構》
- 談談我對於關鍵思考的理解
- 談談我工作中的23個設計模式
- 談談我工作中的23個設計模式
- Serverless 奇點已來,下一個十年將駛向何方?
- 阿里巴巴重磅開源雲原生閘道器: Higress
- 我們總結了 3 大使用建議,並首次公開 Nacos3.0 規劃圖 | Nacos 開源 4 週年
- SAE 助力貴州酒店集團從容支撐貴州特產搶購
- 甩掉容量規劃炸彈:用 AHPA 實現 Kubernetes 智慧彈性伸縮
- 聊聊降本提效這件事兒
- 主流定時任務解決方案全橫評
- 通過Jenkins構建CI/CD實現全鏈路灰度
- 一站式動態多環境建設案例
- Proxyless Mesh 在 Dubbo 中的實踐
- ChaosBlade Java 場景效能優化,那些你不知道的事
- 新零售標杆 SKG 全面擁抱 Serverless,實現敏捷交付
- 「技術人生」第9篇:如何設定業務目標
- 面向物件分析與設計的底層邏輯