本文作者：
山獵，阿裡雲智能技術專家，13年IT領域行業經驗，對網際網路雲原生架構以及大規模分布式技術有着深入了解，實戰經驗豐富，多次幫助阿裡雲的行業客戶對系統架構完成全面的雲原生改造。
前言
在大型分布式IT架構領域，微服務是一項必不可少的技術。從本質上來講，微服務是一種架構風格，将一個大型的系統拆分為多個擁有獨立生命周期的應用，應用之間采用輕量級的通信機制進行通信。這些應用都是圍繞具體業務進行建構，可以獨立部署、獨立疊代，也可能根據業務負載獨立的水準擴充。微服務思想以及相關的技術為IT架構的發展帶來了一系列深刻的變革：
1、 易于開發和維護：一個應用隻會關注一組特定的業務功能，通過服務拆分，能減少應用之間的耦合度，讓開發和維護更加簡單。
2、 技術棧不受限制：在微服務架構中，可以結合項目業務及團隊的特點，合理的選擇技術棧。
3、 加快系統演進速度：每一個應用都可以獨立的進行版本更新，通過灰階釋出等技術手段能確定釋出過程中整個系統穩定運作。
4、 突破性能瓶頸：每個應用都能獨立的水準伸縮，使系統性能可以根據計算資源的增加而得到線性的擴充。
微服務的挑戰
世上沒有免費的午餐，微服務技術讓IT系統變得更靈活、更健壯、更高性能的同時，也帶來了架構複雜度的提升。對于開發者而言，要想更好的駕馭微服務架構，需要解決持續內建、服務發現、應用通信、配置管理、流量防護等一系列難題。幸運的是，針對這些普遍存在的難題，業界湧現了一系列優秀的開源技術元件和工具，讓開發者可以更輕松的建構微服務應用。像Spring Cloud和Dubbo這樣的技術架構，經過多年的發展，已經演化為微服務領域的通用标準，極大地降低了微服務的門檻，但這些技術架構依然沒有辦法解決其中兩個最大的挑戰，這兩個挑戰成為擺在開發者面前的兩座大山。
挑戰一
亟需完善的生命周期管理與服務治理方案：在一個頻繁疊代的系統中，每個應用會經常性面臨新版本釋出需求，需要對應用的上線、下線、更新、復原等流程進行集中性的管理，并配合精細粒度的灰階釋出手段，減少版本疊代對業務造成的影響。
在一個簡單的微服務架構中，如果某應用處于整個鍊路的入口位置，它的前端一般會挂上負載均衡元件（上圖中的應用A），以承接來自于最終使用者的業務請求。這類應用在進行生命周期管理的時候，複雜度會更高，為了確定應用在新版本釋出過程中的平衡穩定，會經過如下的步驟：
在這個流程中，還沒有涉及到對于流量精細粒度控制的進階灰階方案，但已經足夠展現出其複雜性和操作難度了。如果僅僅依賴于簡單的釋出腳本進行管理，不但效率很低，還很容易導緻顧此失彼，對系統穩定性造成巨大的風險。
挑戰二
亟需完善的水準擴容與縮容方案：當某一個應用的性能出現瓶頸，需要通過增加執行個體數量來進行性能提升的時候，就需要引入新的計算資源。新的計算資源從何而來呢？
對于線下IDC而言，計算資源是需要預先規劃的，擴容并不是一件簡單的事情，可能會因為各種條件的制約而導緻擴容無法實作。當然這種困擾在雲計算時代不複存在了，為一個應用擴充計算資源是信手拈來的事情，但光有計算資源是不夠的，還得在上面部署應用，并将應用容納到微服務體系中。
根據這個流程，如果需要擴容一個應用執行個體，保守估計也需要20分鐘以上，其中購買、系統初始化、應用部署都需要占用大量的時間。假設系統流量突增，需要在2分鐘之内緊急擴容，這個方案就無用武之地了。
一劑良藥：容器化技術
為了解決這兩個難題，開發者們嘗試了各種各樣的方案，新的理念以及技術架構在過去的這五年層出不窮。在一輪輪的優勝劣汰下，以Docker為代表的容器技術，在Kubernetes生态的支撐下，在業界成為了主流，是建構雲原生（Cloud Native）應用的必備要素。容器化相關技術能夠更大程式的挖掘雲計算的價值，在一定程度上幫助開發者解決這兩個難題。
在應用生命周期管理以及服務治理方面，Kubernetes提供了比較完善的實作機制，通過建構Deployment資源，配合proStop和postStart腳本，能比較友善的實作滾動釋出以及應用的優雅上下線。雖然在灰階釋出的過程中，依然沒有辦法直接對流量進行精細粒度控制（引入ServiceMesh技術能增強流量控制力，不在本文讨論範圍），但相比簡單的釋出腳本，已經有了飛躍性的提升。
在應用的水準擴容與縮容方面，通過容器化技術可以極大程度的減少作業系統安裝以及系統級初始化的時間，但購買虛拟機的操作是無法避免的，是以在系統遇到流量增突的時候，依然沒有辦法實作快速水準擴容。
我們可以預留一部分計算資源，放在資源池中，當應用有擴容需求的時候，就向資源池申請資源，當業務負載下降的時候，再把多餘的計算資源歸還到資源池中。
這其實并不是一個好主意，每一個計算資源都是需要成本的，資源池雖然能夠解決計算資源快速投入使用的問題，卻造成了巨大的浪費。另外，到底規劃多大的資源池，也是一件很傷腦筋的事情，池子越大，造成的浪費就越大，但池子太小，又可能滿足不了擴容的需求。
資源成本更深層次的分析
可能有的開發者會認為，目前的業務運作非常的穩定，在使用者流量上并不存在明顯的突增，是以擴容和縮容是一個僞需求，在将來也不會有這樣的需求。這可能是對網際網路業務的一種誤解，因為完全沒有擴容需求的情況是不存在的。
首先，隻要一個系統是為人服務的，就必然存在波峰和波谷。對于一個7*24小時運作的系統，不可能永遠保持同樣的使用者流量，二八原則對于很多業務系統依然适用（80%的使用者流量集中在20%的時間段。即便是使用者流量相對平衡的系統，在淩晨也存在流量的低谷，如果能更進一步的釋放閑置計算資源，提升資源使用率，就能顯著的降低資源使用成本。
另外，相比生産環境，開發和測試環境對于擴容和縮容的需求會更加迫切。一套微服務應用由不同的團隊進行開發，在理想的情況下，多個團隊會共享一套測試環境：
然而，每個團隊對于應用的疊代都會有自己的節奏，與此同時，他們又想擁有獨立的端到端測試環境，進而實作環境之間的隔離，以避免團隊之間的互相影響。這樣的話，很有可能會形成多套測試環境：
随着應用、團隊、業務功能點數量的增加，所需要的開發測試環境數量還會成倍的增長，造成巨大的資源浪費。對于測試環境的計算資源而言，資源使用率要遠低于生産環境。有的時候僅僅是一個簡單功能點的驗證，為了端對端的跑通業務功能，又避免團隊之間的互相影響，就會開啟一套包括全部微服務應用的新環境。這樣的資源浪費，對于很多企業，都是一個多年都未曾得到解決的難題。
是以，微服務架構在本質上就是對彈性伸縮有着強烈訴求的，在彈性伸縮的過程中，不管是單應用的水準彈性伸縮，還是整套環境的啟停，資源使用率都對最終的資源成本起着決定性的作用。如果能想辦法提升資源使用率，就能為企業節省大量資源成本。值得我們重視的是，絕大多數的微服務應用的資源使用率都是非常低的。我們可以做一個簡單的統計：把所有伺服器的CPU使用率每5分鐘導出一次，按照天的次元求平均值，就能從整體上了解系統的資源使用率資料。如果把開發測試環境的伺服器資源也納入統計的範圍，資源使用率很有可能會更低。
Serverless化探索
資源使用率低的根本原因，在于以伺服器為載體的應用架構中，開發者需要将建構好的程式包部署到伺服器上，進而對多個使用者事件進行響應。為了確定事件響應的及時性，需要讓程式長駐于伺服器上，而且盡可能保守的規劃資源，以避免出現負載過重而導緻服務崩潰的情況。在這個過程中，實際的負載在時間上配置設定并不均衡，進而導緻整體的資源使用率偏低。
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、 能否0改造成本，或者接近0改造成本。
2、 能否适配所有的業務場景。
應用層Serverless技術
是否有一種介于FaaS和Serverless化容器之間的技術，可以實作上述重要訴求呢？當然有，這就是以阿裡雲Serverless應用引擎（SAE）為代表的應用層Serverless技術。
圖：不同層級的Serverless技術
SAE實作了Serverless 架構 + 微服務架構的完美融合，對于Spring Cloud和Dubbo等主流的微服務架構，可以實作無縫相容，基本上沒有改造成本，并真正按需使用、按量計費，節省閑置計算資源，同時免去 IaaS層運維方面的工作，有效提升開發運維效率。
以Spring Cloud應用為例，如果需要部署一個新的應用，隻需要2個步驟：
1、 告訴SAE這個應用需要多少個執行個體，并指定每個執行個體需要的CPU/記憶體規格。
2、 上傳應用的JAR包/WAR包，并啟動應用。
我們發現，這2個步驟中并不涉及容量評估、伺服器購買、作業系統安裝、資源初始化等工作，就能讓包含多個對等執行個體的微服務應用運作起來。這是因為在Serverless的世界中，不再具有伺服器資源這樣的概念，應用的載體是SAE排程出來的沙箱容器，每個執行個體隻有在真正投入使用後，才會按使用時長進行計費。
對于開發者而言，他們不用關心應用到底部署在實體機裡面，還是虛拟機裡面，或是容器裡面，也不需要知道底層的作業系統是什麼版本的，隻需要關注每個應用執行個體占據多少運算資源就可以了。如果應用需要從4個執行個體擴容到6個執行個體，或者縮容到2個執行個體，隻需要一個指令就可以完成，甚至與SLB的綁定關系，都可以自動的建立或解除，這是Serverless技術為開發者帶來的巨大價值。
使用SAE部署微服務應用，因為隻是變更了應用運作的載體，是以可以100%的相容現有的技術架構和業務功能，遷移成本可以忽略不計。
SAE的極緻彈性能力
除了手動的擴縮容指令，SAE還支援2種自動彈性機制，可以對微服務應用進行靈活的水準擴充，更進一步的發揮雲計算的彈性能力。
1、 定時彈性機制：對于會預期發生的周期性行為，可以設定定時彈性政策。舉例：如果每天的上午9點是業務高峰，可以定時每天8點半增加執行個體數量，并在9點半減少執行個體數量。
2、 基于名額門檻值的彈性機制：對于超出預期的業務流量突增，可以設定基于名額門檻值的彈性政策，根據CPU、記憶體等資源名額，以有QPS等業務名額讓應用實作自動的彈性縮。
通過多種彈性機制，能夠對系統容量進行精細粒度的管理，使資源的使用量能随着業務流量的變化而調整，進而極大程度的增加資源使用率，大幅降低資源成本。
在計算資源的排程和啟動上，SAE做了多項優化，對于擴容出來的新執行個體，隻需要幾秒鐘的時間就能拉起，這項能力對于一些需要緊急快速擴容的突發場景，是具有重大意義的。
對于開發測試環境而言，SAE的機制彈性能力能展現得更加淋漓盡緻，得益于SAE出色的資源排程能力，可以一鍵啟停一整套微服務應用。即便僅對一項簡單的新功能進行冒煙測試，也完全可以新啟一套完整而隔離的測試環境來進行。新的環境可以在秒級搭建完成，快速投入使用，而測試完畢後，又可以立即釋放。從成本上來講，一套新環境實際投入使用的時間很短，是以隻會消耗極少的費用。這對于微服務應用開發過程中的多團隊協作，是一個巨大的變革。
成本分析
SAE通過資源的實際使用量來付費，費用由兩部分組成，每部分根據統計結果和計算方式進行費用結算，按小時出賬單扣款。每個應用使用的資源計量方式如下所示：
1、 應用CPU資源使用量=∑執行個體CPU規格×本月運作時長（以分鐘計），即應用中所有執行個體的CPU規格乘以本月運作時長的總和。
2、 應用記憶體資源使用量=∑執行個體記憶體規格×本月運作時長（以分鐘計），即應用中所有執行個體的記憶體規格乘以本月運作時長的總和。
其中CPU部分的價格為0.0021605元/分鐘/Core，記憶體部分的價格為0.0005401元/分鐘/GiB。SAE還提供預付費資源包，相當于批發的方式預購計算資源，隻要能要有效期内消耗完，就能更進一步的節省使用成本，當資源包扣完以後，系統會自動變更為按量付費的模式。
讓我們通過一個實際案例來進一步體會SAE如何幫助微服務應用降低資源成本。假設一個微服務系統包含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技術為開發者帶來的額外價值，我們可以盡可能的利用這些開箱即用的功能，讓建設微服務應用變成更加簡單。
1、 完整的應用生命周期管理：應用托管至SAE後，可以對應用執行更新、擴縮容、啟停、删除、監控啟停等應用生命周期管理操作。
2、 開箱即用的注冊中心：SAE自帶商業版Nacos注冊中心，可以免費使用，不需要自行搭建。如果有特殊的需求，比如讓部署在SAE的應用和其他應用互相發現，也可以使用微服務引擎（MSE）産品提供的注冊中心，或者自建的注冊中心。
3、 開箱即用的配置管理中心：SAE內建了ACM（Application Configuration Management，應用配置管理）中的配置管理功能，可以在SAE中使用ACM對應用配置進行集中管理。
4、 應用級流量防護：SAE內建AHAS實作應用級别的流控與降級能力，全面保障應用的高可用性。
5、 監控能力：應用托管到SAE以後，可以免費獲得基礎資源（包括CPU、記憶體、負載和網絡）以及應用層（包括JVM分析、接口調用分析等方面）的監控能力。如果需要更進階的SQL分析、異常分析、鍊路上下遊和接口快照，可以內建阿裡雲應用時間監控産品（ARMS）。
6、 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）産品，更進一步的發揮應用日志的價值。
阿裡雲專門成立了“網際網路架構更新實戰課”釘釘群，每周都有阿裡雲專家在群内進行行業最佳實踐直播，每天分享前沿幹貨，歡迎掃碼或釘釘搜尋群号加入：35712134。