![頭圖.jpg](https://ucc.alicdn.com/pic/developer-ecology/994c8a4be8664d6fad422d68e41e67df.jpg)

### 前言

在大型分散式 IT 架構領域，微服務是一項必不可少的技術。從本質上來講，微服務是一種架構風格，將一個大型的系統拆分為多個擁有獨立生命週期的應用，應用之間採用輕量級的通訊機制進行通訊。這些應用都是圍繞具體業務進行構建，可以獨立部署、獨立迭代，也可能根據業務負載獨立進行水平擴充套件。

微服務思想以及相關的技術為 IT 架構的發展帶來了一系列深刻的變革：

**易於開發和維護：**一個應用只會關注一組特定的業務功能，透過服務拆分，能減少應用之間的耦合度，讓開發和維護更加簡單。

**技術棧不受限制：**在微服務架構中，可以結合專案業務及團隊的特點，合理的選擇技術棧。

**加快系統演進速度：**每一個應用都可以獨立的進行版本更新，透過灰度釋出等技術手段能確保釋出過程中整個系統穩定執行。

**突破效能瓶頸：**每個應用都能獨立的水平伸縮，使系統效能可以根據計算資源的增加而得到線性的擴充套件。

### 微服務的挑戰

世上沒有免費的午餐，微服務技術讓 IT 系統變得更敏捷、更健壯、更高效能的同時，也帶來了架構複雜度的提升。對於開發者而言，要想更好的駕馭微服務架構，需要解決持續整合、服務發現、應用通訊、配置管理、流量防護等一系列難題。幸運的是，針對這些普遍存在的難題，業界湧現了一系列優秀的開源技術元件和工具，讓開發者可以更輕鬆的構建微服務應用。像 Spring Cloud 和 Dubbo 這樣的技術框架，經過多年的發展，已經演化為微服務領域的通用標準，極大地降低了微服務的門檻，但這些技術框架依然沒有辦法解決其中兩個最大的挑戰，這兩個挑戰成為擺在開發者面前的兩座大山。

#### 挑戰一：亟需完善的生命週期管理與服務治理方案

在一個頻繁迭代的系統中，每個應用會經常性面臨新版本釋出需求，需要對應用的上線、下線、更新、回滾等流程進行集中性的管理，並配合精細粒度的灰度釋出手段，減少版本迭代對業務造成的影響。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/c7a71eacf7074ba4a0a7519e0c2c9cc2.png)

在一個簡單的微服務架構中，如果某應用處於整個鏈路的入口位置，它的前端一般會掛上負載均衡元件（上圖中的應用 A），以承接來自於終端使用者的業務請求。這類應用在進行生命週期管理的時候，複雜度會更高，為了確保應用在新版本釋出過程中的平衡穩定，會經過如下的步驟：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/999b660192cc43c1ac6d35f79ec1762c.png)

在這個流程中，還沒有涉及到對於流量精細粒度控制的高階灰度方案，但已經足夠體現出其複雜性和操作難度了。如果僅僅依賴於簡單的釋出指令碼進行管理，不但效率很低，還很容易導致顧此失彼，對系統穩定性造成巨大的風險。

#### 挑戰二：亟需完善的水平擴容與縮容方案

當某一個應用的效能出現瓶頸，需要透過增加例項數量來提升效能的時候，就需要引入新的計算資源。

新的計算資源從何而來呢？

對於線下 IDC 而言，計算資源是需要預先規劃的，擴容並不是一件簡單的事情，可能會因為各種條件的制約而導致擴容無法實現。當然這種困擾在雲端計算時代不復存在了，為一個應用擴充計算資源是信手拈來的事情，但光有計算資源是不夠的，還得在上面部署應用，並將應用容納到微服務體系中。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8f23927ed0ec4faf9dac85a271a5ebcb.png)

根據這個流程，如果需要擴容一個應用例項，保守估計也需要 20 分鐘以上，其中購買、系統初始化、應用部署都需要佔用大量的時間。假設系統流量突增，需要在 2 分鐘之內緊急擴容，這個方案就無用武之地了。

### 一劑良藥：容器化技術

為了解決這兩個難題，開發者們嘗試了各種各樣的方案，新的理念以及技術框架在過去的這五年層出不窮。在一輪輪的優勝劣汰下，以 Docker 為代表的容器技術，在 Kubernetes 生態的支撐下，在業界成為了主流，是構建雲原生（Cloud Native）應用的必備要素。容器化相關技術能夠更大程式的挖掘雲端計算的價值，在一定程度上幫助開發者解決這兩個難題。

