基於 Serverless 的雲原生轉型實踐

雲原生架構是什麼

回顧過去十年，數字化轉型驅動着技術創新和商業元素的不斷融合和重構，能夠說，如今已經不是由商業模式決定採用何種技術架構，而是由技術架構決定企業的商業模式。因此不管是行業巨頭仍是中小微企業都面臨着數字化轉型帶來的未知機遇和挑戰。機遇是商業模式的創新，挑戰來自對總體技術架構的變革。

新一代的技術架構是什麼？如何變革？是不少互聯網企業面臨的問題。而云原生架構則是這個問題最好的答案，由於雲原生架構對雲計算服務方式與互聯網架構進行總體性升級，深入改變着整個商業世界的 IT 根基。

雖然雲原生的概念由來已久，不少人並不理解什麼是雲原生。從技術的角度來說，雲原生架構是基於雲原生技術的一組架構原則和設計模式的集合，旨在將雲應用中的非業務代碼部分進行最大化的剝離，從而讓雲設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、 可觀測性、灰度等），使業務再也不受非功能性業務中斷困擾的同時，具有輕量、敏捷、高度自動化的特色。簡單的說，就是幫助企業的業務功能迭代更快、系統能承受住各類量級的流量衝擊的同時，構建系統的成本更低。

傳統架構與雲原生架構的區別

上圖展現了在代碼中一般包括的三部份內容，即業務代碼、第三方軟件、處理非功能特性的代碼。其中「業務代碼」指實現業務邏輯的代碼。「三方軟件」是業務代碼中依賴的全部三方庫，包括業務庫和基礎庫。「處理非功能性的代碼」指實現高可用、安全、可觀測性等非功能性能力的代碼。

這三部分中只有業務代碼是對業務真正帶來價值的，另外兩個部分都只算附屬物，但隨着軟件規模的增大、業務模塊規模變大、部署環境增多、分佈式複雜性加強，使得今天的軟件構建變得愈來愈複雜，對開發人員的技能要求也愈來愈高。雲原生架構相比較傳統架構前進了一大步，即從業務代碼中剝離了大量非功能性特性到 IaaS 和 PaaS 中，從而減小業務代碼開發人員的技術關注範圍，經過雲服務的專業性提高應用的非功能性能力。

這即是雲原生架構的核心思路。

爲何須要雲原生架構

解釋完什麼是雲原生架構後，你們可能會有進一步的思考，即當今互聯網企業爲何須要雲原生架構。分析下SaaS的市場規模能夠發現，2019年SaaS市場規模爲360億元，2020年仍保持可觀上漲趨勢，2022年SaaS市場規模預計破千億。

縱觀中國企業級SaaS行業發展歷程，大致分爲四個階段：2015年以前，中國市場和絕大多數中國企業對「什麼是SaaS」缺少基本認知，基於私有部署的傳統軟件形式仍爲主流，企業級SaaS市場方興未艾。到了2015年，隨着雲計算技術的進一步成熟，中國企業級SaaS行業進入快速成長階段，這個慢賽道逐漸爲公衆所知。

時至今日，在疫情、經濟、社會環境的大背景下。互聯網企業開始尋求新的商業模式，一些抓住機會的SaaS企業實現了快速響應，結果是其業務呈現成倍增加，好比：

• 餐飲SaaS廠商幫助線下餐飲門店開發小程序點餐系統，實現無接觸點餐。
• 電商零售領域的ERP廠商幫助企業創建會員管 理系統。
• 營銷SaaS廠商經過流量平臺幫助企業在線營銷，遠程觸達客戶。

因此，在「如何活下去」成爲熱門議題的背景下，快速響應能力成爲企業之間的核心競爭優點，SaaS企業須要及時知足市場的新需求。而這正是前幾年中國SaaS企業爲了快速佔領市場、盲目跟風、一味借鑑國外產品所產生的天生缺陷。爲彌補這些缺陷，SaaS廠商須要根據市場的需求快速調整產品服務方向，業務功能要多元化，業務體系須要新的枝杈，在技術上也有更大的挑戰。

除了市場帶來的壓力，SaaS企業自身也有諸多痛點：

