Serverless 應(yīng)用引擎的組件架構(gòu)
最早的時(shí)候,大家設(shè)計(jì)軟件一般按照單體架構(gòu),包括和軟件相關(guān)的數(shù)據(jù)庫,存儲等,會直接部署到一臺物理服務(wù)器上。但是單體應(yīng)用的問題在于,隨著企業(yè)的規(guī)模逐步增大,擴(kuò)展性較差,發(fā)布效率非常低。后來,就進(jìn)入了微服務(wù)時(shí)代,微服務(wù)主要用的框架是基于 Java 語言。微服務(wù)架構(gòu)的一個(gè)優(yōu)勢在于迭代效率非常高,擴(kuò)展性也比較好,但是微服務(wù)對資源的占用和成本相對較高。隨著技術(shù)的演進(jìn),容器化加速了微服務(wù)的落地。但并不是所有的企業(yè)都適合微服務(wù),隨著系統(tǒng)復(fù)雜性的提升,微服務(wù)的效率,運(yùn)維成本也在增加。企業(yè)選用單體架構(gòu),還是微服務(wù)取決于系統(tǒng)的復(fù)雜程度。
隨著公有云的發(fā)展,越來越多的用戶會把業(yè)務(wù)部署到云上。隨著云的使用深度越高,架構(gòu)的優(yōu)勢也就越明顯。第一階段叫 Rehost,就是重新托管,使用云主機(jī)替換本地物理服務(wù)器,不改應(yīng)用,但是這種托管模式是最基礎(chǔ)使用云的方式,它的效率并沒有達(dá)到最大化。隨著進(jìn)一步的發(fā)展,我們需要 Re-platform,使用托管的云服務(wù)替換自建應(yīng)用基礎(chǔ)設(shè)施,基本不改應(yīng)用。但 Re-platform 也不是最好的一種方式,隨著進(jìn)一步的發(fā)展,我們可以重新去架構(gòu)這個(gè)應(yīng)用,即 Refactor。這個(gè)時(shí)候,可以用微服務(wù)加容器的方式,重構(gòu)底層架構(gòu)和軟件架構(gòu),把云的價(jià)值發(fā)揮到最大。從長期來看,整體的收益是最大的,但是短期內(nèi)它的遷移成本要求也是比較高的。
如果應(yīng)用能夠按照云上原生的產(chǎn)品或服務(wù)進(jìn)行重構(gòu)開發(fā),就能夠最深的享受云計(jì)算的便利性。但與此同時(shí)它有幾個(gè)問題:
投入成本(遷移/改造);
云廠商綁定程度;
云的易用性(上手門檻/維護(hù));
安全性。
阿里云推出了 Serverless 應(yīng)用引擎(SAE),專門針對應(yīng)用或者微服務(wù),提供一個(gè)全托管的平臺。比如 Java 微服務(wù),目前可以做到零改造遷移部署到云上,并且支持完整的微服務(wù)治理能力。如果用戶想做容器化升級,也可以使用這個(gè)平臺。
SAE 由哪些組件構(gòu)成?是怎樣把各種產(chǎn)品能力結(jié)合到一起的?可以看下這個(gè)組件架構(gòu)。圖中綠色部分,是用戶需要關(guān)注的,是各種各樣的業(yè)務(wù)應(yīng)用。同時(shí),SAE 會提供各種工具,比如 Cloudtoolkit 插件輔助本地代碼部署到云端,比如對接云效提供流水線能力。圖中橘黃色部分,就是 SAE 平臺,會提供很多種能力。比如說寫了一個(gè)商城應(yīng)用,前臺就是一個(gè)獨(dú)立的服務(wù)模塊,可以單獨(dú)迭代、開發(fā)或者管理。還可以給前臺服務(wù)配置彈性策略,例如在大促期間,前臺服務(wù)可以根據(jù)實(shí)際流量自動(dòng)彈性伸縮,這個(gè)也是 SAE 的一個(gè)核心價(jià)值。所以 SAE,既可以提供資源管理能力,又能提供應(yīng)用生命周期管理、微服務(wù)治理,是一個(gè)全托管式的應(yīng)用平臺。在資源層面,SAE 封裝了K8s 集群,K8s 之下是基礎(chǔ)設(shè)施,由神龍服務(wù)器和安全容器構(gòu)建,SAE 在資源層面,會幫助用戶提供資源管理和調(diào)度能力。
接下來講一下 SAE 的核心能力。首先,我們先看一下傳統(tǒng)企業(yè)用戶部署應(yīng)用的整個(gè)流程,首先是需要購買 ECS 資源,然后搭一個(gè)集群,對集群進(jìn)行初始化,然后構(gòu)建環(huán)境。研發(fā)開發(fā)完成后,開始進(jìn)行測試部署,另外還要去部署監(jiān)控、日志等組件。等業(yè)務(wù)全部上線后,就進(jìn)入維護(hù)狀態(tài),包括資源的運(yùn)維和業(yè)務(wù)的運(yùn)維。而使用 SAE 可以省掉很多步驟,首先底層的 K8s 集群由云廠商來維護(hù),用戶只用提交鏡像或者 JAR 包,就可以把系統(tǒng)部署到 SAE 平臺。其次,監(jiān)控和日志系統(tǒng),這些已經(jīng)由平臺提供,用戶只需要關(guān)注業(yè)務(wù)邏輯,不需要去維護(hù)資源。
如果用戶想要做灰度發(fā)布該怎么辦?SAE 也給用戶提供了單批、分批、金絲雀等發(fā)布策略。讓部署到平臺上的業(yè)務(wù)能夠做到不停機(jī)更新,這個(gè)能力也是默認(rèn)就提供的。
關(guān)于用戶訴求非常強(qiáng)烈的金絲雀發(fā)布,SAE 可以以做到按請求內(nèi)容灰度 ,和按流量比例灰度。比如要做流量比例灰度,分批發(fā)布直接 50%,兩批即可發(fā)完。同時(shí),也可以按照精準(zhǔn)的流量比例進(jìn)行灰度。
用戶使用這個(gè)平臺也會非常關(guān)注彈性能力,而 SAE 提供了非常豐富的彈性配置??梢曰诨A(chǔ)監(jiān)控指標(biāo)(CPU、Mem)和業(yè)務(wù)監(jiān)控指標(biāo)(QPS 、RT)來觸發(fā)水平伸縮 。按照這種負(fù)載模型去做彈性擴(kuò)縮容,一般比較適用于突發(fā)流量、或者有典型脈沖的應(yīng)用場景。比如互聯(lián)網(wǎng)游戲,社交平臺。第二種是定時(shí)彈性,這種模型比較適合像餐飲,出行這種有波峰波谷的應(yīng)用場景。
那么彈性效率能不能跟得上彈性訴求呢?正常情況下,當(dāng)我們把一個(gè)鏡像部署到平臺,系統(tǒng)要經(jīng)過一個(gè)資源調(diào)度,然后創(chuàng)建 POD,拉用戶鏡像,創(chuàng)建容器,啟動(dòng)容器等幾個(gè)步驟。為了提升這個(gè)效率,SAE 首先針對應(yīng)用做了原地升級能力。就是針對應(yīng)用升級發(fā)布,可以直接在原有資源上,直接拉用戶最新的鏡像進(jìn)行更新和部署,避免重建 POD,從而幫用戶提升了 42% 的部署效率。
其次,SAE 還做了鏡像加速能力,能幫用戶提升 30% 的彈性效率。也就是在用戶在創(chuàng)建容器的時(shí)候,會同步按需去拉取用戶鏡像,可以降低服務(wù)啟動(dòng)時(shí)間。
第三,SAE 針對 Java 應(yīng)用的啟動(dòng)也做了加速。提供的 Dragonwell JDK版本,可以在 JVM 和進(jìn)程啟動(dòng)的時(shí)候,生成緩存,再應(yīng)用二次啟動(dòng)的時(shí)候,進(jìn)行加速,縮短啟動(dòng)時(shí)間。
最后,SAE 會給用戶提供這種監(jiān)控和應(yīng)用診斷能力,可以查詢服務(wù)的調(diào)用鏈、接口的響應(yīng)耗時(shí)、GC 次數(shù)、慢 SQL 等,幫用戶快速定位問題。
微服務(wù)/應(yīng)用遷移到 SAE,大概有幾個(gè)步驟。首先如果是單體,可以直接打一個(gè)壓縮包,部署到平臺上來,但是單體應(yīng)用需要做存算分離,也就是數(shù)據(jù)庫和計(jì)算代碼分離開,把計(jì)算部分部署到 SAE。微服務(wù)應(yīng)用可以選擇寫一個(gè) docker file,做成鏡像,然后推到鏡像倉庫,即可完成部署。微服務(wù)應(yīng)用也可以選擇打成 JAR/WAR 包直接部署到 SAE。
關(guān)于降本方面,SAE 也推出了一鍵啟停功能。針對不同的環(huán)境,可以開啟定時(shí)起停應(yīng)用。比如對于測試環(huán)境,在晚上沒人用的時(shí)候,就可以把測試環(huán)境直接關(guān)掉,來節(jié)省成本。
SAE 提供多種工具和方法來構(gòu)建 DevOps 體系。比如大部分企業(yè)用戶常用的 Jenkins,或者選擇云上的云效等來做 CI/CD。在應(yīng)用側(cè),可以在 SAE 平臺配置定時(shí)啟停、監(jiān)控告警等完成業(yè)務(wù)運(yùn)維。
關(guān)于企業(yè)用戶比較關(guān)注的環(huán)境管理和權(quán)限劃分,SAE 推薦使用命名空間,來做環(huán)境的隔離,不同的命名空間下的應(yīng)用是不能互訪的。另外,SAE 推薦使用權(quán)限助手來給不同的團(tuán)隊(duì),生成對應(yīng)命名空盡或者應(yīng)用服務(wù)的權(quán)限策略,最終做到不同團(tuán)隊(duì)之間的應(yīng)用,相互不可見不可操作。
還有的用戶會關(guān)注 SAE 和 ECS 比,做了哪些能力增強(qiáng)呢?首先是提供的這種免運(yùn)維全托管能力,其次是一站式的全應(yīng)用生命周期管理能力,以及針對微服務(wù)的治理和優(yōu)化、應(yīng)用監(jiān)控等,都是 SAE 給用戶提供的增值體驗(yàn)。
第一個(gè) Timing app,是在教育領(lǐng)域的在線課程學(xué)習(xí) app,它是典型單體應(yīng)用重構(gòu)成微服務(wù),遷移到 SAE 平臺。隨著疫情的發(fā)展,Timing 的流量激增之后,原有架構(gòu)難以承載業(yè)務(wù)的發(fā)展,開始做微服務(wù)改造。在微服務(wù)化的過程當(dāng)中選了 SAE 平臺,像用戶中心,學(xué)習(xí)中心,自習(xí)中心、圖書館中心等等,都被拆成獨(dú)立的服務(wù)模塊。對比使用云主機(jī)自建微服務(wù)的方式,大約節(jié)省 35% 成本。
另外想要分享的案例是愛奇藝·體育,其整個(gè)業(yè)務(wù)都部署在 SAE 平臺上。在今年 6、7 月份的時(shí)候,愛奇藝·體育轉(zhuǎn)播了歐洲杯賽事,當(dāng)時(shí)的流量非常高;但是體育賽事結(jié)束之后,流量又開始回落,因此彈性能力對其尤為重要。而 SAE 豐富的彈性能力,可以幫助節(jié)省大量的運(yùn)維開銷,擴(kuò)容效率比之前提升了 40%。其次內(nèi)置的應(yīng)用監(jiān)控平臺,在業(yè)務(wù)遇到問題的時(shí)候,排障處理效率也提升了 30%。整體上 SAE 幫助愛奇藝·體育還提升了近 50% 的資源利用率。
相信隨著云計(jì)算的發(fā)展,Serverless 將成為云時(shí)代默認(rèn)的計(jì)算范式,越來越多的企業(yè)客戶將會采用這個(gè)技術(shù)。