簡介：從本質(zhì)上來講，微服務(wù)是一種架構(gòu)風(fēng)格，將一個(gè)大型的系統(tǒng)拆分為多個(gè)擁有獨(dú)立生命周期的應(yīng)用，應(yīng)用之間采用輕量級(jí)的通信機(jī)制進(jìn)行通信。這些應(yīng)用都是圍繞具體業(yè)務(wù)進(jìn)行構(gòu)建，可以獨(dú)立部署、獨(dú)立迭代，也可能根據(jù)業(yè)務(wù)負(fù)載獨(dú)立的水平擴(kuò)展。

前言

在大型分布式IT架構(gòu)領(lǐng)域，微服務(wù)是一項(xiàng)必不可少的技術(shù)。從本質(zhì)上來講，微服務(wù)是一種架構(gòu)風(fēng)格，將一個(gè)大型的系統(tǒng)拆分為多個(gè)擁有獨(dú)立生命周期的應(yīng)用，應(yīng)用之間采用輕量級(jí)的通信機(jī)制進(jìn)行通信。這些應(yīng)用都是圍繞具體業(yè)務(wù)進(jìn)行構(gòu)建，可以獨(dú)立部署、獨(dú)立迭代，也可能根據(jù)業(yè)務(wù)負(fù)載獨(dú)立的水平擴(kuò)展。微服務(wù)思想以及相關(guān)的技術(shù)為IT架構(gòu)的發(fā)展帶來了一系列深刻的變革：
1、 易于開發(fā)和維護(hù)：一個(gè)應(yīng)用只會(huì)關(guān)注一組特定的業(yè)務(wù)功能，通過服務(wù)拆分，能減少應(yīng)用之間的耦合度，讓開發(fā)和維護(hù)更加簡單。
2、 技術(shù)棧不受限制：在微服務(wù)架構(gòu)中，可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)，合理的選擇技術(shù)棧。
3、 加快系統(tǒng)演進(jìn)速度：每一個(gè)應(yīng)用都可以獨(dú)立的進(jìn)行版本更新，通過灰度發(fā)布等技術(shù)手段能確保發(fā)布過程中整個(gè)系統(tǒng)穩(wěn)定運(yùn)行。
4、 突破性能瓶頸：每個(gè)應(yīng)用都能獨(dú)立的水平伸縮，使系統(tǒng)性能可以根據(jù)計(jì)算資源的增加而得到線性的擴(kuò)展。

微服務(wù)的挑戰(zhàn)

世上沒有免費(fèi)的午餐，微服務(wù)技術(shù)讓IT系統(tǒng)變得更敏捷、更健壯、更高性能的同時(shí)，也帶來了架構(gòu)復(fù)雜度的提升。對(duì)于開發(fā)者而言，要想更好的駕馭微服務(wù)架構(gòu)，需要解決持續(xù)集成、服務(wù)發(fā)現(xiàn)、應(yīng)用通信、配置管理、流量防護(hù)等一系列難題。幸運(yùn)的是，針對(duì)這些普遍存在的難題，業(yè)界涌現(xiàn)了一系列優(yōu)秀的開源技術(shù)組件和工具，讓開發(fā)者可以更輕松的構(gòu)建微服務(wù)應(yīng)用。像Spring Cloud和Dubbo這樣的技術(shù)框架，經(jīng)過多年的發(fā)展，已經(jīng)演化為微服務(wù)領(lǐng)域的通用標(biāo)準(zhǔn)，極大地降低了微服務(wù)的門檻，但這些技術(shù)框架依然沒有辦法解決其中兩個(gè)最大的挑戰(zhàn)，這兩個(gè)挑戰(zhàn)成為擺在開發(fā)者面前的兩座大山。

挑戰(zhàn)一

亟需完善的生命周期管理與服務(wù)治理方案：在一個(gè)頻繁迭代的系統(tǒng)中，每個(gè)應(yīng)用會(huì)經(jīng)常性面臨新版本發(fā)布需求，需要對(duì)應(yīng)用的上線、下線、更新、回滾等流程進(jìn)行集中性的管理，并配合精細(xì)粒度的灰度發(fā)布手段，減少版本迭代對(duì)業(yè)務(wù)造成的影響。

