作者 | 陳濤（畢衫）
來源|阿里巴巴云原生公眾號

一、天然云原生的 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 + 微服務的價值紅利，最終幫助用戶更好面對業務上的挑戰。

本文整理自【Serverless Live 系列直播】1 月 29 日場
直播回看鏈接：https://developer.aliyun.com/topic/serverless/practices

Serverless 電子書下載

本書亮點：

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

下載鏈接：https://developer.aliyun.com/topic/download?id=1128

總結

以上是生活随笔為你收集整理的如何 0 改造，让单体/微服务应用成为 Serverless Application的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。