在應用生命週期管理以及服務治理方面， Kubernetes 提供了比較完善的實現機制，透過構建 Deployment 資源，配合 proStop 和 postStart 指令碼，能比較方便的實現滾動釋出以及應用的優雅上下線。雖然在灰度釋出的過程中，依然沒有辦法直接對流量進行精細粒度控制（引入 Service Mesh 技術能增強流量控制力，不在本文討論範圍），但相比簡單的釋出指令碼，已經有了飛躍性的提升。

在應用的水平擴容與縮容方面，透過容器化技術可以極大程度的減少作業系統安裝以及系統級初始化的時間，但購買虛擬機器的操作是無法避免的，所以在系統遇到流量增突的時候，依然沒有辦法實現快速水平擴容。我們可以預留一部分計算資源，放在資源池中，當應用有擴容需求的時候，就向資源池申請資源，當業務負載下降的時候，再把多餘的計算資源歸還到資源池中。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/9e7c2683471f44ffbcc541abb36afa9d.png)

這其實並不是一個好主意，每一個計算資源都是需要成本的，資源池雖然能夠解決計算資源快速投入使用的問題，卻造成了巨大的浪費。另外，到底規劃多大的資源池，也是一件很傷腦筋的事情，池子越大，造成的浪費就越大，但池子太小，又可能滿足不了擴容的需求。

### 資源成本更深層次的分析

可能有的開發者會認為，目前的業務執行非常的穩定，在使用者流量上並不存在明顯的突增，所以擴容和縮容是一個偽需求，在將來也不會有這樣的需求。這可能是對網際網路業務的一種誤解，因為完全沒有擴容需求的情況是不存在的。

首先，只要一個系統是為人服務的，就必然存在波峰和波谷。對於一個 7*24 小時執行的系統，不可能永遠保持同樣的使用者流量，二八原則對於很多業務系統依然適用（ 80% 的使用者流量集中在 20% 的時間段）。即便是使用者流量相對平衡的系統，在凌晨也存在流量的低谷，如果能更進一步的釋放閒置計算資源，提升資源利用率，就能顯著的降低資源使用成本。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/60c524c889ef41a89e88fc816539a1b5.png)

另外，相比生產環境，開發和測試環境對於擴容和縮容的需求會更加迫切。一套微服務應用由不同的團隊進行開發，在理想的情況下，多個團隊會共享一套測試環境：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/f8952e72c59343c1847da3daf39fe324.png)

然而，每個團隊對於應用的迭代都會有自己的節奏，與此同時，他們又想擁有獨立的端到端測試環境，從而實現環境之間的隔離，以避免團隊之間的相互影響。這樣的話，很有可能會形成多套測試環境：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/0fbc0d274ab84a688c44da18875e2054.png)

隨著應用、團隊、業務功能點數量的增加，所需要的開發測試環境數量還會成倍的增長，造成巨大的資源浪費。對於測試環境的計算資源而言，資源利用率要遠低於生產環境。有的時候僅僅是一個簡單功能點的驗證，為了端對端的跑通業務功能，又避免團隊之間的相互影響，就會開啟一套包括全部微服務應用的新環境。這樣的資源浪費，對於很多企業，都是一個多年都未曾得到解決的難題。

因此，微服務架構在本質上就是對彈性伸縮有著強烈訴求的，在彈性伸縮的過程中，不管是單應用的水平彈性伸縮，還是整套環境的啟停，資源利用率都對最終的資源成本起著決定性的作用。如果能想辦法提升資源利用率，就能為企業節省大量資源成本。值得我們重視的是，絕大多數的微服務應用的資源利用率都是非常低的。

我們可以做一個簡單的統計：把所有伺服器的 CPU 利用率每 5 分鐘匯出一次，按照天的維度求平均值，就能從整體上了解系統的資源利用率資料。如果把開發測試環境的伺服器資源也納入統計的範圍，資源利用率很有可能會更低。

### Serverless 化探索

資源利用率低的根本原因，在於以伺服器為載體的應用架構中，開發者需要將構建好的程式包部署到伺服器上，從而對多個使用者事件進行響應。為了確保事件響應的及時性，需要讓程式長駐於伺服器上，而且儘可能保守的規劃資源，以避免出現負載過重而導致服務崩潰的情況。在這個過程中，實際的負載在時間上分配並不均衡，從而導致整體的資源利用率偏低。