在一個(gè)簡單的微服務(wù)架構(gòu)中，如果某應(yīng)用處于整個(gè)鏈路的入口位置，它的前端一般會(huì)掛上負(fù)載均衡組件（上圖中的應(yīng)用A），以承接來自于最終用戶的業(yè)務(wù)請(qǐng)求。這類應(yīng)用在進(jìn)行生命周期管理的時(shí)候，復(fù)雜度會(huì)更高，為了確保應(yīng)用在新版本發(fā)布過程中的平衡穩(wěn)定，會(huì)經(jīng)過如下的步驟：

在這個(gè)流程中，還沒有涉及到對(duì)于流量精細(xì)粒度控制的高級(jí)灰度方案，但已經(jīng)足夠體現(xiàn)出其復(fù)雜性和操作難度了。如果僅僅依賴于簡單的發(fā)布腳本進(jìn)行管理，不但效率很低，還很容易導(dǎo)致顧此失彼，對(duì)系統(tǒng)穩(wěn)定性造成巨大的風(fēng)險(xiǎn)。

挑戰(zhàn)二

亟需完善的水平擴(kuò)容與縮容方案：當(dāng)某一個(gè)應(yīng)用的性能出現(xiàn)瓶頸，需要通過增加實(shí)例數(shù)量來進(jìn)行性能提升的時(shí)候，就需要引入新的計(jì)算資源。新的計(jì)算資源從何而來呢？

對(duì)于線下IDC而言，計(jì)算資源是需要預(yù)先規(guī)劃的，擴(kuò)容并不是一件簡單的事情，可能會(huì)因?yàn)楦鞣N條件的制約而導(dǎo)致擴(kuò)容無法實(shí)現(xiàn)。當(dāng)然這種困擾在云計(jì)算時(shí)代不復(fù)存在了，為一個(gè)應(yīng)用擴(kuò)充計(jì)算資源是信手拈來的事情，但光有計(jì)算資源是不夠的，還得在上面部署應(yīng)用，并將應(yīng)用容納到微服務(wù)體系中。

根據(jù)這個(gè)流程，如果需要擴(kuò)容一個(gè)應(yīng)用實(shí)例，保守估計(jì)也需要20分鐘以上，其中購買、系統(tǒng)初始化、應(yīng)用部署都需要占用大量的時(shí)間。假設(shè)系統(tǒng)流量突增，需要在2分鐘之內(nèi)緊急擴(kuò)容，這個(gè)方案就無用武之地了。

一劑良藥：容器化技術(shù)

為了解決這兩個(gè)難題，開發(fā)者們嘗試了各種各樣的方案，新的理念以及技術(shù)框架在過去的這五年層出不窮。在一輪輪的優(yōu)勝劣汰下，以Docker為代表的容器技術(shù)，在Kubernetes生態(tài)的支撐下，在業(yè)界成為了主流，是構(gòu)建云原生（Cloud Native）應(yīng)用的必備要素。容器化相關(guān)技術(shù)能夠更大程序的挖掘云計(jì)算的價(jià)值，在一定程度上幫助開發(fā)者解決這兩個(gè)難題。

在應(yīng)用生命周期管理以及服務(wù)治理方面，Kubernetes提供了比較完善的實(shí)現(xiàn)機(jī)制，通過構(gòu)建Deployment資源，配合proStop和postStart腳本，能比較方便的實(shí)現(xiàn)滾動(dòng)發(fā)布以及應(yīng)用的優(yōu)雅上下線。雖然在灰度發(fā)布的過程中，依然沒有辦法直接對(duì)流量進(jìn)行精細(xì)粒度控制（引入ServiceMesh技術(shù)能增強(qiáng)流量控制力，不在本文討論范圍），但相比簡單的發(fā)布腳本，已經(jīng)有了飛躍性的提升。