• 大多SaaS產品只作所謂的通用能力，或者只是一味模仿國外產品，一旦深刻到行業屬性比較重的場景時便沒法知足需求，因此被貼上了「半成品」的標籤，致使市場接受程度不如預期。
• 產品模塊單1、功能類似的SaaS產品很容易陷入價格競爭，最後只能以虧損得到網絡效應，但會終食惡果。
• 市場對SaaS產品的定製化需求過多，使得SaaS企業缺少對產品打磨的精力，把一個SaaS型公司作成了項目型公司。

SaaS企業解決以上的外憂內患的核心就是專一在業務。要作好一款SaaS產品，對於業務渠道、競爭格局、用戶體驗等諸多方面都有更加嚴苛的要求，甚至從市場運營、產品經理到研發、運維都要專一在業務，全部這些角色的本職工做都應該爲行業業務服務，行業的深度分析，快速響應市場，穩定的產品質量這些是必需要具有的。但這就要求技術具有更快的迭代速度，業務推出速度從按周提高到按小時，每個月上線業務量從「幾十 / 月」提高到「幾百 / 天」，而且不可接受業務中斷。

另外一個互聯網企業須要雲原生轉型的緣由是中國的劉易斯拐點已經到來。劉易斯拐點，即勞動力過剩向短缺的轉折點，是指在工業化進程中，隨着農村富餘勞動力向非農產業的逐步轉移，農村富餘勞動力逐漸減小，最終達到瓶頸狀態。用大白話說就是中國的人口紅利已經逐漸消退，企業勞動力成本不斷增長，加上2020年疫情的影響，成本因素愈來愈成爲企業的重要考量。而SaaS產品訂閱制付費、通用性強、低部署成本的特色，便成了企業降本增效的新選擇。這是SaaS企業在市場中的機會，並且對於SaaS企業自己來講，一樣有降本增效的需求，並且內部降本增效作得越好，SaaS產品在市場上的競爭力會更加明顯。

以上這些現狀的解法和雲原生架構和核心能力不謀而合：

• 雲原生將三方軟件和非功能性能力的徹底兜底，能夠極大程度解放企業研發、運維人員的精力，並使其能夠專一在業務上。
• 系統的橫向擴展性、高可用性、健壯性、SLA由雲原生架構兜底，解決了SaaS產品最忌諱的穩定性問題。
• 將一些自建的組件遷移至雲原生架構中，對傳統的部署方式和資源進行雲原生化，GitOps的落地，在資源成本和人力成本方面都有進一步的優化。

如何落地雲原生架構

在聊如何落地雲原生架構以前，咱們先來看一看雲原生架構成熟度模型（SESORA）：

雲原生架構成熟度模型

雲原生架構成熟度模型有六個評判維度，能夠將成熟度劃分爲4個級別。我會從自動化能力、無服務化能力、彈性能力、可觀測性、韌性能力這五個維度，貫穿說明如何落地雲原生架構。

傳統架構

上圖展現的是一個較傳統的Java+SpringCloud架構應用服務側的部署架構。除了SLB，基本上全部的組件都部署在ECS上。下面咱們來一塊兒看看如何將這個架構轉型爲雲原生架構。

無服務化（Serverless）

Serverless的概念是什麼在這篇文章不在贅述，能夠參閱這篇文章進行了解。使用ECS集羣部署服務的架構有兩個顯著的短板：

• 運維成本高：ECS的各項狀態、高可用都須要運維同窗維護。
• 彈性能力不足：每次有大促活動時，都須要提早購買ECS，擴展服務的節點數，而後再釋放，而且這種狀況只適用於定時定點的活動，若是是不定時的流量脈衝則沒法應對。

因此首先咱們要將服務的部署方式Serverless化，咱們能夠選擇Serverless App Engine（SAE）做爲服務應用的發佈、部署平臺。SAE是面向應用的Serverless PaaS平臺，可以幫助用戶免運維IaaS、按需使用、按量計費，作到低門檻服務應用雲原生化，而且支持多種語言和高彈性能力。

命名空間

打開SAE控制檯，咱們首先建立命名空間，SAE的命名空間能夠將其下的應用進行網絡和資源的邏輯隔離，一般咱們可以使用命名空間來區分開發環境、測試環境、預發環境、生產環境。

建立應用

