共計 7368 個字符，預計需要花費 19 分鐘才能閱讀完成。
如何通過 Serverless 技術降低微服務應用資源成本，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
前言
在大型分布式 IT 架構領域，微服務是一項必不可少的技術。從本質上來講，微服務是一種架構風格，將一個大型的系統(tǒng)拆分為多個擁有獨立生命周期的應用，應用之間采用輕量級的通信機制進行通信。這些應用都是圍繞具體業(yè)務進行構建，可以獨立部署、獨立迭代，也可能根據業(yè)務負載獨立的水平擴展。微服務思想以及相關的技術為 IT 架構的發(fā)展帶來了一系列深刻的變革：
1、易于開發(fā)和維護：一個應用只會關注一組特定的業(yè)務功能，通過服務拆分，能減少應用之間的耦合度，讓開發(fā)和維護更加簡單。
2、技術棧不受限制：在微服務架構中，可以結合項目業(yè)務及團隊的特點，合理的選擇技術棧。
3、加快系統(tǒng)演進速度：每一個應用都可以獨立的進行版本更新，通過灰度發(fā)布等技術手段能確保發(fā)布過程中整個系統(tǒng)穩(wěn)定運行。
4、突破性能瓶頸：每個應用都能獨立的水平伸縮，使系統(tǒng)性能可以根據計算資源的增加而得到線性的擴展。
微服務的挑戰(zhàn)
世上沒有免費的午餐，微服務技術讓 IT 系統(tǒng)變得更敏捷、更健壯、更高性能的同時，也帶來了架構復雜度的提升。對于開發(fā)者而言，要想更好的駕馭微服務架構，需要解決持續(xù)集成、服務發(fā)現(xiàn)、應用通信、配置管理、流量防護等一系列難題。幸運的是，針對這些普遍存在的難題，業(yè)界涌現(xiàn)了一系列優(yōu)秀的開源技術組件和工具，讓開發(fā)者可以更輕松的構建微服務應用。像 Spring Cloud 和 Dubbo 這樣的技術框架，經過多年的發(fā)展，已經演化為微服務領域的通用標準，極大地降低了微服務的門檻，但這些技術框架依然沒有辦法解決其中兩個最大的挑戰(zhàn)，這兩個挑戰(zhàn)成為擺在開發(fā)者面前的兩座大山。
挑戰(zhàn)一
亟需完善的生命周期管理與服務治理方案：在一個頻繁迭代的系統(tǒng)中，每個應用會經常性面臨新版本發(fā)布需求，需要對應用的上線、下線、更新、回滾等流程進行集中性的管理，并配合精細粒度的灰度發(fā)布手段，減少版本迭代對業(yè)務造成的影響。
在一個簡單的微服務架構中，如果某應用處于整個鏈路的入口位置，它的前端一般會掛上負載均衡組件（上圖中的應用 A），以承接來自于最終用戶的業(yè)務請求。這類應用在進行生命周期管理的時候，復雜度會更高，為了確保應用在新版本發(fā)布過程中的平衡穩(wěn)定，會經過如下的步驟：
在這個流程中，還沒有涉及到對于流量精細粒度控制的高級灰度方案，但已經足夠體現(xiàn)出其復雜性和操作難度了。如果僅僅依賴于簡單的發(fā)布腳本進行管理，不但效率很低，還很容易導致顧此失彼，對系統(tǒng)穩(wěn)定性造成巨大的風險。
挑戰(zhàn)二
亟需完善的水平擴容與縮容方案：當某一個應用的性能出現(xiàn)瓶頸，需要通過增加實例數量來進行性能提升的時候，就需要引入新的計算資源。新的計算資源從何而來呢？
對于線下 IDC 而言，計算資源是需要預先規(guī)劃的，擴容并不是一件簡單的事情，可能會因為各種條件的制約而導致擴容無法實現(xiàn)。當然這種困擾在云計算時代不復存在了，為一個應用擴充計算資源是信手拈來的事情，但光有計算資源是不夠的，還得在上面部署應用，并將應用容納到微服務體系中。
根據這個流程，如果需要擴容一個應用實例，保守估計也需要 20 分鐘以上，其中購買、系統(tǒng)初始化、應用部署都需要占用大量的時間。假設系統(tǒng)流量突增，需要在 2 分鐘之內緊急擴容，這個方案就無用武之地了。
一劑良藥：容器化技術
為了解決這兩個難題，開發(fā)者們嘗試了各種各樣的方案，新的理念以及技術框架在過去的這五年層出不窮。在一輪輪的優(yōu)勝劣汰下，以 Docker 為代表的容器技術，在 Kubernetes 生態(tài)的支撐下，在業(yè)界成為了主流，是構建云原生（Cloud Native）應用的必備要素。容器化相關技術能夠更大程序的挖掘云計算的價值，在一定程度上幫助開發(fā)者解決這兩個難題。
在應用生命周期管理以及服務治理方面，Kubernetes 提供了比較完善的實現(xiàn)機制，通過構建 Deployment 資源，配合 proStop 和 postStart 腳本，能比較方便的實現(xiàn)滾動發(fā)布以及應用的優(yōu)雅上下線。雖然在灰度發(fā)布的過程中，依然沒有辦法直接對流量進行精細粒度控制（引入 ServiceMesh 技術能增強流量控制力，不在本文討論范圍），但相比簡單的發(fā)布腳本，已經有了飛躍性的提升。
在應用的水平擴容與縮容方面，通過容器化技術可以極大程度的減少操作系統(tǒng)安裝以及系統(tǒng)級初始化的時間，但購買虛擬機的操作是無法避免的，所以在系統(tǒng)遇到流量增突的時候，依然沒有辦法實現(xiàn)快速水平擴容。
我們可以預留一部分計算資源，放在資源池中，當應用有擴容需求的時候，就向資源池申請資源，當業(yè)務負載下降的時候，再把多余的計算資源歸還到資源池中。
這其實并不是一個好主意，每一個計算資源都是需要成本的，資源池雖然能夠解決計算資源快速投入使用的問題，卻造成了巨大的浪費。另外，到底規(guī)劃多大的資源池，也是一件很傷腦筋的事情，池子越大，造成的浪費就越大，但池子太小，又可能滿足不了擴容的需求。
資源成本更深層次的分析
可能有的開發(fā)者會認為，目前的業(yè)務運行非常的穩(wěn)定，在用戶流量上并不存在明顯的突增，所以擴容和縮容是一個偽需求，在將來也不會有這樣的需求。這可能是對互聯(lián)網業(yè)務的一種誤解，因為完全沒有擴容需求的情況是不存在的。
首先，只要一個系統(tǒng)是為人服務的，就必然存在波峰和波谷。對于一個 7 *24 小時運行的系統(tǒng)，不可能永遠保持同樣的用戶流量，二八原則對于很多業(yè)務系統(tǒng)依然適用（80% 的用戶流量集中在 20% 的時間段。即便是用戶流量相對平衡的系統(tǒng)，在凌晨也存在流量的低谷，如果能更進一步的釋放閑置計算資源，提升資源利用率，就能顯著的降低資源使用成本。
另外，相比生產環(huán)境，開發(fā)和測試環(huán)境對于擴容和縮容的需求會更加迫切。一套微服務應用由不同的團隊進行開發(fā)，在理想的情況下，多個團隊會共享一套測試環(huán)境：
然而，每個團隊對于應用的迭代都會有自己的節(jié)奏，與此同時，他們又想擁有獨立的端到端測試環(huán)境，從而實現(xiàn)環(huán)境之間的隔離，以避免團隊之間的相互影響。這樣的話，很有可能會形成多套測試環(huán)境：
隨著應用、團隊、業(yè)務功能點數量的增加，所需要的開發(fā)測試環(huán)境數量還會成倍的增長，造成巨大的資源浪費。對于測試環(huán)境的計算資源而言，資源利用率要遠低于生產環(huán)境。有的時候僅僅是一個簡單功能點的驗證，為了端對端的跑通業(yè)務功能，又避免團隊之間的相互影響，就會開啟一套包括全部微服務應用的新環(huán)境。這樣的資源浪費，對于很多企業(yè)，都是一個多年都未曾得到解決的難題。
因此，微服務架構在本質上就是對彈性伸縮有著強烈訴求的，在彈性伸縮的過程中，不管是單應用的水平彈性伸縮，還是整套環(huán)境的啟停，資源利用率都對最終的資源成本起著決定性的作用。如果能想辦法提升資源利用率，就能為企業(yè)節(jié)省大量資源成本。值得我們重視的是，絕大多數的微服務應用的資源利用率都是非常低的。我們可以做一個簡單的統(tǒng)計：把所有服務器的 CPU 利用率每 5 分鐘導出一次，按照天的維度求平均值，就能從整體上了解系統(tǒng)的資源利用率數據。如果把開發(fā)測試環(huán)境的服務器資源也納入統(tǒng)計的范圍，資源利用率很有可能會更低。
Serverless 化探索
資源利用率低的根本原因，在于以服務器為載體的應用架構中，開發(fā)者需要將構建好的程序包部署到服務器上，從而對多個用戶事件進行響應。為了確保事件響應的及時性，需要讓程序長駐于服務器上，而且盡可能保守的規(guī)劃資源，以避免出現(xiàn)負載過重而導致服務崩潰的情況。在這個過程中，實際的負載在時間上分配并不均衡，從而導致整體的資源利用率偏低。
Serverless 技術的出現(xiàn)，為提升資源利用率提供了新的思路。Serverless 是一種構建和管理基于微服務架構的完整流程，允許開發(fā)者脫離服務器資源而直接部署應用。它與傳統(tǒng)架構的不同之處在于，完全由第三方管理，由事件觸發(fā)，存在于無狀態(tài)（Stateless）的計算容器內。構建無服務器應用程序意味著開發(fā)者可以專注在產品代碼上，而無須管理和操作服務器資源，真正做到了部署應用無需涉及基礎設施的建設。
Serverless 技術存在多種形態(tài)，最典型的一種是 FaaS（Function as a Service，函數即服務），比如阿里云的函數計算（Function Compute，F(xiàn)C）產品。在函數計算領域，一切計算資源的申請和調度都由具體的業(yè)務事件觸發(fā)，當業(yè)務事件所對應的任務完成之后，計算資源會被立即釋放。這樣的方式真做到了計算資源的按需分配，能顯著提升資源利用率，是 Serverless 技術的終極形態(tài)。
另外一種是 Serverless 化的容器技術，Serverless 化的容器實例運行在案例隔離的環(huán)境中，每個計算節(jié)點通過輕量級虛擬化安全沙箱技術完全強隔離。對于使用者而言，無需購買服務器資源即可直接部署容器應用，也無需對集群進行節(jié)點維護和容量規(guī)劃，可以根據應用配置的 CPU 和內存資源量進行按需付費。當微服務應用需要擴容的時候，就可以快速獲得計算資源，不需要再經過購買服務器這個步驟了，可以幫助開發(fā)者降低計算成本，減少閑置資源浪費，平滑應對突發(fā)流量高峰。阿里云的 Serverless Kubernetes（ASK）就是 Serverless 化容器技術的代表產品。
更進一步發(fā)掘開發(fā)者的訴求
Serverless 技術無縫是云計算和云原生應用架構的發(fā)展方向，但對于微服務應用的開發(fā)者而言，不管是 FaaS 形態(tài)，還是 Serverless Kubernetes，都存在一定的局限性。
不是每一種業(yè)務都適合通過 FaaS 的方式進行構建，特別是對于鏈路長，上下游依賴特別明顯的應用，根本沒有辦法進行 FaaS 化改造。即便某些業(yè)務系統(tǒng)的 FaaS 化改造被證明可行，把現(xiàn)有的微服務架構改造成 FaaS 架構也需要一定的工作量，并不能做到無縫移植。Serverless Kubernetes 架構雖然能適配所有的業(yè)務場景，但對于開發(fā)者而言，構建一整套 Kubernetes 體系，需要掌握一系列跟 Kubernetes 相關復雜的概念，有著非常陡的學習曲線。而且 Kubernetes 生態(tài)中各種組件的搭建，再加上網絡層與存儲層的適配，都涉及非常復雜的工作。
造成這種局限性的原因很簡單，在以 Spring Cloud 為代表的微服務技術陣營中，系統(tǒng)的構建都是圍繞著應用（也可以理解為單個的服務）而展開，不管是版本更新還是水平擴展，都是針對應用本身。Serverless Kubernetes 架構的核心在于 Pod，比應用更偏向系統(tǒng)底層，所以使用者需要投入更多的精力用于應用下層資源的管理。而 FaaS 架構的核心在于函數，比應用更偏向系統(tǒng)上層，因此靈活度會降低，不能適配所有的業(yè)務場景。
對于使用主流 Spring Cloud 體系或 Dubbo 體系構建微服務應用的開發(fā)者而言，如果需要引入一種方案降低資源成本，他的最終訴求一定包含兩個方面：
1、能否 0 改造成本，或者接近 0 改造成本。
2、能否適配所有的業(yè)務場景。
應用層 Serverless 技術
是否有一種介于 FaaS 和 Serverless 化容器之間的技術，可以實現(xiàn)上述重要訴求呢？當然有，這就是以阿里云 Serverless 應用引擎（SAE）為代表的應用層 Serverless 技術。
圖：不同層級的 Serverless 技術
SAE 實現(xiàn)了 Serverless 架構 + 微服務架構的完美融合，對于 Spring Cloud 和 Dubbo 等主流的微服務架構，可以實現(xiàn)無縫兼容，基本上沒有改造成本，并真正按需使用、按量計費，節(jié)省閑置計算資源，同時免去 IaaS 層運維方面的工作，有效提升開發(fā)運維效率。
以 Spring Cloud 應用為例，如果需要部署一個新的應用，只需要 2 個步驟：
1、告訴 SAE 這個應用需要多少個實例，并指定每個實例需要的 CPU/ 內存規(guī)格。
2、上傳應用的 JAR 包 /WAR 包，并啟動應用。
我們發(fā)現(xiàn)，這 2 個步驟中并不涉及容量評估、服務器購買、操作系統(tǒng)安裝、資源初始化等工作，就能讓包含多個對等實例的微服務應用運行起來。這是因為在 Serverless 的世界中，不再具有服務器資源這樣的概念，應用的載體是 SAE 調度出來的沙箱容器，每個實例只有在真正投入使用后，才會按使用時長進行計費。
對于開發(fā)者而言，他們不用關心應用到底部署在物理機里面，還是虛擬機里面，或是容器里面，也不需要知道底層的操作系統(tǒng)是什么版本的，只需要關注每個應用實例占據多少運算資源就可以了。如果應用需要從 4 個實例擴容到 6 個實例，或者縮容到 2 個實例，只需要一個指令就可以完成，甚至與 SLB 的綁定關系，都可以自動的建立或解除，這是 Serverless 技術為開發(fā)者帶來的巨大價值。
使用 SAE 部署微服務應用，因為只是變更了應用運行的載體，所以可以 100% 的兼容現(xiàn)有的技術架構和業(yè)務功能，遷移成本可以忽略不計。
SAE 的極致彈性能力
除了手動的擴縮容指令，SAE 還支持 2 種自動彈性機制，可以對微服務應用進行靈活的水平擴展，更進一步的發(fā)揮云計算的彈性能力。
1、定時彈性機制：對于會預期發(fā)生的周期性行為，可以設置定時彈性策略。舉例：如果每天的上午 9 點是業(yè)務高峰，可以定時每天 8 點半增加實例數量，并在 9 點半減少實例數量。
2、基于指標閾值的彈性機制：對于超出預期的業(yè)務流量突增，可以設置基于指標閾值的彈性策略，根據 CPU、內存等資源指標，以有 QPS 等業(yè)務指標讓應用實現(xiàn)自動的彈性縮。
通過多種彈性機制，能夠對系統(tǒng)容量進行精細粒度的管理，使資源的使用量能隨著業(yè)務流量的變化而調整，從而極大程度的增加資源利用率，大幅降低資源成本。
在計算資源的調度和啟動上，SAE 做了多項優(yōu)化，對于擴容出來的新實例，只需要幾秒鐘的時間就能拉起，這項能力對于一些需要緊急快速擴容的突發(fā)場景，是具有重大意義的。
對于開發(fā)測試環(huán)境而言，SAE 的機制彈性能力能體現(xiàn)得更加淋漓盡致，得益于 SAE 出色的資源調度能力，可以一鍵啟停一整套微服務應用。即便僅對一項簡單的新功能進行冒煙測試，也完全可以新啟一套完整而隔離的測試環(huán)境來進行。新的環(huán)境可以在秒級搭建完成，快速投入使用，而測試完畢后，又可以立即釋放。從成本上來講，一套新環(huán)境實際投入使用的時間很短，因此只會消耗極少的費用。這對于微服務應用開發(fā)過程中的多團隊協(xié)作，是一個巨大的變革。
成本分析
SAE 通過資源的實際使用量來付費，費用由兩部分組成，每部分根據統(tǒng)計結果和計算方式進行費用結算，按小時出賬單扣款。每個應用使用的資源計量方式如下所示：
1、應用 CPU 資源使用量 =∑實例 CPU 規(guī)格×本月運行時長（以分鐘計），即應用中所有實例的 CPU 規(guī)格乘以本月運行時長的總和。
2、應用內存資源使用量 =∑實例內存規(guī)格×本月運行時長（以分鐘計），即應用中所有實例的內存規(guī)格乘以本月運行時長的總和。
其中 CPU 部分的價格為 0.0021605 元 / 分鐘 /Core，內存部分的價格為 0.0005401 元 / 分鐘 /GiB。SAE 還提供預付費資源包，相當于批發(fā)的方式預購計算資源，只要能要有效期內消耗完，就能更進一步的節(jié)省使用成本，當資源包扣完以后，系統(tǒng)會自動變更為按量付費的模式。
讓我們通過一個實際案例來進一步體會 SAE 如何幫助微服務應用降低資源成本。假設一個微服務系統(tǒng)包含 87 個應用實例，每個時間每天的平均運行時長為 8 小時，實例的配置為 2 Core + 4 GiB + 20 G 磁盤。
1、使用包年包月的 ECS 部署應用：需要購買 87 臺計算型 c5，單臺的月成本為 186 元，每月總成本 16146 元。
2、使用按量付費的 ECS 部署應用：單臺價格為 0.63 元 / 小時，每月累計使用 20880 小時，總成本 13154 元。
3、使用 SAE 部署應用：購買 1 個 75000 元的包年資源包，87 個實例每天運行 8 個小時，剛好把資源包額度用完，折合每月總成本 6250 元。
從這個對比我們可以得出，只要能夠合理的運行 SAE 的彈性能力，就可以為微服務應用大幅度降低資源成本。
附加能力
SAE 除了可以簡化運維工作量，降低資源成本以外，還為微服務應用提升了一系列附加的功能，這是應用層 Serverless 技術為開發(fā)者帶來的額外價值，我們可以盡可能的利用這些開箱即用的功能，讓建設微服務應用變成更加簡單。
1、完整的應用生命周期管理：應用托管至 SAE 后，可以對應用執(zhí)行更新、擴縮容、啟停、刪除、監(jiān)控啟停等應用生命周期管理操作。
2、開箱即用的注冊中心：SAE 自帶商業(yè)版 Nacos 注冊中心，可以免費使用，不需要自行搭建。如果有特殊的需求，比如讓部署在 SAE 的應用和其他應用相互發(fā)現(xiàn)，也可以使用微服務引擎（MSE）產品提供的注冊中心，或者自建的注冊中心。
3、開箱即用的配置管理中心：SAE 集成了 ACM（Application Configuration Management，應用配置管理）中的配置管理功能，可以在 SAE 中使用 ACM 對應用配置進行集中管理。
4、應用級流量防護：SAE 集成 AHAS 實現(xiàn)應用級別的流控與降級能力，全面保障應用的高可用性。
5、監(jiān)控能力：應用托管到 SAE 以后，可以免費獲得基礎資源（包括 CPU、內存、負載和網絡）以及應用層（包括 JVM 分析、接口調用分析等方面）的監(jiān)控能力。如果需要更高級的 SQL 分析、異常分析、鏈路上下游和接口快照，可以集成阿里云應用時間監(jiān)控產品（ARMS）。
6、CI/CD 集成能力：SAE 與云效、云效 2020、Jenkins 等產品進行了深入集成，可以方便開發(fā)者將構建好的應用快速部署。
多語言支持
對于非 Java 語言編寫的應用，或者沒有使用 Spring Cloud 等微服務框架的 Java 應用，SAE 能不能完美支持，并幫助企業(yè)降低資源成本呢？當然是可以的。SAE 提供容器鏡像部署方式，這就代表著不管采用哪種編程語言，只要最終的應用能夠發(fā)布成容器鏡像，就可以部署在 SAE 上。
對于 Java 系的微服務應用，Java 系統(tǒng)的普通應用，以及非 Java 系應用而言，SAE 的極致彈性能力并沒有本質的區(qū)別，都能通過 Serverless 技術提供系統(tǒng)的資源利用率。只不過 SAE 提供的一些附加價值，比如免費的微服務注冊中心，就只能為 Spring Cloud 或 Dubbo 應用服務罷了。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業(yè)資訊頻道，感謝您對丸趣 TV 的支持。
