前言
在大型分佈式 IT 架構領域，微服務是一項必不可少的技術。從本質上來說，微服務是一種架構風格，將一個大型的系統拆分爲多個擁有獨立生命週期的應用，應用之間採用輕量級的通訊機制進行通訊。這些應用都是圍繞具體業務進行構建，能夠獨立部署、獨立迭代，也可能根據業務負載獨立進行水平擴展。前端
微服務思想以及相關的技術爲 IT 架構的發展帶來了一系列深入的變革：shell
**易於開發和維護：**一個應用只會關注一組特定的業務功能，經過服務拆分，能減小應用之間的耦合度，讓開發和維護更加簡單。編程
**技術棧不受限制：**在微服務架構中，能夠結合項目業務及團隊的特色，合理的選擇技術棧。安全
**加快系統演進速度：**每個應用均可以獨立的進行版本更新，經過灰度發佈等技術手段能確保發佈過程當中整個系統穩定運行。服務器
**突破性能瓶頸：**每一個應用都能獨立的水平伸縮，使系統性能能夠根據計算資源的增長而獲得線性的擴展。網絡
微服務的挑戰
世上沒有免費的午飯，微服務技術讓 IT 系統變得更敏捷、更健壯、更高性能的同時，也帶來了架構複雜度的提高。對於開發者而言，要想更好的駕馭微服務架構，須要解決持續集成、服務發現、應用通訊、配置管理、流量防禦等一系列難題。幸運的是，針對這些廣泛存在的難題，業界涌現了一系列優秀的開源技術組件和工具，讓開發者能夠更輕鬆的構建微服務應用。像 Spring Cloud 和 Dubbo 這樣的技術框架，通過多年的發展，已經演化爲微服務領域的通用標準，極大地下降了微服務的門檻，但這些技術框架依然沒有辦法解決其中兩個最大的挑戰，這兩個挑戰成爲擺在開發者面前的兩座大山。架構
挑戰一：亟需完善的生命週期管理與服務治理方案
在一個頻繁迭代的系統中，每一個應用會常常性面臨新版本發佈需求，須要對應用的上線、下線、更新、回滾等流程進行集中性的管理，並配合精細粒度的灰度發佈手段，減小版本迭代對業務形成的影響。負載均衡
在一個簡單的微服務架構中，若是某應用處於整個鏈路的入口位置，它的前端通常會掛上負載均衡組件（上圖中的應用 A），以承接來自於最終用戶的業務請求。這類應用在進行生命週期管理的時候，複雜度會更高，爲了確保應用在新版本發佈過程當中的平衡穩定，會通過以下的步驟：框架
在這個流程中，尚未涉及到對於流量精細粒度控制的高級灰度方案，但已經足夠體現出其複雜性和操做難度了。若是僅僅依賴於簡單的發佈腳本進行管理，不但效率很低，還很容易致使顧此失彼，對系統穩定性形成巨大的風險。less
挑戰二：亟需完善的水平擴容與縮容方案
當某一個應用的性能出現瓶頸，須要經過增長實例數量來提高性能的時候，就須要引入新的計算資源。
新的計算資源從何而來呢？
對於線下 IDC 而言，計算資源是須要預先規劃的，擴容並非一件簡單的事情，可能會由於各類條件的制約而致使擴容沒法實現。固然這種困擾在雲計算時代不復存在了，爲一個應用擴充計算資源是信手拈來的事情，但光有計算資源是不夠的，還得在上面部署應用，並將應用容納到微服務體系中。
根據這個流程，若是須要擴容一個應用實例，保守估計也須要 20 分鐘以上，其中購買、系統初始化、應用部署都須要佔用大量的時間。假設系統流量突增，須要在 2 分鐘以內緊急擴容，這個方案就無用武之地了。
一劑良藥：容器化技術
爲了解決這兩個難題，開發者們嘗試了各類各樣的方案，新的理念以及技術框架在過去的這五年層出不窮。在一輪輪的優勝劣汰下，以 Docker 爲表明的容器技術，在 Kubernetes 生態的支撐下，在業界成爲了主流，是構建雲原生（Cloud Native）應用的必備要素。容器化相關技術可以更大程序的挖掘雲計算的價值，在必定程度上幫助開發者解決這兩個難題。
在應用生命週期管理以及服務治理方面， Kubernetes 提供了比較完善的實現機制，經過構建 Deployment 資源，配合 proStop 和 postStart 腳本，能比較方便的實現滾動發佈以及應用的優雅上下線。雖然在灰度發佈的過程當中，依然沒有辦法直接對流量進行精細粒度控制（引入 Service Mesh 技術能加強流量控制力，不在本文討論範圍），但相比簡單的發佈腳本，已經有了飛躍性的提高。
在應用的水平擴容與縮容方面，經過容器化技術能夠極大程度的減小操做系統安裝以及系統級初始化的時間，但購買虛擬機的操做是沒法避免的，因此在系統遇到流量增突的時候，依然沒有辦法實現快速水平擴容。咱們能夠預留一部分計算資源，放在資源池中，當應用有擴容需求的時候，就向資源池申請資源，當業務負載降低的時候，再把多餘的計算資源歸還到資源池中。
這其實並非一個好主意，每個計算資源都是須要成本的，資源池雖然可以解決計算資源快速投入使用的問題，卻形成了巨大的浪費。另外，到底規劃多大的資源池，也是一件很傷腦筋的事情，池子越大，形成的浪費就越大，但池子過小，又可能知足不了擴容的需求。
資源成本更深層次的分析
可能有的開發者會認爲，目前的業務運行很是的穩定，在用戶流量上並不存在明顯的突增，因此擴容和縮容是一個僞需求，在未來也不會有這樣的需求。這多是對互聯網業務的一種誤解，由於徹底沒有擴容需求的狀況是不存在的。
首先，只要一個系統是爲人服務的，就必然存在波峯和波谷。對於一個 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）可否零改形成本，或者接近零改形成本； （2）可否適配全部的業務場景。
應用層 Serverless 技術
是否有一種介於 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 的極致彈性能力
除了手動的擴縮容指令，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 帶來的紅利，這一次，咱們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。點擊連接便可免費學習課程：https://developer.aliyun.com/learning/roadmap/serverless
Serverless 公衆號，發佈 Serverless 技術最新資訊，聚集 Serverless 技術最全內容，關注 Serverless 趨勢，更關注你落地實踐中的遇到的困惑和問題。