建立好命名空間後，咱們進入應用列表，便可選擇不一樣的命名空間，看到其下的應用或者建立應用：

選擇對應的命名空間，而後建立應用：

• 應用名稱：服務名稱，用戶自行輸入。
• 專有網絡配置：
  • 自動配置：自動幫用戶配置VPC、Vswitch、安全組。這些組件都會新建立。
  • 自定義配置：用戶選擇命名空間，VPC，VSwitch以及安全組。通常選擇自定義配置，由於我們的服務所屬的VPC確定要和其餘雲資源的VPC是相同的，這樣才能保證網絡暢通。這裏須要注意的一點是，當在新的命名空間下第一次建立好應用後，該命名空間就會和所選的VPC進行綁定，以後再建立應用時，該命名空間對應的VPC不可更改。若是須要更改，能夠進入命名空間詳情進行更改。
• 應用實例數：應用（服務）節點數量，這裏的節點數量按需設置，並且不是最終設定，由於後續能夠手動或者自動的擴縮節點數。
• VCPU/內存：該應用在運行過程當中須要的CPU和內存的規格。這裏的規格是單個實例數的規格。既若是選擇了2C4G，那麼有2個實例的話，就是4C8G。

配置完基本信息後，下一步進入應用部署配置：

• 技術棧語言：Java語言支持鏡像、War包、Jar包三種部署方式，其餘語言支持鏡像部署方式。以Java Jar包方式爲例：
  • 應用運行環境：默認標準Java應用運行環境便可。
  • Java環境：目前支持JDK7和JDK8。
  • 文件上傳方式：支持手動上傳Jar包或者配置能夠下載Jar包的地址。
• 版本：支持時間戳和手動輸入。
• 啓動命令設置：配置JVM參數。
• 環境變量設置：設置容器環境中的一些變量，便於應用部署後靈活的變動容器配置。
• Host綁定設置：設置Host綁定，便於經過域名訪問應用。
• 應用健康檢查設置：用於判斷容器和用戶業務是否正常運行。
• 應用生命週期管理設置：容器側的生命週期腳本定義，管理應用在容器在運行前和關閉前的一些動做，好比環境準備、優雅下線等。
• 日誌收集服務：和SLS日誌服務集成，統一管理日誌。
• 持久化存儲：綁定NAS。
• 配置管理：經過掛載配置文件的方式向容器中注入配置信息。

我使用Jar包的方式部署完應用後，在對應命名空間下就能夠看到剛剛建立的應用了：

點擊應用名稱能夠查看應用詳情：

綁定SLB

由於ServiceA在架構中是對外提供接口的服務，因此須要對該服務綁定公網SLB暴露IP和作負載均衡，在SAE中，綁定SLB很是簡單，在詳情頁中，便可看到應用訪問設置：

添加SLB時能夠選擇新建也能夠選擇已經建立好的SLB：

服務/配置中心

對於微服務架構，服務中心和配置中心是必不可少的，你們經常使用到通常是Nacos、Eureka、ZooKeeper三種。對於雲原生架構來說，根據不一樣的場景，服務/配置中心能夠有如下幾種選擇：

對於現狀就是使用Nacos的客戶而言，轉型雲原生架構，服務/配置中心如上面表格所示有兩種選擇：

• 須要快速轉型，對服務/配置中心高可用要求不是特別極致的狀況下，建議直接使用SAE自帶的Nacos便可，代碼不須要作改動，直接在SAE中建立應用便可。SAE控制檯提供的配置管理在界面操做和功能上和開源Nacos的控制檯基本一致。

• 對服務/配置中心高可用要求比較高的狀況下，建議使用MSE Nacos，它的優點是獨享集羣，而且節點規格和節點數量能夠根據實際狀況動態的進行調整。惟一不足的一點就是須要修改Nacos的接入點，算是有一點代碼侵入。

對於現狀是使用Eureka和ZooKeeper的客戶而言，建議直接使用MSE Eureka和MSE ZooKeeper。

這裏我簡單介紹一下MSE。微服務引擎MSE（Microservice Engine）是一個面向業界主流開源微服務框架Spring Cloud和Dubbo一站式微服務平臺，提供治理中心、託管的註冊中心和託管的配置中心。這裏咱們用到的是MSE的託管註冊中心和託管配置中心。

