![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/87566b9fa9984d978c00442e3075c139.png)

作者 | 陳濤（畢衫）
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/AVrv77vkrO3rgn6fef_UAw)

# 一、天然雲原生的 Serverless

## 1. 雲原生時代

隨著 2013 年以 Docker 為代表的容器技術、CNCF 基金會以及 K8s 的發展等，雲原生開始被廣大開發者所熟知。雲原生時代之前還有兩個階段：一是自建 IDC 機房，二是簡單地把原有的應用搬遷到雲上。自建 IDC 機房很難獲得高可用、高可擴充套件以及運維提效等能力；而第二個階段就是雲端計算時代，相比 IDC 有了一定的進步，但大部分還是在相對原始地用雲，很難用好雲，這個階段的資源已經接近無限，但是基於虛擬機器及各種自建服務的方式還有待改善。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/3515945037034a9cb2a6d3673cbcf0cb.jpg)

雲原生時代指的是在設計應用的時候，就考慮到將來應用會執行在雲的環境裡，充分利用了雲資源的優點，比如雲服務的彈性、分散式的優勢。如上圖所示，雲原生可以分為幾部分：

一是**雲原生技術**，包括容器、K8s、微服務、DevOps。而這些技術只是一個工具，要想真正地用好這些技術，還需要一些最佳的實踐和組合，也就是雲原生架構。

**雲原生架構**是基於雲原生技術的一種架構原則和設計模式的集合，是一些指導原則，比如要求做好可觀測，只有在做好可觀測的前提下才能做好後續的彈性，包括高可用相關的建設及基礎設施的下沉，希望對非業務程式碼的部分進行最大化的剝離，在這樣的技術和架構設計的指導下，就可以設計出雲原生應用。

**雲原生應用**具有輕量、敏捷、高度自動化等方面的特點，可以充分發揮雲的優勢，在現代數字化轉型的時代，更好地適應業務的發展變化。

## 2. Serverless 天然雲原生

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/9aa9f7f65abe484d94e5fe4a0086d420.jpg)

為什麼說 Serverless 是天然雲原生的呢？雖然 Serverless 出現的時間比雲原生更早一些，我們向前追溯，AWS 率先推出初代 Serverless 產品——Lambda，其按請求計費和極致伸縮的特點，非常符合雲原生的定義，比如基礎設施下沉。在 Lambda 裡，不需要管理伺服器，它會根據請求去伸縮伺服器，實現了高度自動化；它還以函式的形式來組織程式碼，函式相對於應用來說要更輕量，交付速度也更快。但是這種模式的缺點就是改造成本高，因為很多應用原來是一個巨大的單體或者微服務應用，很難改造成函式模式。

## 3. 認識 SAE

Serverless 理念及相關產品的推出已經走過差不多 7 個年頭，在這個過程中雲原生的技術也在不斷成熟，包括Docker、 K8s 等。阿里雲在 2018 年的時候就開始思考另一種 Serverless 形態，即 Serverless application，也就是 SAE 這款產品，其於 18 年 9 月上線，19 年商業化，至今也走過了 3 個年頭。

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/ac0197af4d274e4690646abd85e54b9c.jpg)

**SAE 的特點：**

- 不可變基礎設施、可觀測、自動恢復

基於 K8s 底座，背後代表的是映象之類的不可變基礎設施以及可觀測、自動恢復，如果檢測到請求失敗，會自動切流或重啟例項。

- 免運維、極致彈性、極致成本

託管伺服器資源，不需要使用者自己運維伺服器，同時也相應地具備極致彈性和極致成本的能力。

- 易上手、0 改造、一體化

如上圖，最上層為客戶感知層，是 aPaaS 產品形態，是一個應用 PaaS，經過三年多的實踐，最終達到讓使用者真正易上手、0 改造的效果，而且做了很多一體化的整合。

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/051bbfb7a4cd4614b7de3160f17b5f6c.jpg)