Serverless 技術的出現，為提升資源利用率提供了新的思路。Serverless 是一種構建和管理基於微服務架構的完整流程，允許開發者脫離伺服器資源而直接部署應用。它與傳統架構的不同之處在於，完全由第三方管理，由事件觸發，存在於無狀態（Stateless）的計算容器內。構建無伺服器應用程式意味著開發者可以專注在產品程式碼上，而無須管理和操作伺服器資源，真正做到了部署應用無需涉及基礎設施的建設。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/1c02907d26f3442a87743adf43a7fc75.png)

Serverless 技術存在多種形態，最典型的一種是 FaaS（Function as a Service，函式即服務），比如阿里雲的函式計算（Function Compute，FC）產品。在函式計算領域，一切計算資源的申請和排程都由具體的業務事件觸發，當業務事件所對應的任務完成之後，計算資源會被立即釋放。這樣的方式真做到了計算資源的按需分配，能顯著提升資源利用率，是 Serverless 技術的終極形態。

另外一種是 Serverless 化的容器技術，Serverless 化的容器例項執行在案例隔離的環境中，每個計算節點透過輕量級虛擬化安全沙箱技術完全強隔離。對於使用者而言，無需購買伺服器資源即可直接部署容器應用，也無需對叢集進行節點維護和容量規劃，可以根據應用配置的 CPU 和記憶體資源量進行按需付費。當微服務應用需要擴容的時候，就可以快速獲得計算資源，不需要再經過購買伺服器這個步驟了，可以幫助開發者降低計算成本，減少閒置資源浪費，平滑應對突發流量高峰。阿里雲的 Serverless Kubernetes （ASK）就是 Serverless 化容器技術的代表產品。

### 更進一步發掘開發者的訴求

Serverless 技術無縫是雲端計算和雲原生應用架構的發展方向，但對於微服務應用的開發者而言，不管是 FaaS 形態，還是 Serverless Kubernetes ，都存在一定的侷限性。

不是每一種業務都適合透過 FaaS 的方式進行構建，特別是對於鏈路長，上下游依賴特別明顯的應用，根本沒有辦法進行 FaaS 化改造。即便某些業務系統的 FaaS 化改造被證明可行，把現有的微服務架構改造成 FaaS 架構也需要一定的工作量，並不能做到無縫移植。

Serverless Kubernetes 架構雖然能適配所有的業務場景，但對於開發者而言，構建一整套 Kubernetes 體系，需要掌握一系列跟 Kubernetes 相關複雜的概念，有著非常陡的學習曲線。而且 Kubernetes 生態中各種元件的搭建，再加上網路層與儲存層的適配，都涉及非常複雜的工作。

造成這種侷限性的原因很簡單，在以 Spring Cloud 為代表的微服務技術陣營中，系統的構建都是圍繞著應用（也可以理解為單個的服務）而展開，不管是版本更新還是水平擴充套件，都是針對應用本身。Serverless Kubernetes 架構的核心在於 Pod ，比應用更偏向系統底層，所以使用者需要投入更多的精力用於應用下層資源的管理。而 FaaS 架構的核心在於函式，比應用更偏向系統上層，因此靈活度會降低，不能適配所有的業務場景。

對於使用主流 Spring Cloud 體系或 Dubbo 體系構建微服務應用的開發者而言，如果需要引入一種方案降低資源成本，他的最終訴求一定包含兩個方面：

（1）能否零改造成本，或者接近零改造成本；
（2）能否適配所有的業務場景。

### 應用層 Serverless 技術

是否有一種介於 FaaS 和 Serverless 化容器之間的技術，可以實現上述重要訴求呢？當然有，這就是以阿里雲 Serverless 應用引擎（SAE）為代表的應用層 Serverless 技術。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/007cb84ce0394c3abc02d155d56737c5.png)
（圖：不同層級的 Serverless 技術 ）

SAE 實現了 Serverless 架構 + 微服務架構的完美融合，對於 Spring Cloud 和 Dubbo 等主流的微服務架構，可以實現無縫相容，基本上沒有改造成本，並真正按需使用、按量計費，節省閒置計算資源，同時免去 IaaS 層運維方面的工作，有效提升開發運維效率。

以 Spring Cloud 應用為例，如果需要部署一個新的應用，只需要 2 個步驟：

（1）告訴 SAE 這個應用需要多少個例項，並指定每個例項需要的 CPU / 記憶體規格。
（2）上傳應用的 JAR 包 / WAR 包，並啟動應用。

我們發現，這兩個步驟中並不涉及容量評估、伺服器購買、作業系統安裝、資源初始化等工作，就能讓包含多個對等例項的微服務應用執行起來。這是因為在 Serverless 的世界中，不再具有伺服器資源這樣的概念，應用的載體是 SAE 排程出來的沙箱容器，每個例項只有在真正投入使用後，才會按使用時長進行計費。