在應(yīng)用的水平擴(kuò)容與縮容方面，通過容器化技術(shù)可以極大程度的減少操作系統(tǒng)安裝以及系統(tǒng)級(jí)初始化的時(shí)間，但購買虛擬機(jī)的操作是無法避免的，所以在系統(tǒng)遇到流量增突的時(shí)候，依然沒有辦法實(shí)現(xiàn)快速水平擴(kuò)容。

我們可以預(yù)留一部分計(jì)算資源，放在資源池中，當(dāng)應(yīng)用有擴(kuò)容需求的時(shí)候，就向資源池申請(qǐng)資源，當(dāng)業(yè)務(wù)負(fù)載下降的時(shí)候，再把多余的計(jì)算資源歸還到資源池中。

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

資源成本更深層次的分析

可能有的開發(fā)者會(huì)認(rèn)為，目前的業(yè)務(wù)運(yùn)行非常的穩(wěn)定，在用戶流量上并不存在明顯的突增，所以擴(kuò)容和縮容是一個(gè)偽需求，在將來也不會(huì)有這樣的需求。這可能是對(duì)互聯(lián)網(wǎng)業(yè)務(wù)的一種誤解，因?yàn)橥耆珱]有擴(kuò)容需求的情況是不存在的。

首先，只要一個(gè)系統(tǒng)是為人服務(wù)的，就必然存在波峰和波谷。對(duì)于一個(gè)7*24小時(shí)運(yùn)行的系統(tǒng)，不可能永遠(yuǎn)保持同樣的用戶流量，二八原則對(duì)于很多業(yè)務(wù)系統(tǒng)依然適用（80%的用戶流量集中在20%的時(shí)間段。即便是用戶流量相對(duì)平衡的系統(tǒng)，在凌晨也存在流量的低谷，如果能更進(jìn)一步的釋放閑置計(jì)算資源，提升資源利用率，就能顯著的降低資源使用成本。

另外，相比生產(chǎn)環(huán)境，開發(fā)和測試環(huán)境對(duì)于擴(kuò)容和縮容的需求會(huì)更加迫切。一套微服務(wù)應(yīng)用由不同的團(tuán)隊(duì)進(jìn)行開發(fā)，在理想的情況下，多個(gè)團(tuán)隊(duì)會(huì)共享一套測試環(huán)境：

然而，每個(gè)團(tuán)隊(duì)對(duì)于應(yīng)用的迭代都會(huì)有自己的節(jié)奏，與此同時(shí)，他們又想擁有獨(dú)立的端到端測試環(huán)境，從而實(shí)現(xiàn)環(huán)境之間的隔離，以避免團(tuán)隊(duì)之間的相互影響。這樣的話，很有可能會(huì)形成多套測試環(huán)境：

隨著應(yīng)用、團(tuán)隊(duì)、業(yè)務(wù)功能點(diǎn)數(shù)量的增加，所需要的開發(fā)測試環(huán)境數(shù)量還會(huì)成倍的增長，造成巨大的資源浪費(fèi)。對(duì)于測試環(huán)境的計(jì)算資源而言，資源利用率要遠(yuǎn)低于生產(chǎn)環(huán)境。有的時(shí)候僅僅是一個(gè)簡單功能點(diǎn)的驗(yàn)證，為了端對(duì)端的跑通業(yè)務(wù)功能，又避免團(tuán)隊(duì)之間的相互影響，就會(huì)開啟一套包括全部微服務(wù)應(yīng)用的新環(huán)境。這樣的資源浪費(fèi)，對(duì)于很多企業(yè)，都是一個(gè)多年都未曾得到解決的難題。

