*作者：洛浩*

## Serverless 應用引擎的元件架構

最早的時候，大家設計軟體一般按照單體架構，包括和軟體相關的資料庫，儲存等，會直接部署到一臺物理伺服器上。但是單體應用的問題在於，隨著企業的規模逐步增大，擴充套件性較差，釋出效率非常低。後來，就進入了微服務時代，微服務主要用的框架是基於 Java 語言。微服務架構的一個優勢在於迭代效率非常高，擴充套件性也比較好，但是微服務對資源的佔用和成本相對較高。隨著技術的演進，容器化加速了微服務的落地。但並不是所有的企業都適合微服務，隨著系統複雜性的提升，微服務的效率，運維成本也在增加。企業選用單體架構，還是微服務取決於系統的複雜程度。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eccfa13209e342d8b5dcad523ba5ba6e~tplv-k3u1fbpfcp-watermark.image?)

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

![2.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/722ec2a6220f4366a71c9e01ce4e0a22~tplv-k3u1fbpfcp-watermark.image?)

如果應用能夠按照雲上原生的產品或服務進行重構開發，就能夠最深的享受雲端計算的便利性。但與此同時它有幾個問題：

- 投入成本（遷移/改造）；
- 雲廠商繫結程度；
- 雲的易用性（上手門檻/維護）；
- 安全性。

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

![3.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/43a6f51f7c274041abdaddbc8fef9e3a~tplv-k3u1fbpfcp-watermark.image?)

## Serverless 應用引擎的核心技術

SAE 由哪些元件構成？是怎樣把各種產品能力結合到一起的？可以看下這個元件架構。圖中綠色部分，是使用者需要關注的，是各種各樣的業務應用。同時，SAE 會提供各種工具，比如 Cloudtoolkit 外掛輔助原生程式碼部署到雲端，比如對接雲效提供流水線能力。圖中橘黃色部分，就是 SAE 平臺，會提供很多種能力。比如說寫了一個商城應用，前臺就是一個獨立的服務模組，可以單獨迭代、開發或者管理。還可以給前臺服務配置彈性策略，例如在大促期間，前臺服務可以根據實際流量自動彈性伸縮，這個也是 SAE 的一個核心價值。所以 SAE，既可以提供資源管理能力，又能提供應用生命週期管理、微服務治理，是一個全託管式的應用平臺。在資源層面，SAE 封裝了K8s 叢集，K8s 之下是基礎設施，由神龍伺服器和安全容器構建，SAE 在資源層面，會幫助使用者提供資源管理和排程能力。

![4.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f2213ae413394f9b9701a48d152676dd~tplv-k3u1fbpfcp-watermark.image?)

接下來講一下 SAE 的核心能力。首先，我們先看一下傳統企業使用者部署應用的整個流程，首先是需要購買 ECS 資源，然後搭一個叢集，對叢集進行初始化，然後構建環境。研發開發完成後，開始進行測試部署，另外還要去部署監控、日誌等元件。等業務全部上線後，就進入維護狀態，包括資源的運維和業務的運維。而使用 SAE 可以省掉很多步驟，首先底層的 K8s 叢集由雲廠商來維護，使用者只用提交映象或者 JAR 包，就可以把系統部署到 SAE 平臺。其次，監控和日誌系統，這些已經由平臺提供，使用者只需要關注業務邏輯，不需要去維護資源。

![5.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/906f1e05b83d45b5b31a242852752842~tplv-k3u1fbpfcp-watermark.image?)

如果使用者想要做灰度釋出該怎麼辦？SAE 也給使用者提供了單批、分批、金絲雀等釋出策略。讓部署到平臺上的業務能夠做到不停機更新，這個能力也是預設就提供的。

![6.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/93c5553de3fc4a7c93ed1dd242370082~tplv-k3u1fbpfcp-watermark.image?)

關於使用者訴求非常強烈的金絲雀釋出，SAE 可以以做到按請求內容灰度 ，和按流量比例灰度。比如要做流量比例灰度，分批發布直接 50%，兩批即可發完。同時，也可以按照精準的流量比例進行灰度。

