*作者：三辰*

## 前言

大家好，今天給大家帶來 MSE 高可用方向的重要功能——風險管理的釋出。

閱讀這篇文章，你將能夠了解以下知識點和能力：

-   熟悉微服務體系高可用如何設計
-   掌握如何控制系統中的風險
-   瞭解MSE微服務引擎風險管理功能能解決什麼風險
-   熟悉如何使用風險管理功能
-   瞭解風險管理更多高階功能的未來規劃

## 微服務高可用如何設計

### 大促場景如何做高可用

阿里巴巴十幾年的大促經驗，積累了一套成熟的微服務高可用評估體系。

我們現在以大促場景為例，談談如何做好高可用。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4cd650112b3a48d6baef58b821483183~tplv-k3u1fbpfcp-zoom-1.image "1.png")

大促高可用

首先從架構上看，內部的電商、物流、文娛等業務系統，都是基於 MSE 微服務引擎提供的雲原生閘道器和 Nacos 註冊配置中心構建的微服務體系。並且在整個鏈路上基於 MSE 的 Sentinel 覆蓋限流降級的能力，基於 ARMS 的 Prometheus 和 Tracing 能力做好鏈路的可觀測。

底層容器化，基於 K8s 這一套成熟的排程體系，解決資源利用率、快速交付和彈性的問題。

在大促即將到來之前，透過 PTS 提供的全鏈路壓測能力，對整個大促涉及的所有鏈路進行端到端的壓測，模擬真實大促流量，觀測每個業務子系統的表現，驗證限流降級預案執行準確無誤。峰值前快速彈性上線，峰值後快速縮容下線。

### MSE 微服務引擎介紹

基於這一套雙十一大促實踐經驗，阿里中介軟體團隊將這一套微服務最佳實踐開源，並提供了一套完整的商業化解決方案。以滿足外部客戶對高效能、高可用、高整合度和安全的述求。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cd1e42ba25d442bea95028f119f2ccfe~tplv-k3u1fbpfcp-zoom-1.image "2.png")

微服務引擎（Micro Service Engine，簡稱 MSE）是一個面向業界主流開源微服務生態的一站式微服務平臺。

### 高可用設計思路

-   **系統組成**

那麼，一套微服務系統如果從零開始搭建，應該如何設計保證高可用呢？

我們用一張簡單的圖來表示一個微服務系統的基本架構。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f8f43e375c7644189d2121e45d374907~tplv-k3u1fbpfcp-zoom-1.image "3.png")

微服務系統全鏈路包含閘道器、註冊配置中心、業務子系統，任何地方都是「牽一髮而動全身」，一個抖動都可能會較大範圍地影響整個系統。

每個業務子系統之間呼叫關係通常也非常複雜，甚至是網狀的。

-   **可能發生什麼問題？**

這套最小系統的每一個部分都可能發生問題，我們來看看都有哪些。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a1741f64ef6d46a880ff94deedbb7a40~tplv-k3u1fbpfcp-zoom-1.image "4.png")

先從入口的閘道器來看，最典型的問題就是容量不足，導致吞吐量下降。表現就是使用者訪問系統出現超時；也有可能是錯配導致流量丟失，使用者訪問的頁面找不到打不開，比如最流行的 Nginx，沒有頁面操作，都是黑屏控制，很容易出現漏配、錯配的問題，也缺少配置版本的管理，非常容易失誤。

註冊中心故障，會導致註冊失敗，影響大促場景下快速彈性上線，新的容器都無法註冊上來。在服務呼叫方還可能收到空列表的情況。

配置中心出問題，會導致風險預案無法下發，不能對業務降級。

業務子系統更加複雜，可能出現某個子系統流量瓶頸，拖垮整個流量的情況。業務異常缺少觀測手段，該打日誌的地方沒有任何資訊。這些都需要藉助服務治理的能力解決。

這些問題都是以往的大促活動中真實案例，每一個高可用方案的背後，都是一段血淚史。

-   **面對風險設計**

我們不得不承認一個事實：沒有任何系統是百分之百沒有問題的。

高可用架構就是面對失敗設計，或者說是面對風險設計。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ae211de286be4a468d7d984823e60f8d~tplv-k3u1fbpfcp-zoom-1.image "5.png")

基礎設施意外風險，最典型的就是幾年前，杭州某條光纜被地鐵施工挖斷，導致全國的支付寶都用不了。這種風險一旦發生，業務很難承受。

還有作業系統依賴上，可能有儲存故障、網路抖動、時間服務不穩定、DNS 故障等等，系統 hang 死了連監控報警都有可能上不來。