因此，微服務(wù)架構(gòu)在本質(zhì)上就是對(duì)彈性伸縮有著強(qiáng)烈訴求的，在彈性伸縮的過程中，不管是單應(yīng)用的水平彈性伸縮，還是整套環(huán)境的啟停，資源利用率都對(duì)最終的資源成本起著決定性的作用。如果能想辦法提升資源利用率，就能為企業(yè)節(jié)省大量資源成本。值得我們重視的是，絕大多數(shù)的微服務(wù)應(yīng)用的資源利用率都是非常低的。我們可以做一個(gè)簡單的統(tǒng)計(jì)：把所有服務(wù)器的CPU利用率每5分鐘導(dǎo)出一次，按照天的維度求平均值，就能從整體上了解系統(tǒng)的資源利用率數(shù)據(jù)。如果把開發(fā)測試環(huán)境的服務(wù)器資源也納入統(tǒng)計(jì)的范圍，資源利用率很有可能會(huì)更低。

Serverless化探索

資源利用率低的根本原因，在于以服務(wù)器為載體的應(yīng)用架構(gòu)中，開發(fā)者需要將構(gòu)建好的程序包部署到服務(wù)器上，從而對(duì)多個(gè)用戶事件進(jìn)行響應(yīng)。為了確保事件響應(yīng)的及時(shí)性，需要讓程序長駐于服務(wù)器上，而且盡可能保守的規(guī)劃資源，以避免出現(xiàn)負(fù)載過重而導(dǎo)致服務(wù)崩潰的情況。在這個(gè)過程中，實(shí)際的負(fù)載在時(shí)間上分配并不均衡，從而導(dǎo)致整體的資源利用率偏低。

Serverless技術(shù)的出現(xiàn)，為提升資源利用率提供了新的思路。Serverless是一種構(gòu)建和管理基于微服務(wù)架構(gòu)的完整流程，允許開發(fā)者脫離服務(wù)器資源而直接部署應(yīng)用。它與傳統(tǒng)架構(gòu)的不同之處在于，完全由第三方管理，由事件觸發(fā)，存在于無狀態(tài)（Stateless）的計(jì)算容器內(nèi)。構(gòu)建無服務(wù)器應(yīng)用程序意味著開發(fā)者可以專注在產(chǎn)品代碼上，而無須管理和操作服務(wù)器資源，真正做到了部署應(yīng)用無需涉及基礎(chǔ)設(shè)施的建設(shè)。

Serverless技術(shù)存在多種形態(tài)，最典型的一種是FaaS（Function as a Service，函數(shù)即服務(wù)），比如阿里云的函數(shù)計(jì)算（Function Compute，FC）產(chǎn)品。在函數(shù)計(jì)算領(lǐng)域，一切計(jì)算資源的申請(qǐng)和調(diào)度都由具體的業(yè)務(wù)事件觸發(fā)，當(dāng)業(yè)務(wù)事件所對(duì)應(yīng)的任務(wù)完成之后，計(jì)算資源會(huì)被立即釋放。這樣的方式真做到了計(jì)算資源的按需分配，能顯著提升資源利用率，是Serverless技術(shù)的終極形態(tài)。

另外一種是Serverless化的容器技術(shù)，Serverless化的容器實(shí)例運(yùn)行在案例隔離的環(huán)境中，每個(gè)計(jì)算節(jié)點(diǎn)通過輕量級(jí)虛擬化安全沙箱技術(shù)完全強(qiáng)隔離。對(duì)于使用者而言，無需購買服務(wù)器資源即可直接部署容器應(yīng)用，也無需對(duì)集群進(jìn)行節(jié)點(diǎn)維護(hù)和容量規(guī)劃，可以根據(jù)應(yīng)用配置的CPU和內(nèi)存資源量進(jìn)行按需付費(fèi)。當(dāng)微服務(wù)應(yīng)用需要擴(kuò)容的時(shí)候，就可以快速獲得計(jì)算資源，不需要再經(jīng)過購買服務(wù)器這個(gè)步驟了，可以幫助開發(fā)者降低計(jì)算成本，減少閑置資源浪費(fèi)，平滑應(yīng)對(duì)突發(fā)流量高峰。阿里云的Serverless Kubernetes（ASK）就是Serverless化容器技術(shù)的代表產(chǎn)品。

更進(jìn)一步發(fā)掘開發(fā)者的訴求

