[CloudNative] 企業應用上云實踐手記-Cloud Native Phase 4 -如何實現云上彈性伸縮和熔斷限流

整個端到端CloudNative產品落地，計劃分為六個階段展開：

Cloud Native Phase 1 - 云上微服務開發端到端

Cloud Native Phase 2 - 云上DevOps

Cloud Native Phase 3 - 云原生應用AutoConfig

Cloud Native Phase 4 – 如何實現云上彈性伸縮和熔斷限流

Cloud Native Phase 5 - 云上權限管理和網絡安全

Cloud Native Phase 6 – 如何申請外網域名和SSL證書

本文為第四章即Cloud Native Phase 4 - 如何實現云上彈性伸縮和熔斷限流。

題記：

前面把應用開發到部署的路走完以后，產品交付的坑基本趟平了，終于可以安心看下最有意思的部分：彈性伸縮和熔斷限流。之所以把這兩個命題放在一起探討，個人理解，其實是一體的兩面，目的當然很明顯，都想保護核心業務，但是打法不一樣。

這兩個點如果非要排個先后，那我個人最感興趣的就是彈性伸縮了，這部分也是個人對云最期待的地方，無限的資源和靈活的伸縮，一方面可以抗住短期的流量洪峰，另一方面還能節約資源。

往后發展，Serverless化、FaaS化以后，可能都不需要主動干預，即可實現Auto-Scaling，對于系統架構設計來說，那就更簡單了，當然那又是另一個話題，我們項目在現階段有引入FunctionGraph的能力，做一些簡單的后端API，確實比較省事，但是架構能力很難體現（代碼沒法框架化，只能一個個的摞功能），后面會詳細看看這塊的能力。

下面主要從具體實現上，嘗試總結一套標準打法，或者說“最佳”實踐，以落地到華為云產品，歡迎指導。

1. 什么是彈性伸縮和熔斷限流

關于彈性伸縮和熔斷限流，網上有很多解釋，筆者想從技術架構的角度，談談個人的理解：

共同點：

兩者共性，就是都是通過一些措施，來預防波動對系統的影響，以期實現系統的長時間可用（Availability），核心業務不中斷

差異：

彈性伸縮，是進攻牌，屬于可靠性（Reliability）的范疇。意味著業務不能斷，不管流量大小，可以通過資源補充或者釋放的方式，不僅支撐業務，還能獲得收益最大化，核心還是支撐業務

熔斷限流，是防守牌，屬于韌性（Resilience）的范疇。意味著茍活，以退為進，丟卒保車，是一種自我保護

無論是彈性伸縮還是熔斷限流，都有很多種方式可以實現。從彈性伸縮來看，從ECS主機層、CCE容器層，都可以實現伸縮；從熔斷限流來看，從微服務內部、CSE引擎層、API網關層，都可以實現熔斷限流。

2. 云上CCE容器實現彈性伸縮

本文所有后端服務，除了用FunctionGraph的部分，其余全部跑在CCE上，因此先探討CCE如何實現彈性伸縮。

CCE提供了兩種方式來實現彈性伸縮：

一種是通過K8s的插件

另一種是借助AOM的監控指標：

CCE容器層的彈性伸縮，又分了兩層：

節點伸縮

工作負載伸縮

這兩層顧名思義，不解釋了。

兩者在具體使用時，都是需要的，首先是確保workload啟動的時候，資源池里有資源，如果沒有，則到資源池里擴節點。兩者的實現方式和概念類似，但是依賴不同的插件支撐。

Cluster Autoscaler是Kubernetes提供的集群節點彈性伸縮組件，根據Pod調度狀態及資源使用情況對集群的節點進行自動擴容縮容。

簡單說，就是提供了一套獨立的Pod，來執行一些Scale-up和Scale-down的流程，詳情可以參考官方文檔：節點伸縮原理。

CCE的節點伸縮，依賴了兩套模型，一個是K8s自己支撐的autoscaler插件，另一個是通過監控探針的采集指標（即AOM服務）。

關于autoscaler插件

這部分建議直接看K8s的官方文檔：Pod水平自動擴縮（Horizontal Pod Autoscaler）

華為的官方文檔里有介紹，“當前該插件使用的是最小浪費策略，即若pod創建需要3核，此時有4核、8核兩種規格，優先創建規格為4核的節點”，這一點還是很不錯的，可以獲得最小的碎片，不會浪費太多資源。

首先要安裝autoscaler插件

到插件市場，搜索autoscaler，安裝插件

基本信息，要選擇集群（要伸縮的集群）

配置一下插件的規格

暫時選擇50節點的規格，需要2個pod來跑這個插件，并且開啟自動縮容，如果資源使用率低于50%的時候，就開始縮容掃描，然后進行安裝

完成插件安裝

兩個pod已經啟動了，狀態是運行中，命名空間位于kube-system

插件安裝完以后，就可以到彈性伸縮->節點伸縮中，創建節點伸縮策略，顧名思義。

開始創建節點伸縮策略

前提條件是插件狀態是運行中

此處需要關聯到一個節點池，或者說一個資源池

回到資源管理->節點池管理，創建一個新的資源池

新建節點池

選擇0個節點，并啟用彈性擴縮容，最大50個節點，最小0個，也就是默認這里沒有節點，不伸縮的情況花費是0元。并且選擇隨機可用區，這樣彈性出來的節點會離散分布在不同的AZ里

配置節點伸縮策略