還有業務系統服務端故障、記憶體洩露，客戶端連線池滿，運維人為誤操作等。

> 雖然我們不可避免風險發生，但是，我們可以控制風險。

高可用的本質：**控制風險**

## 如何控制風險

### 風險控制的策略

大致可以分為四種策略控制風險，如下圖：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/37c09c115eb242e887c6c1f06c471ce2~tplv-k3u1fbpfcp-zoom-1.image "6.png")

有了相應的策略，我們如何提前識別風險並加以控制？

### 識別不同風險

我們把風險分成幾類：

-   架構風險
-   版本風險
-   容量風險
-   安全風險

### 架構風險

例如：

-   註冊配置中心、閘道器、業務系統單節點都無法高可用
-   Nacos、ZK等註冊中心一致性協議對雙數節點存在無法選主的問題，寫請求不可用
-   註冊中心節點在可用區分佈不均，可用區故障可能導致叢集不可用
-   業務系統架構風險：無註冊中心容災措施（如推空保護、服務列表快取&降級方案）

這些都可以算作架構風險。

-   **MSE 註冊配置中心三 AZ 容災架構**

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0503e682739c49d0ad66ff286ee11314~tplv-k3u1fbpfcp-zoom-1.image "7.png")

MSE 專業版的註冊配置中心，預設採用三可用區部署的容災架構。透過 3 副本解決了單點問題，以多可用區部署的方式來減少了單一可用區不可用的風險帶來的影響。叢集所依賴的網路和儲存例項，也都是多可用區部署的架構。

這就是一個雲上服務做高可用容災的典型架構。開發者的業務架構也同樣可以 follow 這個模式。

-   **業務架構風險**

說到業務架構，通常一個網格狀的業務呼叫關係，一定會有服務消費者（Consumer）和服務提供者（Provider）。

#### 1. Consumer

服務消費者（Consumer）會從註冊中心上訂閱服務提供者（Provider）的例項列表。

當遇到突發情況（例如，可用區斷網，Provider 端無法上報心跳） 或 註冊中心（變配、重啟、升降級）出現非預期異常時，都有可能導致訂閱異常，影響服務消費者（Consumer）的可用性。

為了應對不可預知的情況下訂閱列表異常，可以在 Consumer 側配置推空保護。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3551caf29f8a44bba7e8c8be8688454e~tplv-k3u1fbpfcp-zoom-1.image "8.png")

我們來看一下什麼是 Consumer 端的推空保護。

當 Provider 端到 Nacos 註冊中心的網路出現異常，或是註冊中心自身運維上下線過程中，維護的 Provider 例項列表可能出現空的情況，推送到 Consumer 端。這時，Consumer 側訂閱到了空的 Provider 列表，就會導致業務中斷。

如果在 Consumer 側配置推空保護，收到空列表時會丟棄這次異常的更新操作，仍然保持上一次非空列表，確保業務呼叫鏈路的流量正常往下走。

開啟的方式非常簡單，無論是 SCA 還是 Dubbo 框架，一個配置即可開啟。

推空保護支援的版本要求大家可以在我們 MSE 的高可用最佳實踐幫助文件當中找到。

Consumer 第二個有效措施是服務降級。

Consumer 端可以根據不同的策略選擇是否將某個呼叫介面降級，起到對業務請求流程的保護（將寶貴的下游 Provider 資源保留給重要的業務 Consumer 使用）

服務降級的具體策略，包含返回 Null 值、返回 Exception 異常、返回自定義 JSON 資料和自定義回撥

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d07b45f76ea541f596eca6a68d0faf7d~tplv-k3u1fbpfcp-zoom-1.image "9.png")

這個降級過程是全自動，無需干預的過程。只要配置的策略被觸發了，治理平臺會自動執行預案，並且可以在控制檯上清楚地觀測到。

#### 2. Provider

服務提供者（Provider）自身的可用性遇到問題，需要緊急下線，或者是日常運維上下線時，例項列表在註冊中心上的更新不及時導致流量有損，就需要一系列措施來保障它的高可用。

-   **離群例項摘除**

心跳續約是註冊中心感知例項可用性的基本途徑。Provider 在大流量下可能出現異常，但有時候服務不是完全不可用，它與註冊中心之間的心跳續約仍然存在，但是某些系統資源耗盡是簡單的心跳機制無法感知的。例如：

-   Request 處理的執行緒池滿
-   依賴的 RDS 連線異常或慢 SQL

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b0fe59c1b38e4e5d829c7ba7e96e6858~tplv-k3u1fbpfcp-zoom-1.image "10.png")

