雲原生架構是什麼

新一代的技術架構是什麼？如何變革？是很多互聯網企業面臨的問題。而云原生架構則是這個問題最好的答案，因爲雲原生架構對雲計算服務方式與互聯網架構進行整體性升級，深刻改變着整個商業世界的 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 產品只做所謂的通用能力，或者只是一味模仿國外產品，一旦深入到行業屬性比較重的場景時便無法滿足需求，所以被貼上了 “半成品” 的標籤，導致市場接受程度不如預期。

• 產品模塊單一、功能相似的 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，擴展服務的節點數，然後再釋放，並且這種情況只適用於定時定點的活動，如果是不定時的流量脈衝則無法應對。

1、命名空間

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

2、創建應用

創建好命名空間後，我們進入應用列表，即可選擇不同的命名空間，看到其下的應用或者創建應用：

選擇對應的命名空間，然後創建應用：

• 應用名稱：服務名稱，用戶自行輸入。

• 專有網絡配置：

• 自動配置：自動幫用戶配置 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 包的方式部署完應用後，在對應命名空間下就可以看到剛剛創建的應用了：

點擊應用名稱可以查看應用詳情：

3、綁定 SLB

因爲 ServiceA 在架構中是對外提供接口的服務，所以需要對該服務綁定公網 SLB 暴露 IP 和做負載均衡，在 SAE 中，綁定 SLB 非常簡單，在詳情頁中，即可看到應用訪問設置：

添加 SLB 時可以選擇新建也可以選擇已經創建好的 SLB：

4、服務 / 配置中心

對於微服務架構，服務中心和配置中心是必不可少的，大家常用到一般是 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 提供了兩種擴縮應用實例數的方式，手動方式和自動方式。

1、手動擴縮

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

當進行擴縮時，我們可以看到具體實例的變更狀態：

2、自動擴縮

在控制檯右上角有自動擴縮操作按鈕，然後可以看到創建擴縮規則的界面。SAE 自動擴縮提供時間策略和指標策略兩種。

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

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

3、成本優化

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

可觀測性（Observability）

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

在監控微服務架構時，通常需要從三個角度來看：

• 應用的整體健康狀況。

• 應用每個實例的健康狀況。

• 應用每個接口的健康狀況。

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

1、應用整體健康狀況

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

• 總請求量：可以一目瞭然的看到請求量是否明顯的異常，比如驟降或者陡升。

• 平均響應時間：應用整體接口的平均響應時間，這個指標直接反映最真實的應用健康狀況。

• Full GC：JVM 裏比較重要的指標，也是會直接影響系統性能的因素。

• 慢 SQL：智能抓取執行時間大於 500ms 的 SQL。

• 一些曲線視圖：幫助我們掌握不同時段的應用情況。

2、應用實例節點健康狀況

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

從上圖可以看到，左側會列出當前應用的所有實例節點，包括該節點的平均響應時間、請求次數、錯誤數、異常數。如果我們按照影響時間降序排序，比較靠上的節點就是響應時間較慢的節點，然後我們就需要分析是什麼原因導致這些節點的響應時間較慢。所以，右側會提供了一些檢查維度來幫助我們分析排查問題。

比如查看 JVM 指標：

3、應用接口健康狀況

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

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

比如查看 SQL 調用分析：

4、縱向 Metrics 指標

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

5、橫向調用鏈路

在很多時候，我們單純的看 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 部署、限流降級三個方面來聊一聊。

1、優雅上下線

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

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

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

• 註冊中心不可靠、通知不及時。

• 客戶端輪訓不實時、客戶端緩存。

• 自定義鏡像非 1 號進程，Sigterm 信號無法傳遞。

• 無默認優雅下線方案，需要添加 actuator 組建。

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

從上圖可以看到，部署在 SAE 的應用具有主動通知服務中心和服務消費者的能力，再結合 Liveness 應用實例探活和 Readiness 應用業務探活的機制，能讓我們的服務在進行部署和因爲其他原因掛掉時不會影響用戶的正常訪問。

2、多 AZ 部署

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

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

3、限流降級

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

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

然後我們可以針對每一個接口設置流控、隔離、熔斷的規則，比如我對 /checkHealth 接口設置一條流控規則：

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

當開啓流控規則後，可以立即看到限流的效果：

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

自動化能力（Automation）

在自動化能力方面，我主要從 CICD 流程這個維度來聊一聊。大家從上面章節的截圖可以看到，有很多是 SAE 控制檯的截圖，在實際應用中肯定不會通過控制檯來一個一個發佈應用，必然都是通過 CICD 流程來做自動化的應用打包和發佈流程。

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

1、基於 Gitlab 和 Jenkins

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

更詳細的配置信息可以參閱該文檔。

然後在 Jenkins 的任務中，對 Maven 設置如下的命令即可：

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

2、基於 Open API

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

總結

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

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

• 無服務化：3 分

• 彈性能力：3 分

• 可觀測性：2 分

• 韌性能力：2 分

• 自動化能力：2 分

對於上手、實踐、落地快捷簡單，又能達到比較好的雲原生架構成熟度的 SAE 方案，大家還在等什麼呢？一起實踐起來吧。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4RdSU1OM870QwzXGkF3Sdw