作者： Q Si.
微服務架構充分提公升了研發效率，解決了複雜業務系統快速迭代的問題。 然而，隨著業務和技術的發展，各種微服務元件變得更加複雜。 如何實現更敏捷的開發，降低微服務開發和運維成本，實現全鏈路柔性，保證整個系統的穩定性，還存在諸多挑戰。
例如，在沒有統一的規範或多個開發團隊之間的協作下，微服務元件和SDK的版本會出現不一致，但考慮到版本相容性和公升級範圍等因素，很多使用者不敢公升級，埋藏隱患。 在規劃容量時，您很難根據業務量評估合適的資源需求，且使用大規模例項的成本過高，小規模規格的流量突增會影響穩定性。 如果業務是由ISV開發的，在專案交付驗收後，一些基礎元件的運維職責不明確，如果沒有專業的巡檢、監控和告警機制，很容易造成線上故障。
Serverless技術作為微服務架構演進的一大趨勢，可以最大化地利用技術紅利和資源利用率來解決上述問題。 它使開發人員能夠專注於業務實現，而不必擔心底層伺服器在哪裡、資源是否充足以及何時進行擴充套件或公升級。
在研發協作和迭代效率方面，微服務本身具有高度的內聚性和可重用性，並且通過無伺服器基礎設施，它們可以公升級為可組合的研發。 同時，使用者可以通過微服務治理的全鏈路流量控制能力，快速構建邏輯隔離的日常環境，在節省資源成本的同時，將開發測試環境的構建時間從幾天縮短到幾分鐘，大大解放了開發者的生產力。 對於閘道器、註冊中心和配置中心、MQ、資料庫、Redis快取等基礎元件，通過資源冗餘來保證其穩定性顯然是不經濟的。
使用Serverless雲產品，您可以快速實現全鏈路資源彈性，享受自動公升級等免運維能力。 這些基礎元件以服務形式提供，因此開發人員無需陷入複雜的配置整合中，而需要專注於開發任務。 對於業務端來說，即使ISV交付專案並退出後，也無需擔心基礎元件的運維、技術備份、穩定性保障等問題。
順應這一技術趨勢，阿里雲MSE在微服務行業率先推出Serverless版本。 它有三大功能亮點首先是適應性彈性雲原生閘道器和註冊配置中心可根據業務量自動擴容或縮容，無需複雜的容量規劃。 對於註冊中心配置中心來說，其資源消耗與服務提供者數量、客戶端連線數量、TPS等幾個因素有關。 然而，有些指標很難提前觀察和規劃。 閘道器作為關鍵的流量入口，可以提供日常業務流量，但很難判斷計畫外流量。 通過雲服務的自適應彈性，可以保證整個技術架構的穩定性和成本的可控性。
第二點是開箱即用的免運維大大減輕使用者的運維負擔。 MSE將例項變更、節點啟動和關閉、應用上下線、當前限流等關鍵事件彙總到註冊配置中心、雲原生閘道器、服務治理等統一檢視中，方便問題分析和排查。 MSE Serverless例項在使用者自定義的運維週期內進行預檢查和自動公升級。 它既保證了元件是最新的穩定版本，又免除了使用者對相容性或業務流量影響的擔憂。 此外，很多使用者缺乏配置告警規則的意識或經驗，MSE Serverless 例項也支援預設的告警配置，當發生一些嚴重事件時，會第一時間通知使用者並及時介入。
最後但同樣重要的MSE Serverless 計費與業務量相關聯，閾值較低。 普通例項是按照固定規格收費的，對於創業初期或者非高峰期的小企業來說，其實會浪費資源。 MSE註冊配置中心Serverless按客戶端連線數計費，雲原生閘道器Serverless按請求計費，為測試環境、潮汐服務、中小企業節省大量成本。
如果要構建全棧、高彈性的微服務架構，需要權衡各元件的擴容難易程度、擴容速度和業務負載的變化率。 如果您使用MSE Serverless Edition，並結合其他阿里雲產品的能力，就可以輕鬆實現上述目標。 如下圖所示，使用者流量通過NLB進入雲原生閘道器的Serverless例項，並路由到部署在ACK或SAE上的應用，整個鏈路上的產品都具備自適應彈性能力。
隨著業務流量的增加，應用副本數量也會隨之增加，訪問註冊中心和配置中心的連線數和 TPS 也會隨之增加，Nacos 和 ZooKeeper Serverless 例項也會相應地自動擴縮容。 對於服務治理，它是應用級的按需訪問，當SAE或ACK上的應用開啟服務治理時，擴充套件的應用副本會自動享受服務治理能力。 目前，阿里雲已推出20多款Serverless產品，並將持續推廣全面的Serverless核心產品。 通過無伺服器雲服務，使用者可以構建整體高彈性、低成本的微服務架構。
下面通過乙個測試案例，展示雲原生閘道器Serverless例項如何與ACK容器集群配合使用，利用日誌中的QPS指標和容器HPA機制，實現基於請求量的整體伸縮。
對於部署在容器集群中的應用工作負載，我們建立乙個 HPA 資源，設定最小和最大副本數，將 QPS 定義為指標，並在每個副本的平均 QPS 達到 50 時觸發伸縮。
執行壓力測試工具 10 分鐘後，傳送到閘道器的請求數從 400 TPS 增加到 4000+ TPS。 可以看到，所有壓力測試請求都是 100% 成功的，平均 RT 保持在 9 10 毫秒的水平。 事實上，容器集群中的閘道器服務和應用副本是自動擴容的，整個過程對使用者完全透明，服務不知情。
雖然MSE無伺服器有很多優點，但也要根據場景來選擇這裡我們列舉了功能和適用場景的異同。 在高可用性方面，兩款例項均支援多節點集群的多可用區部署，SLA略有不同。 在運維方面，需要手動公升級普通例項的版本，關注底層資源監控指標，達到閾值時及時手動更改配置。 Serverless例項會自動公升級和擴充套件，因此您無需進行複雜的容量規劃、手動更改配置，也無需擔心對 CPU、記憶體等資源進行監控和告警。
對於雲原生閘道器，普通例項支援的通訊協議和身份驗證種類稍多，並具有硬體加速和擴充套件能力。 Serverless例項還支援主流協議和認證方式，可以滿足大部分使用者需求。
綜上所述，Serverless 例項更面向中小型企業、間歇性潮汐場景和測試環境。 使用者希望免運維，更簡單地使用後端服務。 常見的例項適用於希望控制部分運維工作，並具有更多自主性和可擴充套件性要求的使用者。
無論是自建例項還是普通例項，一般都是根據高業務負載購買規格，並支付固定資源費用。 這樣一來，低谷期浪費了更多的資源，整體成本也更高。 如果出現意外的大量業務流量，資源不足會造成業務損失。 Serverless例項可以快速獨立地擴容和縮容，快速響應業務變化，合理優化使用成本，幫助企業降本增效。
註冊配置中心中的Serverless例項按照客戶端到伺服器的總連線數計費，每10個連線計費單位，階梯式計費，按小時計費，如下圖所示。 假設使用者業務量穩定，如折線圖所示，橙線代表Serverless例項的月度價格，藍線代表普通例項專業版集群的月度價格。 如果每小時連線數不超過10個，則Server例項的月費為115元。 即使業務量達到 50 連線，也低於 Nacos 或 ZooKeeper 開源自建的成本。 在100個連線數以內，Serverless例項比普通例項便宜，因此更適合中小型企業。
雲原生閘道器Serverless例項統計每小時處理的請求數，每10000個請求計費單位，階梯定價，按小時計費，如下圖所示。 假設使用者業務量穩定，如折線圖所示，橙色線代表Serverless例項的月度價格，藍色線代表普通例項集群的月度價格。 每小時累計請求數小於50000次，Serverless例項成本低於開源自建，成本小於200000次請求，低於普通例項。
以上假設業務量較小，維持在一定水平，此外，對於間歇和潮汐場景，Serverless 的累計成本也較低。 如下圖所示，如果業務量在10小時內發生明顯變化，則開始時每小時的請求數為20萬到30萬，峰值為每小時200萬，然後逐漸下降。 對於閘道器作為關鍵入口點，普通例項需要預留資源，以保證能夠支援 200 萬請求的峰值。 但是，對於無伺服器例項，其成本會隨著業務量而變化。 雖然無伺服器例項的每小時成本在高峰時段較高，但很明顯，當整個時間段的成本相加時，成本會更高。
MSE Serverless Edition 於 11 月 17 日正式商用，並推出相應的節省計畫，允許使用者承諾每天一定消費量，按照註冊配置中心和雲原生閘道器 Serverless 例項的每日費用進行預付費用，並可享受 2% 至 95% 不等的扣除。 可以進一步降低使用者的長期使用成本。每月消費不到100元，即可享受K8S Ingress、微服務閘道器、安全閘道器三合一的雲原生閘道器，或者穩定、安全、免維護的註冊配置中心，快來搭建你的Serverless微服務架構吧
相關鏈結：
MSE Serverless 例項簡介：
註冊和配置中心中的例項和版本選擇
註冊配置中心無伺服器例項計費概述：
雲原生閘道器例項選擇：
雲原生閘道器Serverless例項計費概述：