Serverless技術(shù)無縫是云計(jì)算和云原生應(yīng)用架構(gòu)的發(fā)展方向，但對(duì)于微服務(wù)應(yīng)用的開發(fā)者而言，不管是FaaS形態(tài)，還是Serverless Kubernetes，都存在一定的局限性。

不是每一種業(yè)務(wù)都適合通過FaaS的方式進(jìn)行構(gòu)建，特別是對(duì)于鏈路長，上下游依賴特別明顯的應(yīng)用，根本沒有辦法進(jìn)行FaaS化改造。即便某些業(yè)務(wù)系統(tǒng)的FaaS化改造被證明可行，把現(xiàn)有的微服務(wù)架構(gòu)改造成FaaS架構(gòu)也需要一定的工作量，并不能做到無縫移植。

Serverless Kubernetes架構(gòu)雖然能適配所有的業(yè)務(wù)場景，但對(duì)于開發(fā)者而言，構(gòu)建一整套Kubernetes體系，需要掌握一系列跟Kubernetes相關(guān)復(fù)雜的概念，有著非常陡的學(xué)習(xí)曲線。而且Kubernetes生態(tài)中各種組件的搭建，再加上網(wǎng)絡(luò)層與存儲(chǔ)層的適配，都涉及非常復(fù)雜的工作。

造成這種局限性的原因很簡單，在以Spring Cloud為代表的微服務(wù)技術(shù)陣營中，系統(tǒng)的構(gòu)建都是圍繞著應(yīng)用（也可以理解為單個(gè)的服務(wù)）而展開，不管是版本更新還是水平擴(kuò)展，都是針對(duì)應(yīng)用本身。Serverless Kubernetes架構(gòu)的核心在于Pod，比應(yīng)用更偏向系統(tǒng)底層，所以使用者需要投入更多的精力用于應(yīng)用下層資源的管理。而FaaS架構(gòu)的核心在于函數(shù)，比應(yīng)用更偏向系統(tǒng)上層，因此靈活度會(huì)降低，不能適配所有的業(yè)務(wù)場景。

對(duì)于使用主流Spring Cloud體系或Dubbo體系構(gòu)建微服務(wù)應(yīng)用的開發(fā)者而言，如果需要引入一種方案降低資源成本，他的最終訴求一定包含兩個(gè)方面：

1、 能否0改造成本，或者接近0改造成本。
2、 能否適配所有的業(yè)務(wù)場景。

應(yīng)用層Serverless技術(shù)

是否有一種介于FaaS和Serverless化容器之間的技術(shù)，可以實(shí)現(xiàn)上述重要訴求呢？當(dāng)然有，這就是以阿里云Serverless應(yīng)用引擎（SAE）為代表的應(yīng)用層Serverless技術(shù)。

圖：不同層級(jí)的Serverless技術(shù)

SAE實(shí)現(xiàn)了Serverless 架構(gòu) + 微服務(wù)架構(gòu)的完美融合，對(duì)于Spring Cloud和Dubbo等主流的微服務(wù)架構(gòu)，可以實(shí)現(xiàn)無縫兼容，基本上沒有改造成本，并真正按需使用、按量計(jì)費(fèi)，節(jié)省閑置計(jì)算資源，同時(shí)免去 IaaS層運(yùn)維方面的工作，有效提升開發(fā)運(yùn)維效率。

以Spring Cloud應(yīng)用為例，如果需要部署一個(gè)新的應(yīng)用，只需要2個(gè)步驟：
1、 告訴SAE這個(gè)應(yīng)用需要多少個(gè)實(shí)例，并指定每個(gè)實(shí)例需要的CPU/內(nèi)存規(guī)格。
2、 上傳應(yīng)用的JAR包/WAR包，并啟動(dòng)應(yīng)用。

我們發(fā)現(xiàn)，這2個(gè)步驟中并不涉及容量評(píng)估、服務(wù)器購買、操作系統(tǒng)安裝、資源初始化等工作，就能讓包含多個(gè)對(duì)等實(shí)例的微服務(wù)應(yīng)用運(yùn)行起來。這是因?yàn)樵赟erverless的世界中，不再具有服務(wù)器資源這樣的概念，應(yīng)用的載體是SAE調(diào)度出來的沙箱容器，每個(gè)實(shí)例只有在真正投入使用后，才會(huì)按使用時(shí)長進(jìn)行計(jì)費(fèi)。