**微服務治理中心**提供離群例項摘除：

-   基於異常檢測的摘除策略：包含網路異常和網路異常 + 業務異常（HTTP 5xx）
-   設定異常閾值、QPS 下限、摘除比例下限 
  
離群例項摘除的能力是一個補充，根據特定介面的呼叫異常特徵，來衡量服務的可用性。降級過程完全自動。

-   **無損上下線**

通常我們不做任何措施的情況下，我們的服務上下線都是有損的。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cc72d1c6d7e848c69917210f147c28c7~tplv-k3u1fbpfcp-zoom-1.image "11.png")

有損下線

無損下線，又叫優雅下線、或者平滑下線，都是一個意思。首先看什麼是有損下線：

Provider 例項進行升級過程中，下線後心跳在註冊中心存約以及變更生效都有一定的時間，在這個期間 Consumer 端訂閱列表仍然沒有更新到下線後的版本，如果魯莽地將 Provider 停止服務，會造成一部分的流量損失。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1cdcf36c21154811aad6d9ae8c70bbe3~tplv-k3u1fbpfcp-zoom-1.image "12.png")

無損下線

可以透過 MSE 微服務治理平臺的能力，開啟無損上下線。無侵入、無改造地無感開啟。

無損下線的流程整合在釋出流程中，對應用進行停止、部署、回滾、縮容、重置等操作時，無損下線會自動執行。免去繁瑣的運維指令碼邏輯的維護。

### 版本風險

任何軟體版本都有一個迭代過程，不斷增強功能和最佳化的過程當中，也會無意中引入一些問題。在我們 Nacos 過去釋出的版本當中，就存在一些客戶端版本在特定條件下會出現嚴重問題的缺陷。例如：Nacos-Java-Client:v1.4.1 DNS 失敗後心跳執行緒無法自愈；或者是一些社群維護的多語言版本客戶端，存在一些功能的缺失。

服務端版本也是同樣的。由 MSE 專業的商業化團隊維護，無論是註冊中心還是閘道器都在不斷地迭代收斂各類效能問題和功能缺陷，版本總是越發展越趨向於穩定，一些過去存在嚴重缺陷的版本，我們也會透過這次釋出的風險管理功能給開發者們透出。

-   **案例**

某客戶在阿里雲上使用 K8s 叢集部署了許多自己的微服務，但是某一天，其中一臺節點的網路卡發生了異常，最終導致服務不可用，無法呼叫下游，業務受損。

1.  ECS 故障節點上執行著 K8s 叢集的核心基礎元件 CoreDNS 的所有 Pod，它沒有打散，導致叢集 DNS 解析出現問題。
1.  該客戶的服務發現使用了有缺陷的客戶端版本（nacos-client 的 1.4.1 版本），這個版本的缺陷就是跟 DNS 有關——心跳請求在域名解析失敗後，會導致程式後續不會再續約心跳，只有重啟才能恢復。
1.  這個缺陷版本實際上是已知問題，阿里雲在 5 月份推送了 nacos-client 1.4.1 存在嚴重 bug 的公告，但客戶研發未收到通知，進而在生產環境中使用了這個版本。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e3e3499b96264db6929215f011d832e9~tplv-k3u1fbpfcp-zoom-1.image "13.png")

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0d01c1cda9b949aaa0fad9db15bfa735~tplv-k3u1fbpfcp-zoom-1.image "14.png")

案例中存在的風險：

1.  CoreDNS 沒有按節點打散，單點架構風險
1.  依賴客戶端版本風險沒有被通知，沒有有效收斂

### 容量風險

容量評估一直是一個複雜的事情。

每年每個大促，阿里內部都會做一次全鏈路的壓測，目的就是確保每個業務和系統的容量做到最佳的評估。容量風險帶來的雪崩效應能夠像洪水一樣，瞬間摧毀整個系統。

說它複雜，是因為每個子系統都有不同的評估指標和標準。

1.  註冊中心：Provider 數量、連線數、QPS/TPS
1.  配置中心：配置長輪詢數、連線數、QPS/TPS
1.  閘道器：併發連線數、新建連線數、頻寬、QPS

1.  1.  不同條件下（短/長連線、包大小、是否 https/gzip）的 QPS 容量是不同的
    1.  真實條件更加複雜

4.  業務系統：吞吐能力（QPS/TPS/RT）、上下游依賴的處理能力

