一、天然雲原生的 Serverless
1. 雲原生時代
隨着 2013 年以 Docker 爲代表的容器技術、CNCF 基金會以及 K8s 的發展等，雲原生開始被廣大開發者所熟知。雲原生時代之前還有兩個階段：一是自建 IDC 機房，二是簡單地把原有的應用搬遷到雲上。自建 IDC 機房很難獲得高可用、高可擴展以及運維提效等能力；而第二個階段就是雲計算時代，相比 IDC 有了一定的進步，但大部分還是在相對原始地用雲，很難用好雲，這個階段的資源已經接近無限，但是基於虛擬機及各種自建服務的方式還有待改善。
雲原生時代指的是在設計應用的時候，就考慮到將來應用會運行在雲的環境裏，充分利用了雲資源的優點，比如雲服務的彈性、分佈式的優勢。如上圖所示，雲原生可以分爲幾部分：
一是雲原生技術，包括容器、K8s、微服務、DevOps。而這些技術只是一個工具，要想真正地用好這些技術，還需要一些最佳的實踐和組合，也就是雲原生架構。
雲原生架構是基於雲原生技術的一種架構原則和設計模式的集合，是一些指導原則，比如要求做好可觀測，只有在做好可觀測的前提下才能做好後續的彈性，包括高可用相關的建設及基礎設施的下沉，希望對非業務代碼的部分進行最大化的剝離，在這樣的技術和架構設計的指導下，就可以設計出雲原生應用。
雲原生應用具有輕量、敏捷、高度自動化等方面的特點，可以充分發揮雲的優勢，在現代數字化轉型的時代，更好地適應業務的發展變化。
2. Serverless 天然雲原生
爲什麼說 Serverless 是天然雲原生的呢？雖然 Serverless 出現的時間比雲原生更早一些，我們向前追溯，AWS 率先推出初代 Serverless 產品——Lambda，其按請求計費和極致伸縮的特點，非常符合雲原生的定義，比如基礎設施下沉。在 Lambda 裏，不需要管理服務器，它會根據請求去伸縮服務器，實現了高度自動化；它還以函數的形式來組織代碼，函數相對於應用來說要更輕量，交付速度也更快。但是這種模式的缺點就是改造成本高，因爲很多應用原來是一個巨大的單體或者微服務應用，很難改造成函數模式。
3. 認識 SAE
Serverless 理念及相關產品的推出已經走過差不多 7 個年頭，在這個過程中雲原生的技術也在不斷成熟，包括Docker、 K8s 等。阿里雲在 2018 年的時候就開始思考另一種 Serverless 形態，即 Serverless application，也就是 SAE 這款產品，其於 18 年 9 月上線，19 年商業化，至今也走過了 3 個年頭。
SAE 的特點：
- 不可變基礎設施、可觀測、自動恢復
基於 K8s 底座，背後代表的是鏡像之類的不可變基礎設施以及可觀測、自動恢復，如果檢測到請求失敗，會自動切流或重啓實例。
- 免運維、極致彈性、極致成本
託管服務器資源，不需要用戶自己運維服務器，同時也相應地具備極致彈性和極致成本的能力。
- 易上手、0 改造、一體化
如上圖，最上層爲客戶感知層，是 aPaaS 產品形態，是一個應用 PaaS，經過三年多的實踐，最終達到讓用戶真正易上手、0 改造的效果，而且做了很多一體化的集成。
SAE 這樣一款以 K8s 爲底座、具備 Serverless 的特點、以 aPaaS 爲形態的產品，完全符合雲原生的特點。在技術層面，底層使用容器、K8s，集成了微服務，包括各種 DevOps 工具。在架構層面，因爲底層依賴於這些技術，所以可以非常方便地讓用戶遵照雲原生架構的原則，去設計出自己的應用實踐，最終讓客戶的應用可以最大化地享受到雲原生的紅利，實現應用的輕量、敏捷以及高度自動化，極大地降低邁入雲原生時代的門檻。
SAE 產品架構圖
SAE 是一款面向應用的 Serverless PaaS，0 改造 0 門檻 0 容器基礎是它的特點，可以讓用戶非常方便地享受到 Serverless、 K8s 以及微服務帶來的技術紅利。同時也支持多種微服務框架、多種部署渠道（包括自己產品的 UI 部署 / 雲效 / Jenkins / 插件部署等）、多種部署方式（包括 War / Jar / 鏡像部署等）。
其底層是一個 IaaS 資源層，上面是 K8s 集羣，對用戶來說這些都是透明的，不需要自己購置服務器，也不需要理解 K8s，再上一層有兩個核心能力：一是應用託管，二是微服務治理，應用託管就是應用生命週期等，微服務治理就是服務發現、優雅下線等，這些在 SAE 裏都做了較好的集成。
SAE 的核心特點可以總結爲三個：一個是 0 代碼改造，二是 15s 彈性效率，三是 57% 的降本提效。
二、SAE 設計理念
1. Kubernetes 底座
- 容器
在 K8s 容器編排生態中，最基礎的是容器或鏡像，依託於鏡像，用戶就相當於實現了不可變的基礎設施，其好處是鏡像可以到處分發、複製，相當於實現了可移植性，沒有了廠商綁定。另外針對不太熟悉鏡像或者不想感受複雜性的用戶，我們也提供了 War / Jar 層面的部署，極大降低用戶享受紅利的門檻。
- 面向終態
在傳統的運維領域有很多問題比較難解決，比如服務器因爲各種各樣的原因，突然負載高或者 CPU 高等，這時在傳統領域通常需要大量的手動運維操作，而在 K8s 領域結合可觀測、健康檢查，只需配置好 liveness 和 readiness，就可以實現自動化的運維，K8s 會自動進行切流以及自動化地重新調度，極大地降低了運維成本。
- 資源託管
不僅 ECS 機是託管的，K8s 也是內部託管運維的，客戶完全不需要購買服務器或者購買 K8s 或者運維 K8s，甚至都不需要懂 K8s，極大地降低了客戶的入門門檻和薪資負擔。
2. Serverless 特性
- 極致彈性
我們已經實現了端到端的 15 秒，也就是 15 秒內可以創建出一個 pod，讓用戶的應用開始啓動。在彈性能力上，我們具有基礎指標彈性（如 CPU、Memory 等）、業務指標條件彈性（如 QPS、RT 等）和定時彈性。如果手動設置彈性指標，仍有一些門檻和負擔，因爲客戶不知道指標應該設成多少，在這個背景下，我們也在考慮智能彈性，自動幫用戶算出彈性指標推薦給用戶，進一步降低門檻。
- 精益成本
SAE 免去了資源託管和運維成本，在此之前客戶需要運維大量的 ECS 服務器，當需要安全升級、漏洞修復，特別是高密部署時，成本會很高。另外 SAE 計費模式是以分鐘計費，用戶完全可以實現精益成本，比如在業務高峯的 1 小時擴容到 10 個實例，在高峯結束後變成 2 個實例。
- 語言增強
在彈性領域，我們針對性地做了一些語言增強。比如 Java，結合阿里的大規模 Java 應用實踐，阿里的 JDK——Dragonwell11 相比於其它開源的 JDK，可以讓 Java 應用的啓動速度提高 40%。未來我們還會在其它語言上探索更多的可能性。
3. (application)PaaS 產品形態
- 應用託管
應用託管，相當於應用生命週期的管理，包括應用發佈、重啓、擴容、灰度發佈等，其使用的心智和大家在使用應用或其他 PaaS 平臺是一樣的，上手門檻非常低。
- 一體化集成
因爲雲產品有幾百多款，如果要每一款都用好也是額外成本。所以我們對最常用的雲服務進行了一體化集成，包括基礎監控、業務監控 ARMS、NAS 存儲、SLS 的日誌收集等各方面，降低用戶使用產品的門檻。
另外我們還額外地做了微服務增強，包括託管註冊中心、優雅上下線和微服務治理等。因爲使用微服務通常需要一個註冊中心，SAE 內置託管註冊中心，用戶不需要再重新購置，完全可以把應用直接註冊上來，進一步降低用戶門檻和成本。
SAE 將這些能力組合起來，最終讓用戶在遷移傳統單體應用或者微服務應用時，基本可以實現 0 改造遷移，0 門檻地享受到這款產品背後帶來的技術紅利。
三、SAE 技術架構
1. SAE 技術架構圖
SAE 幫用戶託管 K8s 背後的技術架構如上圖所示，在 1 個宿主機上，最上層是 SAE 的 PaaS 界面，第二層是 K8s 的 Master（包括 API server 等），最下面一層是 K8s 真正運行資源的宿主機，這些都是完全由 SAE 託管的，用戶只需要在自己的 VPC 或網絡段內創建 Pod 資源並做一個連通，即可實現應用的正常運行。
這裏有兩個核心問題：
一是防穿透，比如我們的 Pod 或容器使用的是像 Docker 這樣的傳統容器技術，把公有云的 a 和 b 兩個用戶跑到一個物理機上，其實有非常高的安全風險，b 用戶很有可能會侵入到 a 用戶的容器裏獲取用戶信息，所以這裏面的核心就是要限制用戶能力，防止其逃逸。
二是網絡的連通或者雲體系的打通，我們要跟用戶的網絡體系打通，這樣用戶纔可以方便地和他的安全組、安全的規則、RDS 等連通，這也是一個核心的問題。
2. 安全容器
在這裏具體展開一下防逃逸問題。上圖表格是現在大家討論的比較廣泛的安全容器技術，安全容器簡單理解就是虛擬機思想。如果使用傳統的像 Docker 這樣的容器化技術，很難做好安全的防護或隔離，而安全容器可以理解爲一個輕量級的虛擬機，既有容器的啓動速度，又有虛擬機的安全。
目前安全容器已經超脫出了安全，不僅僅有安全的隔離，也有性能的隔離以及故障的隔離，以故障隔離爲例，如果採用 Docker 這種容器技術，遇到一些內核問題，就有可能因爲一個 Docker 容器的失敗而影響到其他用戶，整個宿主機都可能會受到影響，而如果採用安全容器技術就不會有這樣的問題。
SAE 採用了 Kata 安全容器技術，從時間和開源界的事實來說，Kata 是 runV 和 Clear Container 兩個項目的結合，相比於 Firecracker 以及 gVisor 方案更加成熟。
四、SAE 最佳實踐
最佳實踐 1：低門檻微服務架構轉型
熟悉微服務的客戶都知道，如果要自己運維一套微服務技術架構，需要考慮很多因素，不僅是開源、框架層面，還有資源層面及後續的問題排查，包括註冊中心、鏈路追蹤、監控、服務治理等等，如上圖左側所示，在傳統開發模式下，這些能力都需要用戶自己託管和運維。
而在 SAE 中，用戶就可以把一些與業務無關的特性交給 SAE，用戶只需要關注自己的業務，包括微服務的用戶中心、羣組中心等，以及和 SAE 的 CI/CD 工具做一個集成，就可以快速實現微服務架構。
最佳實踐 2：一鍵啓停開發測試環境降本增效
有些中大型企業會有多套的測試環境，這些測試環境一般晚上都不使用，在 ECS 模式下，是需要長期保有這些應用實例的，閒置浪費的成本比較高。
而如果在 SAE 裏就可以結合命名空間，比如一鍵啓停或定時啓停的能力，可以將測試環境的應用全部建在測試環境的命名空間下，再配置早上如 8:00 啓動測試環境命名空間所有實例，在晚上 8:00 全部停止，停止後的時間段就完全不計費，可以讓用戶最大化地降低成本。
根據計算，在比較極致的情況下，基本上可以節省用戶 2/3 的硬件成本，而且也不需要額外付出其他運維成本，只需配置好定時啓停的規則即可。
最佳實踐 3：精準容量+極致彈性的解決方案
在今年疫情情況下，大量學生在家進行在線教育，很多在線教育行業的客戶面臨業務流量暴漲七八倍的情況，如果基於原來自己運維的 ECS 架構，用戶就需要在非常短的時間內做架構升級，不僅是運維架構升級，還有應用架構升級，這對用戶的成本及精力都是非常大的挑戰。
而如果依託於 SAE 中各種各樣的一體化集成以及底層 K8s 這樣高度自動化的平臺，就可以簡單很多。比如可以結合 PTS 壓縮工具評估容量水位；比如壓測有問題，可以結合基礎監控和應用監控，包括調用鏈、診斷報告等，可以分析瓶頸在哪裏，有沒有可能盡短的時間內解決；如果發現是比較難解決的瓶頸，可以使用應用高可用服務，實現限流降級，確保業務不會因爲突發洪峯而垮掉。
最後 SAE 可以根據壓測模型配置相應的彈性策略，比如根據 CPU memory、RT 或者 QPS 等，在有容量模型的情況下設置行業策略，達到非常貼合實際使用量的效果，實現低成本及架構的最大化升級。
五、總結
數字化轉型已經滲透到各行各業，不管是因爲時間發展原因還是疫情原因，在數字化轉型裏，企業要有應用好雲的能力，來應對業務上的快速變化及高洪峯高流量場景下的挑戰，這一過程包含幾個階段：Rehost（新託管）、Re-platform（新平臺）、Refactor（新架構），隨着架構改造的深入，企業能夠獲得的雲的價值越高，同時遷移改造成本也會隨之上漲，如果只是把應用簡單託管到雲上，很難獲得雲的彈性能力，遇到問題時還是很難及時處理。
通過 SAE，我們希望能夠讓用戶 0 改造、0 門檻、0 容器基礎即可享受到 Serverless + K8s + 微服務的價值紅利，最終幫助用戶更好面對業務上的挑戰。
作者 | 陳濤（畢衫）
本文爲阿里雲原創內容，未經允許不得轉載。