SAE 這樣一款以 K8s 為底座、具備 Serverless 的特點、以 aPaaS 為形態的產品，完全符合雲原生的特點。在技術層面，底層使用容器、K8s，整合了微服務，包括各種 DevOps 工具。在架構層面，因為底層依賴於這些技術，所以可以非常方便地讓使用者遵照雲原生架構的原則，去設計出自己的應用實踐，最終讓客戶的應用可以最大化地享受到雲原生的紅利，實現應用的輕量、敏捷以及高度自動化，極大地降低邁入雲原生時代的門檻。

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/0c0eb7f0fbd34208ae84922011a9f8bb.jpg)

SAE 產品架構圖

SAE 是一款面向應用的 Serverless PaaS，**0 改造 0 門檻 0 容器基礎**是它的特點，可以讓使用者非常方便地享受到 Serverless、 K8s 以及微服務帶來的技術紅利。同時也支援多種微服務框架、多種部署渠道（包括自己產品的 UI 部署 / 雲效 / Jenkins / 外掛部署等）、多種部署方式（包括 War / Jar / 映象部署等）。

其底層是一個 IaaS 資源層，上面是 K8s 叢集，對使用者來說這些都是透明的，不需要自己購置伺服器，也不需要理解 K8s，再上一層有兩個核心能力：一是應用託管，二是微服務治理，應用託管就是應用生命週期等，微服務治理就是服務發現、優雅下線等，這些在 SAE 裡都做了較好的整合。

**SAE 的核心特點可以總結為三個：一個是 0 程式碼改造，二是 15s 彈性效率，三是 57% 的降本提效。**

# 二、SAE 設計理念

## 1. Kubernetes 底座

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/32f52edc84204ed7b13513f869309762.jpg)

- 容器

在 K8s 容器編排生態中，最基礎的是容器或映象，依託於映象，使用者就相當於實現了不可變的基礎設施，其好處是映象可以到處分發、複製，相當於實現了可移植性，沒有了廠商繫結。另外針對不太熟悉映象或者不想感受複雜性的使用者，我們也提供了 War / Jar 層面的部署，極大降低使用者享受紅利的門檻。

- 面向終態

在傳統的運維領域有很多問題比較難解決，比如伺服器因為各種各樣的原因，突然負載高或者 CPU 高等，這時在傳統領域通常需要大量的手動運維操作，而在 K8s 領域結合可觀測、健康檢查，只需配置好 liveness 和 readiness，就可以實現自動化的運維，K8s 會自動進行切流以及自動化地重新排程，極大地降低了運維成本。

- 資源託管

不僅 ECS 機是託管的，K8s 也是內部託管運維的，客戶完全不需要購買伺服器或者購買 K8s 或者運維 K8s，甚至都不需要懂 K8s，極大地降低了客戶的入門門檻和薪資負擔。

## 2. Serverless 特性

![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/dfed8e653a2744d6a94862c8236a66df.jpg)

- 極致彈性

我們已經實現了端到端的 15 秒，也就是 15 秒內可以建立出一個 pod，讓使用者的應用開始啟動。在彈效能力上，我們具有基礎指標彈性（如 CPU、Memory 等）、業務指標條件彈性（如 QPS、RT 等）和定時彈性。如果手動設定彈性指標，仍有一些門檻和負擔，因為客戶不知道指標應該設成多少，在這個背景下，我們也在考慮智慧彈性，自動幫使用者算出彈性指標推薦給使用者，進一步降低門檻。

- 精益成本

SAE 免去了資源託管和運維成本，在此之前客戶需要運維大量的 ECS 伺服器，當需要安全升級、漏洞修復，特別是高密部署時，成本會很高。另外 SAE 計費模式是以分鐘計費，使用者完全可以實現精益成本，比如在業務高峰的 1 小時擴容到 10 個例項，在高峰結束後變成 2 個例項。

- 語言增強

在彈性領域，我們針對性地做了一些語言增強。比如 Java，結合阿里的大規模 Java 應用實踐，阿里的 JDK——Dragonwell11 相比於其它開源的 JDK，可以讓 Java 應用的啟動速度提高 40%。未來我們還會在其它語言上探索更多的可能性。