對於開發者而言，他們不用關心應用到底部署在物理機裡面，還是虛擬機器裡面，或是容器裡面，也不需要知道底層的作業系統是什麼版本的，只需要關注每個應用例項佔據多少運算資源就可以了。如果應用需要從 4 個例項擴容到 6 個例項，或者縮容到 2 個例項，只需要一個指令就可以完成，甚至與 SLB 的繫結關係，都可以自動的建立或解除，這是 Serverless 技術為開發者帶來的巨大價值。

使用 SAE 部署微服務應用，因為只是變更了應用執行的載體，所以可以 100% 的相容現有的技術架構和業務功能，遷移成本可以忽略不計。

### SAE 的極致彈效能力

除了手動的擴縮容指令，SAE 還支援 2 種自動彈性機制，可以對微服務應用進行靈活的水平擴充套件，更進一步的發揮雲端計算的彈效能力。

**定時彈性機制：**對於會預期發生的週期性行為，可以設定定時彈性策略。舉例：如果每天的上午 9 點是業務高峰，可以定時每天 8 點半增加例項數量，並在 9 點半減少例項數量。

**基於指標閾值的彈性機制：**對於超出預期的業務流量突增，可以設定基於指標閾值的彈性策略，根據 CPU 、記憶體等資源指標，以有 QPS 等業務指標讓應用實現自動的彈性縮。

透過多種彈性機制，能夠對系統容量進行精細粒度的管理，使資源的使用量能隨著業務流量的變化而調整，從而極大程度的增加資源利用率，大幅降低資源成本。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/2b075dd3eff24083b4f26dfb642b8f44.png)

在計算資源的排程和啟動上， SAE 做了多項最佳化，對於擴容出來的新例項，只需要幾秒鐘的時間就能拉起，這項能力對於一些需要緊急快速擴容的突發場景，是具有重大意義的。

對於開發測試環境而言，SAE 的機制彈效能力能體現得更加淋漓盡致，得益於 SAE 出色的資源排程能力，可以一鍵啟停一整套微服務應用。即便僅對一項簡單的新功能進行冒煙測試，也完全可以新啟一套完整而隔離的測試環境來進行。新的環境可以在秒級搭建完成，快速投入使用，而測試完畢後，又可以立即釋放。從成本上來講，一套新環境實際投入使用的時間很短，因此只會消耗極少的費用。這對於微服務應用開發過程中的多團隊協作，是一個巨大的變革。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/faa3de2a6c224602a1ab9ff4d5c9ff68.png)

### 成本分析

SAE 透過資源的實際使用量來付費，費用由兩部分組成，每部分根據統計結果和計算方式進行費用結算，按小時出賬單扣款。每個應用使用的資源計量方式如下所示：

**應用 CPU 資源使用量**=∑例項 CPU 規格×本月執行時長（以分鐘計），即應用中所有例項的 CPU 規格乘以本月執行時長的總和。

**應用記憶體資源使用量**=∑例項記憶體規格×本月執行時長（以分鐘計），即應用中所有例項的記憶體規格乘以本月執行時長的總和。

其中 CPU 部分的價格為 0.0021605 元/分鐘/Core，記憶體部分的價格為 0.0005401 元/分鐘/GiB。SAE 還提供預付費資源包，相當於批發的方式預購計算資源，只要能要有效期內消耗完，就能更進一步的節省使用成本，當資源包扣完以後，系統會自動變更為按量付費的模式。

讓我們透過一個實際案例來進一步體會 SAE 如何幫助微服務應用降低資源成本。假設一個微服務系統包含 87 個應用例項，每個時間每天的平均執行時長為 8 小時，例項的配置為 2 Core + 4 GiB + 20 G 磁碟。

- 使用包年包月的 ECS 部署應用：需要購買 87 臺計算型 c5 ，單臺的月成本為 186 元，每月總成本 16146 元。
- 使用按量付費的 ECS 部署應用：單臺價格為 0.63 元/小時，每月累計使用 20880 小時，總成本 13154 元。
- 使用 SAE 部署應用：購買 1 個 75000 元的包年資源包，87 個例項每天執行 8 個小時，剛好把資源包額度用完，摺合每月總成本 6250 元。

從這個對比我們可以得出，只要能夠合理的執行 SAE 的彈效能力，就可以為微服務應用大幅度降低資源成本。

### 附加能力

