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

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

1、自然雲原生的 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% 的降本提效。

2、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 門檻地享受到這款產品背後帶來的技術紅利。

3、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 方案更加成熟。

4、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 等，在有容量模型的狀況下設置行業策略，達到很是貼合實際使用量的效果，實現低成本及架構的最大化升級。

5、總結

數字化轉型已經滲透到各行各業，無論是由於時間發展緣由仍是疫情緣由，在數字化轉型裏，企業要有應用好雲的能力，來應對業務上的快速變化及高洪峯高流量場景下的挑戰，這一過程包含幾個階段：Rehost（新託管）、Re-platform（新平臺）、Refactor（新架構），隨着架構改造的深刻，企業可以得到的雲的價值越高，同時遷移改形成本也會隨之上漲，若是隻是把應用簡單託管到雲上，很難得到雲的彈性能力，遇到問題時仍是很難及時處理。

經過 SAE，咱們但願可以讓用戶 0 改造、0 門檻、0 容器基礎便可享受到 Serverless + K8s + 微服務的價值紅利，最終幫助用戶更好面對業務上的挑戰。

做者： 陳濤（畢衫）
原文連接本文爲阿里雲原創內容，未經容許不得轉載