使用者使用這個平臺也會非常關注彈效能力，而 SAE 提供了非常豐富的彈性配置。可以基於基礎監控指標（CPU、Mem）和業務監控指標（QPS 、RT）來觸發水平伸縮 。按照這種負載模型去做彈性擴縮容，一般比較適用於突發流量、或者有典型脈衝的應用場景。比如網際網路遊戲，社交平臺。第二種是定時彈性，這種模型比較適合像餐飲，出行這種有波峰波谷的應用場景。

![7.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/10f41908744b469d865f1bfe9487a701~tplv-k3u1fbpfcp-watermark.image?)

那麼彈性效率能不能跟得上彈性訴求呢？正常情況下，當我們把一個映象部署到平臺，系統要經過一個資源排程，然後建立 POD，拉使用者映象，建立容器，啟動容器等幾個步驟。為了提升這個效率，SAE 首先針對應用做了原地升級能力。就是針對應用升級釋出，可以直接在原有資源上，直接拉使用者最新的映象進行更新和部署，避免重建 POD，從而幫使用者提升了 42% 的部署效率。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c21517fc19a44eea8cbabc142d0abe68~tplv-k3u1fbpfcp-watermark.image?)

其次，SAE 還做了映象加速能力，能幫使用者提升 30% 的彈性效率。也就是在使用者在建立容器的時候，會同步按需去拉取使用者映象，可以降低服務啟動時間。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7e840463ceb34b579df57686c39f8b96~tplv-k3u1fbpfcp-watermark.image?)

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

![10.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7ed5d693916d40daa31bf3123594d6ac~tplv-k3u1fbpfcp-watermark.image?)

最後，SAE 會給使用者提供這種監控和應用診斷能力，可以查詢服務的呼叫鏈、介面的響應耗時、GC 次數、慢 SQL 等，幫使用者快速定位問題。

![11.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9d81c19a92694bb897f87169ba244818~tplv-k3u1fbpfcp-watermark.image?)

## Serverless 應用引擎的最佳實踐

微服務/應用遷移到 SAE，大概有幾個步驟。首先如果是單體，可以直接打一個壓縮包，部署到平臺上來，但是單體應用需要做存算分離，也就是資料庫和計算程式碼分離開，把計算部分部署到 SAE。微服務應用可以選擇寫一個 docker file，做成映象，然後推到映象倉庫，即可完成部署。微服務應用也可以選擇打成 JAR/WAR 包直接部署到 SAE。

![12.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c4bea60c09dd46fe9104b22c7ed9adc8~tplv-k3u1fbpfcp-watermark.image?)

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

![13.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6bce5832117a45d48eb17e744b47e95c~tplv-k3u1fbpfcp-watermark.image?)

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

![14.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c6f25f7a3c69439a9e4c9a19a4e0a229~tplv-k3u1fbpfcp-watermark.image?)

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

![15.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fbe890baceb84e4097f328ca24388b25~tplv-k3u1fbpfcp-watermark.image?)

還有的使用者會關注 SAE 和 ECS 比，做了哪些能力增強呢？首先是提供的這種免運維全託管能力，其次是一站式的全應用生命週期管理能力，以及針對微服務的治理和最佳化、應用監控等，都是 SAE 給使用者提供的增值體驗。

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/47e1d5b814f84262bb1122f1ccb83033~tplv-k3u1fbpfcp-watermark.image?)

## Serverless 應用引擎的客戶案例

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

![17.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/78cda73abb944733805803fff0f989ac~tplv-k3u1fbpfcp-watermark.image?)

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

![18.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bba80207deb447feb73e7ae7f7bf842a~tplv-k3u1fbpfcp-watermark.image?)

相信隨著雲端計算的發展，Serverless 將成為雲時代預設的計算正規化，越來越多的企業客戶將會採用這個技術。

![19.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1d0a5dbd14114c9881eebf2df09f01ec~tplv-k3u1fbpfcp-watermark.image?)

[戳此處，前往檢視影片解析~](https://developer.aliyun.com/live/247346)

阿里雲 Serverless 助力企業全面擁抱雲原生

相關文章