對(duì)于開發(fā)者而言，他們不用關(guān)心應(yīng)用到底部署在物理機(jī)里面，還是虛擬機(jī)里面，或是容器里面，也不需要知道底層的操作系統(tǒng)是什么版本的，只需要關(guān)注每個(gè)應(yīng)用實(shí)例占據(jù)多少運(yùn)算資源就可以了。如果應(yīng)用需要從4個(gè)實(shí)例擴(kuò)容到6個(gè)實(shí)例，或者縮容到2個(gè)實(shí)例，只需要一個(gè)指令就可以完成，甚至與SLB的綁定關(guān)系，都可以自動(dòng)的建立或解除，這是Serverless技術(shù)為開發(fā)者帶來的巨大價(jià)值。

使用SAE部署微服務(wù)應(yīng)用，因?yàn)橹皇亲兏藨?yīng)用運(yùn)行的載體，所以可以100%的兼容現(xiàn)有的技術(shù)架構(gòu)和業(yè)務(wù)功能，遷移成本可以忽略不計(jì)。

SAE的極致彈性能力

除了手動(dòng)的擴(kuò)縮容指令，SAE還支持2種自動(dòng)彈性機(jī)制，可以對(duì)微服務(wù)應(yīng)用進(jìn)行靈活的水平擴(kuò)展，更進(jìn)一步的發(fā)揮云計(jì)算的彈性能力。

1、 定時(shí)彈性機(jī)制：對(duì)于會(huì)預(yù)期發(fā)生的周期性行為，可以設(shè)置定時(shí)彈性策略。舉例：如果每天的上午9點(diǎn)是業(yè)務(wù)高峰，可以定時(shí)每天8點(diǎn)半增加實(shí)例數(shù)量，并在9點(diǎn)半減少實(shí)例數(shù)量。
2、 基于指標(biāo)閾值的彈性機(jī)制：對(duì)于超出預(yù)期的業(yè)務(wù)流量突增，可以設(shè)置基于指標(biāo)閾值的彈性策略，根據(jù)CPU、內(nèi)存等資源指標(biāo)，以有QPS等業(yè)務(wù)指標(biāo)讓應(yīng)用實(shí)現(xiàn)自動(dòng)的彈性縮。

通過多種彈性機(jī)制，能夠?qū)ο到y(tǒng)容量進(jìn)行精細(xì)粒度的管理，使資源的使用量能隨著業(yè)務(wù)流量的變化而調(diào)整，從而極大程度的增加資源利用率，大幅降低資源成本。

在計(jì)算資源的調(diào)度和啟動(dòng)上，SAE做了多項(xiàng)優(yōu)化，對(duì)于擴(kuò)容出來的新實(shí)例，只需要幾秒鐘的時(shí)間就能拉起，這項(xiàng)能力對(duì)于一些需要緊急快速擴(kuò)容的突發(fā)場景，是具有重大意義的。

對(duì)于開發(fā)測試環(huán)境而言，SAE的機(jī)制彈性能力能體現(xiàn)得更加淋漓盡致，得益于SAE出色的資源調(diào)度能力，可以一鍵啟停一整套微服務(wù)應(yīng)用。即便僅對(duì)一項(xiàng)簡單的新功能進(jìn)行冒煙測試，也完全可以新啟一套完整而隔離的測試環(huán)境來進(jìn)行。新的環(huán)境可以在秒級(jí)搭建完成，快速投入使用，而測試完畢后，又可以立即釋放。從成本上來講，一套新環(huán)境實(shí)際投入使用的時(shí)間很短，因此只會(huì)消耗極少的費(fèi)用。這對(duì)于微服務(wù)應(yīng)用開發(fā)過程中的多團(tuán)隊(duì)協(xié)作，是一個(gè)巨大的變革。

成本分析

