阿里云Serverless助力企業(yè)全面擁抱云原生

作者：洛浩

Serverless 應用引擎的組件架構(gòu)

最早的時候，大家設計軟件一般按照單體架構(gòu)，包括和軟件相關(guān)的數(shù)據(jù)庫，存儲等，會直接部署到一臺物理服務器上。但是單體應用的問題在于，隨著企業(yè)的規(guī)模逐步增大，擴展性較差，發(fā)布效率非常低。后來，就進入了微服務時代，微服務主要用的框架是基于 Java 語言。微服務架構(gòu)的一個優(yōu)勢在于迭代效率非常高，擴展性也比較好，但是微服務對資源的占用和成本相對較高。隨著技術(shù)的演進，容器化加速了微服務的落地。但并不是所有的企業(yè)都適合微服務，隨著系統(tǒng)復雜性的提升，微服務的效率，運維成本也在增加。企業(yè)選用單體架構(gòu)，還是微服務取決于系統(tǒng)的復雜程度。

隨著公有云的發(fā)展，越來越多的用戶會把業(yè)務部署到云上。隨著云的使用深度越高，架構(gòu)的優(yōu)勢也就越明顯。第一階段叫 Rehost，就是重新托管，使用云主機替換本地物理服務器，不改應用，但是這種托管模式是最基礎使用云的方式，它的效率并沒有達到最大化。隨著進一步的發(fā)展，我們需要 Re-platform，使用托管的云服務替換自建應用基礎設施，基本不改應用。但 Re-platform 也不是最好的一種方式，隨著進一步的發(fā)展，我們可以重新去架構(gòu)這個應用，即 Refactor。這個時候，可以用微服務加容器的方式，重構(gòu)底層架構(gòu)和軟件架構(gòu)，把云的價值發(fā)揮到最大。從長期來看，整體的收益是最大的，但是短期內(nèi)它的遷移成本要求也是比較高的。

如果應用能夠按照云上原生的產(chǎn)品或服務進行重構(gòu)開發(fā)，就能夠最深的享受云計算的便利性。但與此同時它有幾個問題：

• 投入成本（遷移/改造）；

• 云廠商綁定程度；

• 云的易用性（上手門檻/維護）；

• 安全性。

阿里云推出了 Serverless 應用引擎（SAE），專門針對應用或者微服務，提供一個全托管的平臺。比如 Java 微服務，目前可以做到零改造遷移部署到云上，并且支持完整的微服務治理能力。如果用戶想做容器化升級，也可以使用這個平臺。

Serverless 應用引擎的核心技術(shù)

SAE 由哪些組件構(gòu)成？是怎樣把各種產(chǎn)品能力結(jié)合到一起的？可以看下這個組件架構(gòu)。圖中綠色部分，是用戶需要關(guān)注的，是各種各樣的業(yè)務應用。同時，SAE 會提供各種工具，比如 Cloudtoolkit 插件輔助本地代碼部署到云端，比如對接云效提供流水線能力。圖中橘黃色部分，就是 SAE 平臺，會提供很多種能力。比如說寫了一個商城應用，前臺就是一個獨立的服務模塊，可以單獨迭代、開發(fā)或者管理。還可以給前臺服務配置彈性策略，例如在大促期間，前臺服務可以根據(jù)實際流量自動彈性伸縮，這個也是 SAE 的一個核心價值。所以 SAE，既可以提供資源管理能力，又能提供應用生命周期管理、微服務治理，是一個全托管式的應用平臺。在資源層面，SAE 封裝了K8s 集群，K8s 之下是基礎設施，由神龍服務器和安全容器構(gòu)建，SAE 在資源層面，會幫助用戶提供資源管理和調(diào)度能力。

接下來講一下 SAE 的核心能力。首先，我們先看一下傳統(tǒng)企業(yè)用戶部署應用的整個流程，首先是需要購買 ECS 資源，然后搭一個集群，對集群進行初始化，然后構(gòu)建環(huán)境。研發(fā)開發(fā)完成后，開始進行測試部署，另外還要去部署監(jiān)控、日志等組件。等業(yè)務全部上線后，就進入維護狀態(tài)，包括資源的運維和業(yè)務的運維。而使用 SAE 可以省掉很多步驟，首先底層的 K8s 集群由云廠商來維護，用戶只用提交鏡像或者 JAR 包，就可以把系統(tǒng)部署到 SAE 平臺。其次，監(jiān)控和日志系統(tǒng)，這些已經(jīng)由平臺提供，用戶只需要關(guān)注業(yè)務邏輯，不需要去維護資源。

如果用戶想要做灰度發(fā)布該怎么辦？SAE 也給用戶提供了單批、分批、金絲雀等發(fā)布策略。讓部署到平臺上的業(yè)務能夠做到不停機更新，這個能力也是默認就提供的。

關(guān)于用戶訴求非常強烈的金絲雀發(fā)布，SAE 可以以做到按請求內(nèi)容灰度 ，和按流量比例灰度。比如要做流量比例灰度，分批發(fā)布直接 50%，兩批即可發(fā)完。同時，也可以按照精準的流量比例進行灰度。