選擇剛建好的節點池，然后創建一個規則，這里支持兩種，基于CPU/內存，和基于時間，這樣可以用來處理突發流量波動和周期性流量波動，比如打卡、促銷之類的。

最終，得到了一個空的節點伸縮策略

走到這里就會發現，很多參數其實并沒有配置，比如每次擴縮容的間隔（保護時間）等，這些是全部在autoscaler插件里配置的

注意：?節點伸縮會觸發ECS資源購買，這也簡化了整體伸縮的復雜度，也就是不需要感知到支撐ECS彈性伸縮的AS服務

目前CCE的工作負載伸縮功能提供了兩種模式，第一種是默認的，也就是K8s配套的，另一種是華為自研的增強版，具體參考官方文檔

創建工作負載伸縮策略，兩種模式的插件一不一樣，暫時選擇默認的Pod水平伸縮，即Horizontal Pod Autoscaling（HPA）

HPA是基于指標閾值進行伸縮的，常見的指標主要是 CPU、內存，當然也可以通過自定義指標，例如QPS、連接數等進行伸縮。但是存在一個問題：基于指標的伸縮存在一定的時延，這個時延主要包含：采集時延(分鐘級) + 判斷時延(分鐘級) + 伸縮時延(分鐘級)。這個分鐘級的時延，可能會導致應用CPU飚高，相應時間變慢。為了解決這個問題，CCE提供了定時策略，對于一些有周期性變化的應用，提前擴容資源，而業務低谷時，定時回收資源。

參考官方幫助：工作負載伸縮原理

首先，進入彈性伸縮->工作負載伸縮，創建HPA策略

安裝metrics-server組件的過程很簡單，簡單配置多實例一下即可

期間狀態會是安裝中，大約幾分鐘就OK

插件安裝完以后，就進入下一步，策略配置頁面，這里的參數介紹，可以參考前面的：[2.2.1 參考：HPA工作原理]

首先寫了一個很簡單的壓測API，主要邏輯就是起一個線程死循環，API入參傳入線程數，傳導壓力到容器內部，持續120秒。

利用APIG執行壓力測試接口，傳入并發線程數5

可以看到CPU有一個明顯的波峰，可以達到100%的CPU利用率，超過前面HPA策略設置的閾值180%。

回到CCE的工作負載頁面，可以看到已經增加了一個Pod

在工作負載的事件標簽頁里，也會記錄一個ReplicaSet創建成功的動作

在工作負載的伸縮標簽頁里，也會看到HPA策略的SuccessfulRescale事件，重新計算了New size: 2; reason: cpu resource utilization (percentage of request) above target

第二次加壓以后，彈性出來了4臺機器，剛好用來驗證壓力回落以后，是否能夠成功縮容

這里會發現，每隔6分鐘，系統檢測一次，識別到資源低于閾值，縮容1臺服務器

ECS主機實現彈性伸縮，主要靠AS彈性伸縮服務，能監控CPU、內存、磁盤、入網流量等指標，然后自動的彈性伸縮，整體機制和前面節點伸縮差不多。

3. 云上實現熔斷限流

因為本文是基于SpringCloud體系搭建的微服務框架，所以優先看了spring-cloud-huawei這套框架提供了Governance功能（ServiceComb-Governance的適配版），能夠實現基于動態配置的流量特征治理。

下面這段基本上講清楚了原理：

治理過程可以從兩個不同的角度進行描述。

從管理流程上，可以分為流量標記和設置治理規則兩個步驟。系統架構師將請求流量根據特征打上標記，用于區分一個或者一組代表具體業務含義的流量，然后對這些流量設置治理規則。

從處理過程上，可以分為下發配置和應用治理規則兩個步驟。可以通過配置文件、配置中心、環境變量等常見的配置管理手段下發配置。微服務SDK負責讀取配置，解析治理規則，實現治理效果。

簡單說，就是先做流量標記，也就是所謂的染色，然后根據染色，配置一些規則確定何時限流，何時熔斷等。然后再給個管理入口，進行配置下發，動態生效起來。

首先要引入一個依賴spring-cloud-starter-huawei-governance

2. application.yaml文件中增加如下配置，意思就是對前綴為/demo的API進行染色，限流為1個QPS

3.用工具測試一下，限流生效

CSE的服務治理只適用于Java Chassis、Go Chassis開發框架，由于程序是基于SpringCloud開發的，所以暫時不能使用該功能，只能通過服務內置的ServiceComb-Governance進行處理。

PS：參考官方文檔：服務治理

API網關針對所有已發布的API，提供了一種流控措施，可以通過創建API流控策略，綁定API，進行生效。

首先在APIG服務中，進入流量控制頁面，創建新的流控策略

這里分兩種流控模式，基礎流控和共享流控，一個是針對單個API消耗計數，另一個是所有綁定的共同消耗計數。

PS：詳情可以參考官方文檔：創建流控策略并綁定到API

然后綁定前面創建的測試API

通過Insomnia敲了20次回車以后，響應變成429 Too Many Requests，符合預期。

總結

華為云針對微服務，提供了一套相對完整的體系，能夠支撐應用在流量洪峰面前，保護自己核心業務，整套體系無論是彈性伸縮還是熔斷限流，都有多層的實現方式，可以從高到低，從邊界最前沿到服務深處，逐層防護。

總結起來，可以通過：

CCE容器的節點伸縮和工作負載伸縮兩種能力，進行容器級別的彈性伸縮

APIG層面流量控制，配合微服務內部的動態流量治理，進行微服務級別的服務治理

API Kubernetes 彈性伸縮 AS

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。