SAE通過資源的實(shí)際使用量來付費(fèi)，費(fèi)用由兩部分組成，每部分根據(jù)統(tǒng)計(jì)結(jié)果和計(jì)算方式進(jìn)行費(fèi)用結(jié)算，按小時(shí)出賬單扣款。每個(gè)應(yīng)用使用的資源計(jì)量方式如下所示：

1、 應(yīng)用CPU資源使用量=∑實(shí)例CPU規(guī)格×本月運(yùn)行時(shí)長（以分鐘計(jì)），即應(yīng)用中所有實(shí)例的CPU規(guī)格乘以本月運(yùn)行時(shí)長的總和。
2、 應(yīng)用內(nèi)存資源使用量=∑實(shí)例內(nèi)存規(guī)格×本月運(yùn)行時(shí)長（以分鐘計(jì)），即應(yīng)用中所有實(shí)例的內(nèi)存規(guī)格乘以本月運(yùn)行時(shí)長的總和。

其中CPU部分的價(jià)格為0.0021605元/分鐘/Core，內(nèi)存部分的價(jià)格為0.0005401元/分鐘/GiB。SAE還提供預(yù)付費(fèi)資源包，相當(dāng)于批發(fā)的方式預(yù)購計(jì)算資源，只要能要有效期內(nèi)消耗完，就能更進(jìn)一步的節(jié)省使用成本，當(dāng)資源包扣完以后，系統(tǒng)會(huì)自動(dòng)變更為按量付費(fèi)的模式。

讓我們通過一個(gè)實(shí)際案例來進(jìn)一步體會(huì)SAE如何幫助微服務(wù)應(yīng)用降低資源成本。假設(shè)一個(gè)微服務(wù)系統(tǒng)包含87個(gè)應(yīng)用實(shí)例，每個(gè)時(shí)間每天的平均運(yùn)行時(shí)長為8小時(shí)，實(shí)例的配置為2 Core + 4 GiB + 20 G磁盤。
1、 使用包年包月的ECS部署應(yīng)用：需要購買87臺(tái)計(jì)算型c5，單臺(tái)的月成本為186元，每月總成本16146元。
2、 使用按量付費(fèi)的ECS部署應(yīng)用：單臺(tái)價(jià)格為0.63元/小時(shí)，每月累計(jì)使用20880小時(shí)，總成本13154元。
3、 使用SAE部署應(yīng)用：購買1個(gè)75000元的包年資源包，87個(gè)實(shí)例每天運(yùn)行8個(gè)小時(shí)，剛好把資源包額度用完，折合每月總成本6250元。

從這個(gè)對(duì)比我們可以得出，只要能夠合理的運(yùn)行SAE的彈性能力，就可以為微服務(wù)應(yīng)用大幅度降低資源成本。

附加能力

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

1、 完整的應(yīng)用生命周期管理：應(yīng)用托管至SAE后，可以對(duì)應(yīng)用執(zhí)行更新、擴(kuò)縮容、啟停、刪除、監(jiān)控啟停等應(yīng)用生命周期管理操作。
2、 開箱即用的注冊(cè)中心：SAE自帶商業(yè)版Nacos注冊(cè)中心，可以免費(fèi)使用，不需要自行搭建。如果有特殊的需求，比如讓部署在SAE的應(yīng)用和其他應(yīng)用相互發(fā)現(xiàn)，也可以使用微服務(wù)引擎（MSE）產(chǎn)品提供的注冊(cè)中心，或者自建的注冊(cè)中心。
3、 開箱即用的配置管理中心：SAE集成了ACM（Application Configuration Management，應(yīng)用配置管理）中的配置管理功能，可以在SAE中使用ACM對(duì)應(yīng)用配置進(jìn)行集中管理。
4、 應(yīng)用級(jí)流量防護(hù)：SAE集成AHAS實(shí)現(xiàn)應(yīng)用級(jí)別的流控與降級(jí)能力，全面保障應(yīng)用的高可用性。
5、 監(jiān)控能力：應(yīng)用托管到SAE以后，可以免費(fèi)獲得基礎(chǔ)資源（包括CPU、內(nèi)存、負(fù)載和網(wǎng)絡(luò)）以及應(yīng)用層（包括JVM分析、接口調(diào)用分析等方面）的監(jiān)控能力。如果需要更高級(jí)的SQL分析、異常分析、鏈路上下游和接口快照，可以集成阿里云應(yīng)用時(shí)間監(jiān)控產(chǎn)品（ARMS）。
6、 CI/CD集成能力：SAE與云效、云效2020、Jenkins等產(chǎn)品進(jìn)行了深入集成，可以方便開發(fā)者將構(gòu)建好的應(yīng)用快速部署。