## 3. (application)PaaS 產品形態

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/75e40522aed0477a8a8332891344c5a6.jpg)

- 應用託管

應用託管，相當於應用生命週期的管理，包括應用釋出、重啟、擴容、灰度釋出等，其使用的心智和大家在使用應用或其他 PaaS 平臺是一樣的，上手門檻非常低。

- 一體化整合

因為雲產品有幾百多款，如果要每一款都用好也是額外成本。所以我們對最常用的雲服務進行了一體化整合，包括基礎監控、業務監控 ARMS、NAS 儲存、SLS 的日誌收集等各方面，降低使用者使用產品的門檻。

另外我們還額外地做了微服務增強，包括託管註冊中心、優雅上下線和微服務治理等。因為使用微服務通常需要一個註冊中心，SAE 內建託管註冊中心，使用者不需要再重新購置，完全可以把應用直接註冊上來，進一步降低使用者門檻和成本。

SAE 將這些能力組合起來，最終讓使用者在遷移傳統單體應用或者微服務應用時，基本可以實現 0 改造遷移，0 門檻地享受到這款產品背後帶來的技術紅利。

# 三、SAE 技術架構

## 1. SAE 技術架構圖

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/aedd2f9e708f458b91fc4ebdf637cfd7.jpg)

SAE 幫使用者託管 K8s 背後的技術架構如上圖所示，在 1 個宿主機上，最上層是 SAE 的 PaaS 介面，第二層是 K8s 的 Master（包括 API server 等），最下面一層是 K8s 真正執行資源的宿主機，這些都是完全由 SAE 託管的，使用者只需要在自己的 VPC 或網路段內建立 Pod 資源並做一個連通，即可實現應用的正常執行。

這裡有兩個核心問題：

**一是防穿透**，比如我們的 Pod 或容器使用的是像 Docker 這樣的傳統容器技術，把公有云的 a 和 b 兩個使用者跑到一個物理機上，其實有非常高的安全風險，b 使用者很有可能會侵入到 a 使用者的容器裡獲取使用者資訊，所以這裡面的核心就是要限制使用者能力，防止其逃逸。

**二是網路的連通或者雲體系的打通**，我們要跟使用者的網路體系打通，這樣使用者才可以方便地和他的安全組、安全的規則、RDS 等連通，這也是一個核心的問題。

## 2. 安全容器

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/1b147b3eb2ac4d52952b23b75092aa64.jpg)

在這裡具體展開一下防逃逸問題。上圖表格是現在大家討論的比較廣泛的安全容器技術，安全容器簡單理解就是虛擬機器思想。如果使用傳統的像 Docker 這樣的容器化技術，很難做好安全的防護或隔離，而安全容器可以理解為一個輕量級的虛擬機器，既有容器的啟動速度，又有虛擬機器的安全。

目前安全容器已經超脫出了安全，不僅僅有安全的隔離，也有效能的隔離以及故障的隔離，以故障隔離為例，如果採用 Docker 這種容器技術，遇到一些核心問題，就有可能因為一個 Docker 容器的失敗而影響到其他使用者，整個宿主機都可能會受到影響，而如果採用安全容器技術就不會有這樣的問題。

SAE 採用了 Kata 安全容器技術，從時間和開源界的事實來說，Kata 是 runV 和 Clear Container 兩個專案的結合，相比於 Firecracker 以及 gVisor 方案更加成熟。

# 四、SAE 最佳實踐

## 最佳實踐 1：低門檻微服務架構轉型

![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/31e0a1adfd4248e0b32b153534b29f8e.jpg)

熟悉微服務的客戶都知道，如果要自己運維一套微服務技術架構，需要考慮很多因素，不僅是開源、框架層面，還有資源層面及後續的問題排查，包括註冊中心、鏈路追蹤、監控、服務治理等等，如上圖左側所示，在傳統開發模式下，這些能力都需要使用者自己託管和運維。

