溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這期內容當中小編將會給大家帶來有關如何通過Serverless 技術降低微服務應用資源成本，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
在大型分布式 IT 架構領域，微服務是一項必不可少的技術。從本質上來講，微服務是一種架構風格，將一個大型的系統拆分為多個擁有獨立生命周期的應用，應用之間采用輕量級的通信機制進行通信。這些應用都是圍繞具體業務進行構建，可以獨立部署、獨立迭代，也可能根據業務負載獨立進行水平擴展。
微服務思想以及相關的技術為 IT 架構的發展帶來了一系列深刻的變革：
**易于開發和維護：**一個應用只會關注一組特定的業務功能，通過服務拆分，能減少應用之間的耦合度，讓開發和維護更加簡單。
**技術棧不受限制：**在微服務架構中，可以結合項目業務及團隊的特點，合理的選擇技術棧。
**加快系統演進速度：**每一個應用都可以獨立的進行版本更新，通過灰度發布等技術手段能確保發布過程中整個系統穩定運行。
**突破性能瓶頸：**每個應用都能獨立的水平伸縮，使系統性能可以根據計算資源的增加而得到線性的擴展。
世上沒有免費的午餐，微服務技術讓 IT 系統變得更敏捷、更健壯、更高性能的同時，也帶來了架構復雜度的提升。對于開發者而言，要想更好的駕馭微服務架構，需要解決持續集成、服務發現、應用通信、配置管理、流量防護等一系列難題。幸運的是，針對這些普遍存在的難題，業界涌現了一系列優秀的開源技術組件和工具，讓開發者可以更輕松的構建微服務應用。像 Spring Cloud 和 Dubbo 這樣的技術框架，經過多年的發展，已經演化為微服務領域的通用標準，極大地降低了微服務的門檻，但這些技術框架依然沒有辦法解決其中兩個最大的挑戰，這兩個挑戰成為擺在開發者面前的兩座大山。
在一個頻繁迭代的系統中，每個應用會經常性面臨新版本發布需求，需要對應用的上線、下線、更新、回滾等流程進行集中性的管理，并配合精細粒度的灰度發布手段，減少版本迭代對業務造成的影響。
在一個簡單的微服務架構中，如果某應用處于整個鏈路的入口位置，它的前端一般會掛上負載均衡組件（上圖中的應用 A），以承接來自于最終用戶的業務請求。這類應用在進行生命周期管理的時候，復雜度會更高，為了確保應用在新版本發布過程中的平衡穩定，會經過如下的步驟：
在這個流程中，還沒有涉及到對于流量精細粒度控制的高級灰度方案，但已經足夠體現出其復雜性和操作難度了。如果僅僅依賴于簡單的發布腳本進行管理，不但效率很低，還很容易導致顧此失彼，對系統穩定性造成巨大的風險。
當某一個應用的性能出現瓶頸，需要通過增加實例數量來提升性能的時候，就需要引入新的計算資源。
新的計算資源從何而來呢？
對于線下 IDC 而言，計算資源是需要預先規劃的，擴容并不是一件簡單的事情，可能會因為各種條件的制約而導致擴容無法實現。當然這種困擾在云計算時代不復存在了，為一個應用擴充計算資源是信手拈來的事情，但光有計算資源是不夠的，還得在上面部署應用，并將應用容納到微服務體系中。
根據這個流程，如果需要擴容一個應用實例，保守估計也需要 20 分鐘以上，其中購買、系統初始化、應用部署都需要占用大量的時間。假設系統流量突增，需要在 2 分鐘之內緊急擴容，這個方案就無用武之地了。
為了解決這兩個難題，開發者們嘗試了各種各樣的方案，新的理念以及技術框架在過去的這五年層出不窮。在一輪輪的優勝劣汰下，以 Docker 為代表的容器技術，在 Kubernetes 生態的支撐下，在業界成為了主流，是構建云原生（Cloud Native）應用的必備要素。容器化相關技術能夠更大程序的挖掘云計算的價值，在一定程度上幫助開發者解決這兩個難題。
在應用生命周期管理以及服務治理方面， Kubernetes 提供了比較完善的實現機制，通過構建 Deployment 資源，配合 proStop 和 postStart 腳本，能比較方便的實現滾動發布以及應用的優雅上下線。雖然在灰度發布的過程中，依然沒有辦法直接對流量進行精細粒度控制（引入 Service Mesh 技術能增強流量控制力，不在本文討論范圍），但相比簡單的發布腳本，已經有了飛躍性的提升。
在應用的水平擴容與縮容方面，通過容器化技術可以極大程度的減少操作系統安裝以及系統級初始化的時間，但購買虛擬機的操作是無法避免的，所以在系統遇到流量增突的時候，依然沒有辦法實現快速水平擴容。我們可以預留一部分計算資源，放在資源池中，當應用有擴容需求的時候，就向資源池申請資源，當業務負載下降的時候，再把多余的計算資源歸還到資源池中。
這其實并不是一個好主意，每一個計算資源都是需要成本的，資源池雖然能夠解決計算資源快速投入使用的問題，卻造成了巨大的浪費。另外，到底規劃多大的資源池，也是一件很傷腦筋的事情，池子越大，造成的浪費就越大，但池子太小，又可能滿足不了擴容的需求。
可能有的開發者會認為，目前的業務運行非常的穩定，在用戶流量上并不存在明顯的突增，所以擴容和縮容是一個偽需求，在將來也不會有這樣的需求。這可能是對互聯網業務的一種誤解，因為完全沒有擴容需求的情況是不存在的。
首先，只要一個系統是為人服務的，就必然存在波峰和波谷。對于一個 7*24 小時運行的系統，不可能永遠保持同樣的用戶流量，二八原則對于很多業務系統依然適用（ 80% 的用戶流量集中在 20% 的時間段）。即便是用戶流量相對平衡的系統，在凌晨也存在流量的低谷，如果能更進一步的釋放閑置計算資源，提升資源利用率，就能顯著的降低資源使用成本。
另外，相比生產環境，開發和測試環境對于擴容和縮容的需求會更加迫切。一套微服務應用由不同的團隊進行開發，在理想的情況下，多個團隊會共享一套測試環境：
然而，每個團隊對于應用的迭代都會有自己的節奏，與此同時，他們又想擁有獨立的端到端測試環境，從而實現環境之間的隔離，以避免團隊之間的相互影響。這樣的話，很有可能會形成多套測試環境：
隨著應用、團隊、業務功能點數量的增加，所需要的開發測試環境數量還會成倍的增長，造成巨大的資源浪費。對于測試環境的計算資源而言，資源利用率要遠低于生產環境。有的時候僅僅是一個簡單功能點的驗證，為了端對端的跑通業務功能，又避免團隊之間的相互影響，就會開啟一套包括全部微服務應用的新環境。這樣的資源浪費，對于很多企業，都是一個多年都未曾得到解決的難題。
因此，微服務架構在本質上就是對彈性伸縮有著強烈訴求的，在彈性伸縮的過程中，不管是單應用的水平彈性伸縮，還是整套環境的啟停，資源利用率都對最終的資源成本起著決定性的作用。如果能想辦法提升資源利用率，就能為企業節省大量資源成本。值得我們重視的是，絕大多數的微服務應用的資源利用率都是非常低的。
我們可以做一個簡單的統計：把所有服務器的 CPU 利用率每 5 分鐘導出一次，按照天的維度求平均值，就能從整體上了解系統的資源利用率數據。如果把開發測試環境的服務器資源也納入統計的范圍，資源利用率很有可能會更低。
資源利用率低的根本原因，在于以服務器為載體的應用架構中，開發者需要將構建好的程序包部署到服務器上，從而對多個用戶事件進行響應。為了確保事件響應的及時性，需要讓程序長駐于服務器上，而且盡可能保守的規劃資源，以避免出現負載過重而導致服務崩潰的情況。在這個過程中，實際的負載在時間上分配并不均衡，從而導致整體的資源利用率偏低。
Serverless 技術的出現，為提升資源利用率提供了新的思路。Serverless 是一種構建和管理基于微服務架構的完整流程，允許開發者脫離服務器資源而直接部署應用。它與傳統架構的不同之處在于，完全由第三方管理，由事件觸發，存在于無狀態（Stateless）的計算容器內。構建無服務器應用程序意味著開發者可以專注在產品代碼上，而無須管理和操作服務器資源，真正做到了部署應用無需涉及基礎設施的建設。
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）能否適配所有的業務場景。
是否有一種介于 FaaS 和 Serverless 化容器之間的技術，可以實現上述重要訴求呢？當然有，這就是以阿里云 Serverless 應用引擎（SAE）為代表的應用層 Serverless 技術。
（圖：不同層級的 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 還支持 2 種自動彈性機制，可以對微服務應用進行靈活的水平擴展，更進一步的發揮云計算的彈性能力。
**定時彈性機制：**對于會預期發生的周期性行為，可以設置定時彈性策略。舉例：如果每天的上午 9 點是業務高峰，可以定時每天 8 點半增加實例數量，并在 9 點半減少實例數量。
**基于指標閾值的彈性機制：**對于超出預期的業務流量突增，可以設置基于指標閾值的彈性策略，根據 CPU 、內存等資源指標，以有 QPS 等業務指標讓應用實現自動的彈性縮。
通過多種彈性機制，能夠對系統容量進行精細粒度的管理，使資源的使用量能隨著業務流量的變化而調整，從而極大程度的增加資源利用率，大幅降低資源成本。
在計算資源的調度和啟動上， SAE 做了多項優化，對于擴容出來的新實例，只需要幾秒鐘的時間就能拉起，這項能力對于一些需要緊急快速擴容的突發場景，是具有重大意義的。
對于開發測試環境而言，SAE 的機制彈性能力能體現得更加淋漓盡致，得益于 SAE 出色的資源調度能力，可以一鍵啟停一整套微服務應用。即便僅對一項簡單的新功能進行冒煙測試，也完全可以新啟一套完整而隔離的測試環境來進行。新的環境可以在秒級搭建完成，快速投入使用，而測試完畢后，又可以立即釋放。從成本上來講，一套新環境實際投入使用的時間很短，因此只會消耗極少的費用。這對于微服務應用開發過程中的多團隊協作，是一個巨大的變革。
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 等產品進行了深入集成，可以方便開發者將構建好的應用快速部署。
對于非 Java 語言編寫的應用，或者沒有使用 Spring Cloud 等微服務框架的 Java 應用， SAE 能不能完美支持，并幫助企業降低資源成本呢？
當然是可以的。SAE 提供容器鏡像部署方式，這就代表著不管采用哪種編程語言，只要最終的應用能夠發布成容器鏡像，就可以部署在 SAE 上。
對于 Java 系的微服務應用， Java 系統的普通應用，以及非 Java 系應用而言，SAE 的極致彈性能力并沒有本質的區別，都能通過 Serverless 技術提供系統的資源利用率。只不過 SAE 提供的一些附加價值，比如免費的微服務注冊中心，就只能為 Spring Cloud 或 Dubbo 應用服務罷了。
讓我們用這張圖回顧 Serverless 技術的巨大價值：
常見問題：
1.問：應用實例沒有固定的機器資源，連固定的 IP 地址都沒有，如何 SSH 到一臺服務器排查問題？
答：并不需要有固定的機器資源和固定的IP地址才能排查問題，在云計算時代，通過 SSH 登錄到一臺機器排查問題的方式并不是一個好的實踐。相反， SAE 提供了完善的監控能力，還可以方便的與云監控、 ARMS 等新一代監控診斷類產品進行了集成，為排查故障提供了更大的便利。當然，如果一定要登錄到某一臺機器，SSH 依然是可以支持的，也可以利用 SAE 提供的 Webshell 工具簡化這個流程。
2.問：磁盤不是計費的維度嗎？應用需要大容量磁盤怎么辦？應用重啟后碰盤中的數據還保留嗎？
答：在微服務領域，應用一般是無狀態（Stateless）的，不需要保存大量的本地數據。如果在特殊的場景下離不開這個需求，可以集成 NAS ，使用集中式的存儲實現。
3.問：應用的日志怎么查看？
答：SAE 控制臺界面提供了對于文件日志的實時查閱能力，相當于免費提供了一個分布式日志采集平臺。當然強烈建議接入阿里云日志服務（SLS）產品，更進一步的發揮應用日志的價值。
上述就是小編為大家分享的如何通過Serverless 技術降低微服務應用資源成本了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