多語言支持

對(duì)于非Java語言編寫的應(yīng)用，或者沒有使用Spring Cloud等微服務(wù)框架的Java應(yīng)用，SAE能不能完美支持，并幫助企業(yè)降低資源成本呢？當(dāng)然是可以的。SAE提供容器鏡像部署方式，這就代表著不管采用哪種編程語言，只要最終的應(yīng)用能夠發(fā)布成容器鏡像，就可以部署在SAE上。

對(duì)于Java系的微服務(wù)應(yīng)用，Java系統(tǒng)的普通應(yīng)用，以及非Java系應(yīng)用而言，SAE的極致彈性能力并沒有本質(zhì)的區(qū)別，都能通過Serverless技術(shù)提供系統(tǒng)的資源利用率。只不過SAE提供的一些附加價(jià)值，比如免費(fèi)的微服務(wù)注冊(cè)中心，就只能為Spring Cloud或Dubbo應(yīng)用服務(wù)罷了。

總結(jié)

讓我們用這張圖回顧Serverless技術(shù)的巨大價(jià)值：

常見問題

1、 問：應(yīng)用實(shí)例沒有固定的機(jī)器資源，連固定的ip地址都沒有，如何SSH到一臺(tái)服務(wù)器排查問題？
答：并不需要有固定的機(jī)器資源和固定的IP地址才能排查問題，在云計(jì)算時(shí)代，通過SSH登錄到一臺(tái)機(jī)器排查問題的方式并不是一個(gè)好的實(shí)踐。相反，SAE提供了完善的監(jiān)控能力，還可以方便的與云監(jiān)控、ARMS等新一代監(jiān)控診斷類產(chǎn)品進(jìn)行了集成，為排查故障提供了更大的便利。當(dāng)然，如果一定要登錄到某一臺(tái)機(jī)器，SSH依然是可以支持的，也可以利用SAE提供的Webshell工具簡化這個(gè)流程。

2、 問：磁盤不是計(jì)費(fèi)的維度嗎？應(yīng)用需要大容量磁盤怎么辦？應(yīng)用重啟后碰盤中的數(shù)據(jù)還保留嗎？
答：在微服務(wù)領(lǐng)域，應(yīng)用一般是無狀態(tài)（Stateless）的，不需要保存大量的本地?cái)?shù)據(jù)。如果在特殊的場景下離不開這個(gè)需求，可以集成NAS，使用集中式的存儲(chǔ)實(shí)現(xiàn)。

3、 問：應(yīng)用的日志怎么查看？
答：SAE控制臺(tái)界面提供了對(duì)于文件日志的實(shí)時(shí)查閱能力，相當(dāng)于免費(fèi)提供了一個(gè)分布式日志采集平臺(tái)。當(dāng)然強(qiáng)烈建議接入阿里云日志服務(wù)（SLS）產(chǎn)品，更進(jìn)一步的發(fā)揮應(yīng)用日志的價(jià)值。

阿里云專門成立了“互聯(lián)網(wǎng)架構(gòu)升級(jí)實(shí)戰(zhàn)課”釘釘群，每周都有阿里云專家在群內(nèi)進(jìn)行行業(yè)最佳實(shí)踐直播，每天分享前沿干貨，歡迎掃碼或釘釘搜索群號(hào)加入：35712134。

原文鏈接：https://developer.aliyun.com/article/775649?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的通过Serverless技术降低微服务应用资源成本的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。