而在 SAE 中，使用者就可以把一些與業務無關的特性1交給 SAE，使用者只需要關注自己的業務，包括微服務的使用者中心、群組中心等，以及和 SAE 的 CI/CD 工具做一個整合，就可以快速實現微服務架構。

## 最佳實踐 2：一鍵啟停開發測試環境降本增效

![12.jpg](https://ucc.alicdn.com/pic/developer-ecology/e7a09969ff0d4587b03a5769a4fac72f.jpg)

有些中大型企業會有多套的測試環境，這些測試環境一般晚上都不使用，在 ECS 模式下，是需要長期保有這些應用例項的，閒置浪費的成本比較高。

而如果在 SAE 裡就可以結合名稱空間，比如一鍵啟停或定時啟停的能力，可以將測試環境的應用全部建在測試環境的名稱空間下，再配置早上如 8:00 啟動測試環境名稱空間所有例項，在晚上 8:00 全部停止，停止後的時間段就完全不計費，可以讓使用者最大化地降低成本。

根據計算，在比較極致的情況下，基本上可以節省使用者 2/3 的硬體成本，而且也不需要額外付出其他運維成本，只需配置好定時啟停的規則即可。

## 最佳實踐 3：精準容量+極致彈性的解決方案

![13.jpg](https://ucc.alicdn.com/pic/developer-ecology/8f7c8dca9a36471e80faa3c73455f615.jpg)

在今年疫情情況下，大量學生在家進行線上教育，很多線上教育行業的客戶面臨業務流量暴漲七八倍的情況，如果基於原來自己運維的 ECS 架構，使用者就需要在非常短的時間內做架構升級，不僅是運維架構升級，還有應用架構升級，這對使用者的成本及精力都是非常大的挑戰。

而如果依託於 SAE 中各種各樣的一體化整合以及底層 K8s 這樣高度自動化的平臺，就可以簡單很多。比如可以結合 PTS 壓縮工具評估容量水位；比如壓測有問題，可以結合基礎監控和應用監控，包括呼叫鏈、診斷報告等，可以分析瓶頸在哪裡，有沒有可能盡短的時間內解決；如果發現是比較難解決的瓶頸，可以使用應用高可用服務，實現限流降級，確保業務不會因為突發洪峰而垮掉。

最後 SAE 可以根據壓測模型配置相應的彈性策略，比如根據 CPU memory、RT 或者 QPS 等，在有容量模型的情況下設定行業策略，達到非常貼合實際使用量的效果，實現低成本及架構的最大化升級。

# 五、總結

![14.jpg](https://ucc.alicdn.com/pic/developer-ecology/714365eb847541349c0db28b14d5b093.jpg)

數字化轉型已經滲透到各行各業，不管是因為時間發展原因還是疫情原因，在數字化轉型裡，企業要有應用好雲的能力，來應對業務上的快速變化及高洪峰高流量場景下的挑戰，這一過程包含幾個階段：Rehost（新託管）、Re-platform（新平臺）、Refactor（新架構），隨著架構改造的深入，企業能夠獲得的雲的價值越高，同時遷移改造成本也會隨之上漲，如果只是把應用簡單託管到雲上，很難獲得雲的彈效能力，遇到問題時還是很難及時處理。

透過 SAE，我們希望能夠讓使用者 0 改造、0 門檻、0 容器基礎即可享受到 Serverless + K8s + 微服務的價值紅利，最終幫助使用者更好面對業務上的挑戰。

> 本文整理自【Serverless Live 系列直播】1 月 29 日場
> 直播回看連結：[https://developer.aliyun.com/topic/serverless/practices](https://developer.aliyun.com/topic/serverless/practices)

### Serverless 電子書下載

**本書亮點**：

- 從架構演進開始，介紹 Serverless 架構及技術選型構建 Serverless 思維；
- 瞭解業界流行的 Serverless 架構執行原理；
- 掌握 10 大 Serverless 真實落地案例，活學活用。

**下載連結**：[https://developer.aliyun.com/topic/download?id=1128](https://developer.aliyun.com/topic/download?id=1128)

如何 0 改造，讓單體/微服務應用成為 Serverless Application

相關文章