MSE有三塊核心的功能點：

• 支持三大主流服務中心，節點規格和數量靈活搭配，可在運行時動態調整節點規格/數量。

• 經過命名空間邏輯隔離不一樣環境。

• 配置變動實時推送而且可追蹤。

彈性能力（Elasticity）

雲原生架構成熟度模型中的彈性能力一樣依託於SAE來實現，由於Serverless的底層實現原理，因此在SAE中的應用實例數（節點數）擴縮速度很是快，可達到秒級。

進入應用詳情頁的實例部署信息，能夠看到應用的具體實例：

SAE提供了兩種擴縮應用實例數的方式，手動方式和自動方式。

手動擴縮

在控制檯右上方有手動擴縮操做按鈕，而後選擇要擴縮到的實例數便可：

當進行擴縮時，咱們能夠看到具體實例的變動狀態：

自動擴縮

在控制檯右上角有自動擴縮操做按鈕，而後能夠看到建立擴縮規則的界面。SAE自動擴縮提供時間策略和指標策略兩種。

上圖是時間策略，即設置好具體的時間節點，在這個時間節點要將應用的實例數擴到幾個或者縮到幾個。這種策略適合流量高峯期有相對明確時間節點的場景，好比在線教育的客戶，一般流量高峯在晚上8點開始，11點逐漸結束，這種狀況下，經過定時策略在7點半左右把應用的實例數擴起來，而後11點以後逐漸把應用實例數縮回正常。

上圖是指標策略，目前提供CPU使用率、內存使用率、應用的QPS閥值、應用接口平均響應時間（RT）閥值四種指標，這四種指標能夠配合使用。當這四種指標其中有一種達到閥值後就會觸發擴容，會對應用實例進行逐漸擴容。當指標小於閥值後觸發縮容。這種策略適合流量高峯時間不固定的場景，好比市場營銷，遊戲運營。

成本優化

對於彈性能力，你們可能更多的是關注它能讓系統快速支撐流量脈衝，增長系統橫向擴展的能力。其實由於SAE有極致的彈性能力，再加上按分鐘、按量計費的模式，對總體的資源成本是有必定優化的。

可觀測性（Observability）

應用側的可觀測性分兩個維度，一是縱向的Metrics指標，好比主機的CPU、內存、磁盤各項指標，Pod的CPU、內存各項指標，JVM的Full GC、堆內存、非堆內存各項指標。另外一個維度是橫向的請求調用鏈路監測，上游服務到下游服務的調用、上游接口到下游接口的調用。

在監控微服務架構時，一般須要從三個角度來看：

• 應用的總體健康情況。
• 應用每一個實例的健康情況。
• 應用每一個接口的健康情況。

而SAE對應用的監控也都覆蓋了上述這兩個維度和三個角度。

應用總體健康情況

進入應用詳情頁，點擊左側菜單中的應用監控/應用總覽，即可以看到應用的總體情況：

• 總請求量：能夠一目瞭然的看到請求量是否明顯的異常，好比驟降或者陡升。
• 平均響應時間：應用總體接口的平均響應時間，這個指標直接反映最真實的應用健康情況。
• Full GC：JVM裏比較重要的指標，也是會直接影響系統性能的因素。
• 慢SQL：智能抓取執行時間大於500ms的SQL。
• 一些曲線視圖：幫助咱們掌握不一樣時段的應用狀況。

應用實例節點健康情況

進入應用詳情頁，點擊左側菜單中的應用監控/應用詳情，即可以看到應用每一個節點的信息：

從上圖能夠看到，左側會列出當前應用的全部實例節點，包括該節點的平均響應時間、請求次數、錯誤數、異常數。若是咱們按照影響時間降序排序，比較靠上的節點就是響應時間較慢的節點，而後咱們就須要分析是什麼緣由致使這些節點的響應時間較慢。因此，右側會提供了一些檢查維度來幫助咱們分析排查問題。

好比查看JVM指標：

應用接口健康情況

進入應用詳情頁，點擊左側菜單中的應用監控/接口調用，即可以看到應用每一個接口的信息：