用戶使用這個平臺也會非常關(guān)注彈性能力，而 SAE 提供了非常豐富的彈性配置。可以基于基礎監(jiān)控指標（CPU、Mem）和業(yè)務監(jiān)控指標（QPS 、RT）來觸發(fā)水平伸縮 。按照這種負載模型去做彈性擴縮容，一般比較適用于突發(fā)流量、或者有典型脈沖的應用場景。比如互聯(lián)網(wǎng)游戲，社交平臺。第二種是定時彈性，這種模型比較適合像餐飲，出行這種有波峰波谷的應用場景。

那么彈性效率能不能跟得上彈性訴求呢？正常情況下，當我們把一個鏡像部署到平臺，系統(tǒng)要經(jīng)過一個資源調(diào)度，然后創(chuàng)建 POD，拉用戶鏡像，創(chuàng)建容器，啟動容器等幾個步驟。為了提升這個效率，SAE 首先針對應用做了原地升級能力。就是針對應用升級發(fā)布，可以直接在原有資源上，直接拉用戶最新的鏡像進行更新和部署，避免重建 POD，從而幫用戶提升了 42% 的部署效率。

其次，SAE 還做了鏡像加速能力，能幫用戶提升 30% 的彈性效率。也就是在用戶在創(chuàng)建容器的時候，會同步按需去拉取用戶鏡像，可以降低服務啟動時間。

第三，SAE 針對 Java  應用的啟動也做了加速。提供的 Dragonwell JDK版本，可以在 JVM 和進程啟動的時候，生成緩存，再應用二次啟動的時候，進行加速，縮短啟動時間。

最后，SAE 會給用戶提供這種監(jiān)控和應用診斷能力，可以查詢服務的調(diào)用鏈、接口的響應耗時、GC 次數(shù)、慢 SQL 等，幫用戶快速定位問題。

Serverless 應用引擎的最佳實踐

微服務/應用遷移到 SAE，大概有幾個步驟。首先如果是單體，可以直接打一個壓縮包，部署到平臺上來，但是單體應用需要做存算分離，也就是數(shù)據(jù)庫和計算代碼分離開，把計算部分部署到 SAE。微服務應用可以選擇寫一個 docker file，做成鏡像，然后推到鏡像倉庫，即可完成部署。微服務應用也可以選擇打成 JAR/WAR 包直接部署到 SAE。

關(guān)于降本方面，SAE 也推出了一鍵啟停功能。針對不同的環(huán)境，可以開啟定時起停應用。比如對于測試環(huán)境，在晚上沒人用的時候，就可以把測試環(huán)境直接關(guān)掉，來節(jié)省成本。

SAE 提供多種工具和方法來構(gòu)建 DevOps 體系。比如大部分企業(yè)用戶常用的 Jenkins，或者選擇云上的云效等來做 CI/CD。在應用側(cè)，可以在 SAE 平臺配置定時啟停、監(jiān)控告警等完成業(yè)務運維。

關(guān)于企業(yè)用戶比較關(guān)注的環(huán)境管理和權(quán)限劃分，SAE 推薦使用命名空間，來做環(huán)境的隔離，不同的命名空間下的應用是不能互訪的。另外，SAE 推薦使用權(quán)限助手來給不同的團隊，生成對應命名空盡或者應用服務的權(quán)限策略，最終做到不同團隊之間的應用，相互不可見不可操作。

還有的用戶會關(guān)注 SAE 和 ECS 比，做了哪些能力增強呢？首先是提供的這種免運維全托管能力，其次是一站式的全應用生命周期管理能力，以及針對微服務的治理和優(yōu)化、應用監(jiān)控等，都是 SAE 給用戶提供的增值體驗。

Serverless 應用引擎的客戶案例

第一個 Timing app，是在教育領域的在線課程學習 app，它是典型單體應用重構(gòu)成微服務，遷移到 SAE 平臺。隨著疫情的發(fā)展，Timing 的流量激增之后，原有架構(gòu)難以承載業(yè)務的發(fā)展，開始做微服務改造。在微服務化的過程當中選了 SAE 平臺，像用戶中心，學習中心，自習中心、圖書館中心等等，都被拆成獨立的服務模塊。對比使用云主機自建微服務的方式，大約節(jié)省 35% 成本。

另外想要分享的案例是愛奇藝·體育，其整個業(yè)務都部署在 SAE 平臺上。在今年 6、7 月份的時候，愛奇藝·體育轉(zhuǎn)播了歐洲杯賽事，當時的流量非常高；但是體育賽事結(jié)束之后，流量又開始回落，因此彈性能力對其尤為重要。而 SAE 豐富的彈性能力，可以幫助節(jié)省大量的運維開銷，擴容效率比之前提升了 40%。其次內(nèi)置的應用監(jiān)控平臺，在業(yè)務遇到問題的時候，排障處理效率也提升了 30%。整體上 SAE 幫助愛奇藝·體育還提升了近 50% 的資源利用率。

相信隨著云計算的發(fā)展，Serverless 將成為云時代默認的計算范式，越來越多的企業(yè)客戶將會采用這個技術(shù)。