比如註冊中心關注 Provider 數量、連線數、TPS；配置中心關注長輪詢請求的量；閘道器更加複雜，併發連線數、新建連線數、頻寬、QPS；甚至不同條件下，比如請求是長連線還是短連線、每個 HTTP 包的大小、是否是 HTTPS、是否 gzip 壓縮，都是影響容量上限的因素。

業務系統除了需要評估自身的吞吐能力之外，還需要關注上下游依賴的處理能力，遵循木桶原理，透過全鏈路壓測的方式，來找到那個短板。

-   **閘道器容量評估策略**

這裡簡單分享一個大促下閘道器的容量評估方法。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/31acbb210580445da8e50c11245918c2~tplv-k3u1fbpfcp-zoom-1.image "15.png")

大促的特點是什麼？

第一個是瞬時流量非常高，秒級突發流量，我們需要做好過載保護的限流措施，除了正常流量之外，還需要預留好足夠的容量水位應對突發的網路攻擊。

第二個是大促會有熱點商品，閘道器針對熱點商品提前預熱流量，確保底層業務系統處於最佳狀態。

第三個是梳理和保障核心鏈路，大促期間，一些非主鏈路的，錦上添花的功能就可以直接在閘道器側降級掉，避免不必要的流量打到業務系統上。

我舉一個我自己體會很深的一個例子，就是釘釘當時因為疫情，學校都透過釘釘在家上網課，為了保障核心影片鏈路的通暢，所有無關的功能就被降級掉了。比如表情標籤，點贊這些功能，一般人不會因為不能點贊而抱怨功能異常產生輿情，降級也是合理的。

### 安全風險

開源產品總會時不時報出安全漏洞，無論是產品自身還是第三方依賴。

-   註冊中心（Nacos、ZooKeeper）、閘道器（Envoy）相關安全漏洞
-   客戶端的第三方依賴漏洞（log4j 等）

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/38673f2df0eb47289fc4e576fc9091d5~tplv-k3u1fbpfcp-zoom-1.image "16.png")

安全能力：

-   註冊配置中心公網 Endpoint 白名單 ACL 控制
-   MSE 雲原生閘道器獲得信通院安全評級認證
-   閘道器支援 WAF 本地防護

目前，MSE 已經具備較高的安全能力。

很多客戶都為了除錯方便，註冊配置中心的公網 Endpoint 沒有設定 ACL，容易被攻擊。我們建議將 ACL 開啟。

閘道器支援本地 WAF 等防護能力，並且獲得了信通院安全評級認證。

## 風險管理功能介紹

到這裡，大家應該充分掌握瞭如何有效地控制系統中的風險。

本次 MSE 釋出的風險管理功能，目地就是讓開發者能夠簡單高效地識別和控制風險，給大家一個 MSE 產品相關的風險控制的最佳實踐指導。

### 功能頁面

風險管理已覆蓋 MSE 中 Nacos、ZooKeeper、雲原生閘道器三大子產品。在例項頁面中的選單上可以找到：

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ba2ca08fa47b44eb814876e097cc310a~tplv-k3u1fbpfcp-zoom-1.image "17.png")

針對每一個例項，我們會給出當前例項的風險列表，覆蓋架構、版本、容量、安全等方面。

每個風險都會給出相應的解決方案和建議，如果需要擴容或升配，建議在業務低峰期操作。

### 未來規劃

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6cc5a309dc184d86ba855aacae813b47~tplv-k3u1fbpfcp-zoom-1.image "18.png")

過去，風險的識別都依賴人工感知，甚至滯後，到了風險發生時再採取措施就為時已晚了。

現在，MSE 相關產品都已經能夠做到系統自動化的識別風險資訊，並且主動推送到使用產品的負責人。

我們完成了風險識別、透出、診斷鏈路的建設，後續還會不斷建設完善更多的診斷方式，增加對風險的識別能力。

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/516311bf185c49c79fd5694ea5d03933~tplv-k3u1fbpfcp-zoom-1.image "19.png")

未來，我們還會探索風險自愈能力的建設。我們希望把一些明確的風險問題能夠做到自愈，讓使用者無需感知風險收斂的過程。

感知容量風險，自動彈性；在可運維時間內無感知自愈；提供一個使用者可主動訂閱的事件中心，幫助使用者快速感知異常事件。

*作者介紹：*

*三辰，雲原生微服務基礎架構技術專家、MSE 架構-高可用負責人。*

更多 MSE 特性，歡迎進釘釘群/交流~

![20.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ea6d4390bf7c4b4582f6b2f13a0288cf~tplv-k3u1fbpfcp-zoom-1.image "20.jpeg")

MSE 風險管理功能釋出

相關文章