作者:洛浩
視訊解析
點選此處,可檢視相關直播回放~Serverless 應用引擎的元件架構
最早的時候,大家設計軟體一般按照單體架構,包括和軟體相關的資料庫,存儲等,會直接部署到一台實體伺服器上。但是單體應用的問題在于,随着企業的規模逐漸增大,擴充性較差,釋出效率非常低。後來,就進入了微服務時代,微服務主要用的架構是基于 Java 語言。微服務架構的一個優勢在于疊代效率非常高,擴充性也比較好,但是微服務對資源的占用和成本相對較高。随着技術的演進,容器化加速了微服務的落地。但并不是所有的企業都适合微服務,随着系統複雜性的提升,微服務的效率,運維成本也在增加。企業選用單體架構,還是微服務取決于系統的複雜程度。
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLicmbw5SY2UTMxIGZ4ImZ0QGO4cjYzQmZ0ATOjVzMwcTZlNzMm9CX5d2bs92Yl1iclB3bsVmdlR2LcNWaw9CXt92Yu4GZjlGbh5yYjV3Lc9CX6MHc0RHaiojIsJye.png)
随着公有雲的發展,越來越多的使用者會把業務部署到雲上。随着雲的使用深度越高,架構的優勢也就越明顯。第一階段叫 Rehost,就是重新托管,使用雲主機替換本地實體伺服器,不改應用,但是這種托管模式是最基礎使用雲的方式,它的效率并沒有達到最大化。随着進一步的發展,我們需要 Re-platform,使用托管的雲服務替換自建應用基礎設施,基本不改應用。但 Re-platform 也不是最好的一種方式,随着進一步的發展,我們可以重新去架構這個應用,即 Refactor。這個時候,可以用微服務加容器的方式,重構底層架構和軟體架構,把雲的價值發揮到最大。從長期來看,整體的收益是最大的,但是短期内它的遷移成本要求也是比較高的。
如果應用能夠按照雲上原生的産品或服務進行重構開發,就能夠最深的享受雲計算的便利性。但與此同時它有幾個問題:
- 投入成本(遷移/改造);
- 雲廠商綁定程度;
- 雲的易用性(上手門檻/維護);
- 安全性。
阿裡雲推出了 Serverless 應用引擎(SAE),專門針對應用或者微服務,提供一個全托管的平台。比如 Java 微服務,目前可以做到零改造遷移部署到雲上,并且支援完整的微服務治理能力。如果使用者想做容器化更新,也可以使用這個平台。
Serverless 應用引擎的核心技術
SAE 由哪些元件構成?是怎樣把各種産品能力結合到一起的?可以看下這個元件架構。圖中綠色部分,是使用者需要關注的,是各種各樣的業務應用。同時,SAE 會提供各種工具,比如 Cloudtoolkit 插件輔助本地代碼部署到雲端,比如對接雲效提供流水線能力。圖中橘黃色部分,就是 SAE 平台,會提供很多種能力。比如說寫了一個商城應用,前台就是一個獨立的服務子產品,可以單獨疊代、開發或者管理。還可以給前台服務配置彈性政策,例如在大促期間,前台服務可以根據實際流量自動彈性伸縮,這個也是 SAE 的一個核心價值。是以 SAE,既可以提供資源管理能力,又能提供應用生命周期管理、微服務治理,是一個全托管式的應用平台。在資源層面,SAE 封裝了K8s 叢集,K8s 之下是基礎設施,由神龍伺服器和安全容器建構,SAE 在資源層面,會幫助使用者提供資源管理和排程能力。
接下來講一下 SAE 的核心能力。首先,我們先看一下傳統企業使用者部署應用的整個流程,首先是需要購買 ECS 資源,然後搭一個叢集,對叢集進行初始化,然後建構環境。研發開發完成後,開始進行測試部署,另外還要去部署監控、日志等元件。等業務全部上線後,就進入維護狀态,包括資源的運維和業務的運維。而使用 SAE 可以省掉很多步驟,首先底層的 K8s 叢集由雲廠商來維護,使用者隻用送出鏡像或者 JAR 包,就可以把系統部署到 SAE 平台。其次,監控和日志系統,這些已經由平台提供,使用者隻需要關注業務邏輯,不需要去維護資源。
如果使用者想要做灰階釋出該怎麼辦?SAE 也給使用者提供了單批、分批、金絲雀等釋出政策。讓部署到平台上的業務能夠做到不停機更新,這個能力也是預設就提供的。
關于使用者訴求非常強烈的金絲雀釋出,SAE 可以以做到按請求内容灰階 ,和按流量比例灰階。比如要做流量比例灰階,分批釋出直接 50%,兩批即可發完。同時,也可以按照精準的流量比例進行灰階。
使用者使用這個平台也會非常關注彈性能力,而 SAE 提供了非常豐富的彈性配置。可以基于基礎監控名額(CPU、Mem)和業務監控名額(QPS 、RT)來觸發水準伸縮 。按照這種負載模型去做彈性擴縮容,一般比較适用于突發流量、或者有典型脈沖的應用場景。比如網際網路遊戲,社交平台。第二種是定時彈性,這種模型比較适合像餐飲,出行這種有波峰波谷的應用場景。
那麼彈性效率能不能跟得上彈性訴求呢?正常情況下,當我們把一個鏡像部署到平台,系統要經過一個資源排程,然後建立 POD,拉使用者鏡像,建立容器,啟動容器等幾個步驟。為了提升這個效率,SAE 首先針對應用做了原地更新能力。就是針對應用更新釋出,可以直接在原有資源上,直接拉使用者最新的鏡像進行更新和部署,避免重建 POD,進而幫使用者提升了 42% 的部署效率。
其次,SAE 還做了鏡像加速能力,能幫使用者提升 30% 的彈性效率。也就是在使用者在建立容器的時候,會同步按需去拉取使用者鏡像,可以降低服務啟動時間。
第三,SAE 針對 Java 應用的啟動也做了加速。提供的 Dragonwell JDK版本,可以在 JVM 和程序啟動的時候,生成緩存,再應用二次啟動的時候,進行加速,縮短啟動時間。
最後,SAE 會給使用者提供這種監控和應用診斷能力,可以查詢服務的調用鍊、接口的響應耗時、GC 次數、慢 SQL 等,幫使用者快速定位問題。
Serverless 應用引擎的最佳實踐
微服務/應用遷移到 SAE,大概有幾個步驟。首先如果是單體,可以直接打一個壓縮包,部署到平台上來,但是單體應用需要做存算分離,也就是資料庫和計算代碼分離開,把計算部分部署到 SAE。微服務應用可以選擇寫一個 docker file,做成鏡像,然後推到鏡像倉庫,即可完成部署。微服務應用也可以選擇打成 JAR/WAR 包直接部署到 SAE。
關于降本方面,SAE 也推出了一鍵啟停功能。針對不同的環境,可以開啟定時起停應用。比如對于測試環境,在晚上沒人用的時候,就可以把測試環境直接關掉,來節省成本。
SAE 提供多種工具和方法來建構 DevOps 體系。比如大部分企業使用者常用的 Jenkins,或者選擇雲上的雲效等來做 CI/CD。在應用側,可以在 SAE 平台配置定時啟停、監控告警等完成業務運維。
關于企業使用者比較關注的環境管理和權限劃分,SAE 推薦使用命名空間,來做環境的隔離,不同的命名空間下的應用是不能互訪的。另外,SAE 推薦使用權限助手來給不同的團隊,生成對應命名空盡或者應用服務的權限政策,最終做到不同團隊之間的應用,互相不可見不可操作。
還有的使用者會關注 SAE 和 ECS 比,做了哪些能力增強呢?首先是提供的這種免運維全托管能力,其次是一站式的全應用生命周期管理能力,以及針對微服務的治理和優化、應用監控等,都是 SAE 給使用者提供的增值體驗。
Serverless 應用引擎的客戶案例
第一個 Timing app,是在教育領域的線上課程學習 app,它是典型單體應用重構成微服務,遷移到 SAE 平台。随着疫情的發展,Timing 的流量激增之後,原有架構難以承載業務的發展,開始做微服務改造。在微服務化的過程當中選了 SAE 平台,像使用者中心,學習中心,自習中心、圖書館中心等等,都被拆成獨立的服務子產品。對比使用雲主機自建微服務的方式,大約節省 35% 成本。
另外想要分享的案例是愛奇藝·體育,其整個業務都部署在 SAE 平台上。在今年 6、7 月份的時候,愛奇藝·體育轉播了歐洲杯賽事,當時的流量非常高;但是體育賽事結束之後,流量又開始回落,是以彈性能力對其尤為重要。而 SAE 豐富的彈性能力,可以幫助節省大量的運維開銷,擴容效率比之前提升了 40%。其次内置的應用監控平台,在業務遇到問題的時候,排障處理效率也提升了 30%。整體上 SAE 幫助愛奇藝·體育還提升了近 50% 的資源使用率。
相信随着雲計算的發展,Serverless 将成為雲時代預設的計算範式,越來越多的企業客戶将會采用這個技術。
戳下方
此處,前往 Serverless 社群官網檢視更多相關資訊吧!