SAE 除了可以簡化運維工作量，降低資源成本以外，還為微服務應用提升了一系列附加的功能，這是應用層 Serverless 技術為開發者帶來的額外價值，我們可以儘可能的利用這些開箱即用的功能，讓建設微服務應用變成更加簡單。

**完整的應用生命週期管理：**應用託管至 SAE 後，可以對應用執行更新、擴縮容、啟停、刪除、監控啟停等應用生命週期管理操作。

**開箱即用的註冊中心：**SAE 自帶商業版 Nacos 註冊中心，可以免費使用，不需要自行搭建。如果有特殊的需求，比如讓部署在 SAE 的應用和其他應用相互發現，也可以使用微服務引擎（MSE）產品提供的註冊中心，或者自建的註冊中心。

**開箱即用的配置管理中心：**SAE 整合了 ACM（Application Configuration Management，應用配置管理）中的配置管理功能，可以在 SAE 中使用 ACM 對應用配置進行集中管理。

**應用級流量防護：** SAE 整合 AHAS 實現應用級別的流控與降級能力，全面保障應用的高可用性。

**監控能力：**應用託管到 SAE 以後，可以免費獲得基礎資源（包括 CPU、記憶體、負載和網路）以及應用層（包括 JVM 分析、介面呼叫分析等方面）的監控能力。如果需要更高階的 SQL 分析、異常分析、鏈路上下游和介面快照，可以整合阿里雲應用時間監控產品（ARMS）。

**CI/CD 整合能力：**SAE 與雲效、雲效 2020、 Jenkins 等產品進行了深入整合，可以方便開發者將構建好的應用快速部署。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/9f79336b1fbb42c2b06b1ee8d6efbd43.png)

### 多語言支援

對於非 Java 語言編寫的應用，或者沒有使用 Spring Cloud 等微服務框架的 Java 應用， SAE 能不能完美支援，並幫助企業降低資源成本呢？

當然是可以的。SAE 提供容器映象部署方式，這就代表著不管採用哪種程式語言，只要最終的應用能夠釋出成容器映象，就可以部署在 SAE 上。

對於 Java 系的微服務應用， Java 系統的普通應用，以及非 Java 系應用而言，SAE 的極致彈效能力並沒有本質的區別，都能透過 Serverless 技術提供系統的資源利用率。只不過 SAE 提供的一些附加價值，比如免費的微服務註冊中心，就只能為 Spring Cloud 或 Dubbo 應用服務罷了。

### 總結

讓我們用這張圖回顧 Serverless 技術的巨大價值：

![13.png](https://ucc.alicdn.com/pic/developer-ecology/faf424788d164b079242a42487a81fd4.png)

**常見問題**：

1.問：應用例項沒有固定的機器資源，連固定的 IP 地址都沒有，如何 SSH 到一臺伺服器排查問題？

答：並不需要有固定的機器資源和固定的IP地址才能排查問題，在雲端計算時代，透過 SSH 登入到一臺機器排查問題的方式並不是一個好的實踐。相反， SAE 提供了完善的監控能力，還可以方便的與雲監控、 ARMS 等新一代監控診斷類產品進行了整合，為排查故障提供了更大的便利。當然，如果一定要登入到某一臺機器，SSH 依然是可以支援的，也可以利用 SAE 提供的 Webshell 工具簡化這個流程。

2.問：磁碟不是計費的維度嗎？應用需要大容量磁碟怎麼辦？應用重啟後碰盤中的資料還保留嗎？

答：在微服務領域，應用一般是無狀態（Stateless）的，不需要儲存大量的本地資料。如果在特殊的場景下離不開這個需求，可以整合 NAS ，使用集中式的儲存實現。

3.問：應用的日誌怎麼檢視？

答：SAE 控制檯介面提供了對於檔案日誌的實時查閱能力，相當於免費提供了一個分散式日誌採集平臺。當然強烈建議接入阿里雲日誌服務（SLS）產品，更進一步的發揮應用日誌的價值。

### 課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲端計算的新正規化——Serverless。點選連結即可免費學習課程：[https://developer.aliyun.com/learning/roadmap/serverless](https://developer.aliyun.com/learning/roadmap/serverless)

> [Serverless 公眾號](https://mp.weixin.qq.com/s/bo5t4wiiv3Q82oJAGUKRfA)，釋出 Serverless 技術最新資訊，彙集 Serverless 技術最全內容，關注 Serverless 趨勢，更關注你落地實踐中的遇到的困惑和問題。

如何透過 Serverless 技術降低微服務應用資源成本？

相關文章