接口監控和應用實例節點監控的思路一致，左側會列出全部請求過的接口，一樣顯示了響應時間、請求數、錯誤數，右側一樣提供了一些檢查維度來幫助咱們分析接口RT高的緣由。

好比查看SQL調用分析：

縱向Metrics指標

在上述三個角度中，其實已經涵蓋了絕大多數Metrics指標，好比有應用健康狀態的指標、JVM的指標、SQL指標、NoSQL指標等。

橫向調用鏈路

在不少時候，咱們單純的看Metrics指標是沒法肯定問題的根本緣由的，由於會涉及到不一樣服務之間的調用，不一樣接口之間的調用，因此須要查看服務和服務之間、接口和接口之間的調用關係以及具體的代碼信息。在這個維度上，SAE集成的ARMS的監控能力即可以實現。咱們在應用監控/接口調用/接口快照中能夠看到有請求的接口快照，經過TraceID即可以查看該接口的總體調用鏈路：

從上面這個圖咱們能夠看出不少信息：

• 該接口在服務級別的完整請求鏈路，好比ikf（前端）-> ikf-web(java服務)-> ikf-blog(java服務)-> ikf-blog(java服務)
• 每一個服務的狀態狀況，好比狀態一列是紅點，說明在這個環節是有異常出現的。
• 在每一個服務中請求的接口名稱。
• 每一個服務的請求耗時。

除了上述這些顯性的信息之外，還有一些隱性的信息：

• 上游服務ikf-web的總耗時是2008ms，但下游服務ikf-blog的總耗時是5052ms，並且耗時起點是同樣的，說明ikf-web到ikf-blog是一個異步調用。
• 既然ikf-web到ikf-blog是異步調用，然而ikf-web的耗時有2s之多，說明ikf-web服務中的接口也有問題。
• 在ikf-blog服務中，又有內部接口被調用，由於從調用鏈上出現了兩個ikf-blog，而且這個內部調用是同步調用，並且問題出如今最後一個接口調用上。

從以上這些信息能夠幫咱們縮小和圈定問題根因出如今哪一個環節的範圍，而後咱們能夠點擊方法棧一列的放大鏡，查看具體的方法棧代碼信息：

從方法棧這裏咱們又能夠獲得不少顯性信息：

• 具體的方法。
• 每一個方法的耗時。
• 方法產生的具體異常信息。
• 數據庫操做的具體SQL語句，甚至SQL上的Binding Value。

固然除了顯性信息外，還有一個比較重要的隱性信息，好比咱們能夠看到BlogController.findBlogByIsSelection(int isSelection)這個方法的耗時是5s，可是該方法內部的數據庫操做的耗時不多，只有1ms，說明耗時是屬於業務代碼的，畢竟業務代碼咱們是抓不到也不會去抓取信息的。這時咱們能夠有兩種方式去定位具體問題：

• 從方法棧信息中已經知道了具體的服務和具體的方法，那麼直接打開IDE查看、分析代碼。
• 查看方法棧頁籤旁邊的線程剖析，也基本能夠肯定問題所在。好比上圖這個狀況，咱們查看線程剖析後會發現他的耗時是由於java.lang.Thread.sleep( ):-2 [3000ms]。

韌性能力（Resilience）

對於雲原生架構的韌性能力，我會從優雅上下線、多AZ部署、限流降級三個方面來聊一聊。

優雅上下線

一個好的產品，要能快速應對用戶對產品功能、能力具備普適性的反饋和意見，能快速響應市場需求的變化。那麼產品的功能就須要快速的作迭代和優化，從IT層面來看，就是要有快速、高效、高質量的發佈變動流程，可以隨時進行生產環境的服務發佈。

可是這會帶來一個核心問題，即頻繁的服務發佈，而且不能影響用戶體驗，用戶的請求不能斷流。因此這就要求咱們的系統部署架構中有優雅上下線的能力。

以微服務架構來講明，雖然開源的產品有能力和方案作到近似優雅上下線，但也是近似作到，當發佈服務節點較多的狀況下依然會有斷流的狀況。因此開源方案有諸多問題：

• 註冊中心不可靠、通知不及時。
• 客戶端輪訓不實時、客戶端緩存。
• 自定義鏡像非1號進程，Sigterm信號沒法傳遞。
• 無默認優雅下線方案，須要添加actuator組建。

在無服務化/服務配置中心章節中，我闡述了SAE自帶的服務中心和MSE的服務中心，不管使用那種方案，咱們都對優雅上下線作了進一步的優化。

從上圖能夠看到，部署在SAE的應用具備主動通知服務中心和服務消費者的能力，再結合Liveness應用實例探活和Readiness應用業務探活的機制，能讓咱們的服務在進行部署和由於其餘緣由掛掉時不會影響用戶的正常訪問。

多AZ部署

本着雞蛋不能放在一個籃子裏的原則，一個應用的多個節點，應該分佈在不一樣的可用區，這樣總體應用的高可用和健壯性纔是足夠好的。SAE支持設置多個交換機（VSwitch），每一個交換機能夠在不一樣的可用區，這樣在部署、擴容應用的節點時會隨機從可選的可用區拉起實例：

這就避免了當某個可用區出現問題掛掉時，總體系統由於在一個可用區而掛掉，這也是最基本的同城多活的實踐。

限流降級

限流降級是系統斷臂求生的能力，在遇到突發的流量脈衝時，能夠及時限制流量，避免整個系統被擊穿，或者當流量超出預期時，及時切斷非核心業務，釋放資源來支撐核心業務。

目前對於Java應用，SAE也支持限流降級的能力，首先對應用的全部接口的請求指標進行抓取和監控：

而後咱們能夠針對每個接口設置流控、隔離、熔斷的規則，好比我對/checkHealth接口設置一條流控規則：

當該接口的QPS達到50後，單個機器超過50的請求將快速失敗。好比咱們對一個有6個節點的應用進行壓測時，能夠看到每一個節點的QPS狀況：

當開啓流控規則後，能夠當即看到限流的效果：

能夠看到QPS被精準的控制到50，超過50的請求直接返回失敗。

自動化能力（Automation）

在自動化能力方面，我主要從CICD流程這個維度來聊一聊。你們從上面章節的截圖能夠看到，有不少是SAE控制檯的截圖，在實際應用中確定不會經過控制檯來一個一個發佈應用，必然都是經過CICD流程來作自動化的應用打包和發佈流程。

SAE在這個方面提供兩種實現自動化運維的方式。

基於Gitlab和Jenkins

目前不少企業的CICD流程都是基於Gitlab和Jenkins來作的，那麼SAE也支持將發佈的操做集成到這種方案裏。這個方案的核心是SAE會提供一個Maven插件，同時對應有三個配置文件，Maven插件經過這三個配置文件中的信息將打包好的Jar/War或者鏡像發佈到對應的SAE應用中。

• toolkit_profile.yaml：配置RegionID、AccessKey ID、AccessKey Secret。
• toolkit_package.yaml：配置好比應用部署包類型、部署包地址、鏡像地址。
• toolkit_deploy.yaml：配置好比SAE應用的ID、應用所屬命名空間ID、應用名稱、發佈方式等。

更詳細的配置信息能夠參閱該文檔。

而後在Jenkins的任務中，對Maven設置以下的命令便可：

clean package toolkit:deploy -Dtoolkit_profile=toolkit_profile.yaml -Dtoolkit_package=toolkit_package.yaml -Dtoolkit_deploy=toolkit_deploy.yaml

這樣就能夠很容易的將SAE的部署流程集成到基於Gitlab和Jenkins的CICD方案裏了。

基於Open API

還有一些企業會本身研發運維平臺，運維賦能研發，由研發同窗在運維平臺上進行運維操做。面對這種場景，SAE提供了豐富的Open API，能夠將SAE控制檯上90%的能力經過Open API集成到客戶本身的運維平臺中。詳細的OpenAPI說明能夠參與該文檔。

總結

基於SAE武裝過系統後，總體的部署架構會變成這樣：

雲原生架構成熟度模型（SESORA）在我闡述的這五個維度一共是15分，基於SAE的雲原生架構在這五個維度會達到12分：

• 無服務化：3分
• 彈性能力：3分
• 可觀測性：2分
• 韌性能力：2分
• 自動化能力：2分

做者：計緣，阿里雲解決方案架構師

原文連接

本文爲阿里雲原創內容，未經容許不得轉載。