*作者：流士*

本次 MSE 治理中心在限流降級、資料庫治理及同 AZ 優先方面進行了重磅升級，對微服務治理的彈性、依賴中介軟體的穩定性及流量排程的效能進行全面增強，致力於打造雲原生時代的微服務治理平臺。

## 前情回顧

在介紹升級能力之前，先簡要回顧 MSE 產品的核心能力，分為開發態、測試態及執行態，其中在服務治理中較為常用的功能包括無損上下線、全鏈路灰度以及日常環境隔離三大功能。

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

-   **無損上下線方面**

支援小流量服務預熱，避免新啟動應用被流量擊垮；而預熱模型支援動態調節，可滿足複雜場景需求；並且，預熱過程支援關聯 Kubernetes 檢查。

-   **全鏈路灰度方面**

可進行泳道設定，支援閘道器、RPC、RocketMQ 等；具備流量一鍵動態切流能力，可透過監控檢視切流效果；此外，提供了端到端的穩定基線環境，方便使用者快速、安全地驗證新版本。

-   **日常環境隔離功能**

流量在 feature 環境內流轉，實現高效的敏捷開發；各環境邏輯隔離，只需要維護一套基線環境，大幅降低成本；在 IDEA 中使用 Cloud Toolkit 的端雲互聯，可將本機啟動的應用接入到開發環境，降低開發調測成本。

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

下面介紹流量治理、資料庫治理及同 AZ 優先解決的問題和具體方案。

## 限流降級全面升級為流量治理

對應流量治理模型在流量防護方面形成可擴充閉環，圍繞系統線上環境可能出現的各種問題，進行有效治理。模型始於‘故障識別’，發現不同層次的問題，如介面層的狀態碼與異常型別、作業系統層的指標異常；在識別出問題後，發出異常告警，方便使用者進行針對性的流量治理，如進行自適應限流防護或場景化限流防護；防護規則設定後，系統便按照預設的閾值與防護手段保護系統，而系統防護的效果可透過監控檢視，另一方面，也可透過監控反向審視流量防護規則設定的合理性，及時調整。

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

對於首次接入無歷史資料參考的情況，可透過系統壓測的方式，結合業務場景設定壓測引數，為線上可能出現的問題配置流量治理規則，做好防護策略。

### 單機流量防護

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

首先看流量控制，其原理是監控應用或服務流量的 QPS 指標，當指標達到設定的閾值時立即攔截流量，避免應用被瞬時的流量高峰沖垮，從而保障應用高可用性。本產品提供了提供單機限流、叢集流控、分鐘小時限流、關聯限流等多種限流方式，支援滑動視窗、令牌桶、漏斗桶多種限流演算法。

對於併發控制，當強依賴的方法或介面出現不穩定的時候，可以透過配置併發執行緒數來限制不穩定的強依賴併發數，起到隔離異常的效果。若執行該請求的響應時間變長，會導致執行緒的併發數變大。當併發數超過閾值以後，AHAS 將拒絕多餘的請求，直到堆積的任務完成，併發執行緒數變少。達到將異常隔離，減小不穩定性的效果。

在系統保護方面，支援自適應流控或手動設定系統規則，自適應流控是根據系統的 CPU 使用率自動動態地調整應用程式的入口流量；系統規則是從整體維度手動設定規則，對應用入口流量進行控制。目的都是為了讓系統的入口流量和系統的負載達到一個平衡，保證系統在最大吞吐量狀態下穩定執行。

熔斷防護可以監控應用內部或者下游依賴的響應時間或異常比例，當達到指定的閾值時立即降低下游依賴的優先順序。在指定的時間內，系統不會呼叫該不穩定的資源，避免應用受到影響，從而保障應用高可用性。當指定時間過後，再重新恢復對該資源的呼叫。

主動降級防護可以指定對某些介面進行降級，被降級的介面會觸發自定義的降級行為（如返回指定內容）而不會執行原有的邏輯。

熱點防護透過分析資源呼叫過程中的呼叫次數較高的引數，並根據配置的熱點規則對包含熱點引數的資源呼叫進行限流，保護系統穩定性。

最後，當系統遇到一些非致命性的錯誤（如偶現的超時等）時，可以透過自動重試的方式來避免系統最終失敗。

### 叢集流量防護

其中叢集流量防護用於解決單機流控存在流量不均勻、機器數頻繁變動以及均攤閾值太小的情況導致限流效果不佳的問題，叢集流控可以精確地控制某個服務介面在整個叢集的實時呼叫總量。較適用於以下場景：

**1. 服務呼叫流量不均，需要緩解的情況**

流量到每臺服務例項不均衡導致單機限流不夠精確（總量上“提前限流”），從而無法精確控制總量

**2. 叢集小流量精確場景**

對叢集總流量限制比較小的情況，單機限流將失效（比如某個介面每秒總量不超過 10QPS，但機器數為 50 臺，即便單機閾值設為 1，仍會超出閾值）

**3. 業務叢集流控**

對於有業務含義的分鐘小時級流量控制，可保護下游系統不被（如閘道器層限制每個使用者每分鐘呼叫某個 API 不能超過多少次）壓垮。

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

叢集流控具有場景豐富、使用成本低以及全自動管控等優勢：

**場景豐富**：全面覆蓋從閘道器入口流量精確防護、Web/RPC 服務呼叫精確流控到分鐘小時級業務維度流量控制的場景

**低使用成本**：無需特殊接入方式，開箱即用

**全自動管控**：自動化管控與分配 server 資源，自動化運維能力保障可用性，無需使用者關注資源準備與分配細節，只需關注業務

### 閘道器流量防護

閘道器流量防護則用於精確控制某個或某組 API 的流量，起到提前保護的作用，使多餘流量不會打到後端系統。如果按照單機維度配置，一方面閘道器機器數變化難以感知，另一方面閘道器流量不均可能導致限流效果不佳。

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

閘道器防護具備四點核心能力：

1. API/Host 維度的實時監控與流量控制

2. 動態規則配置，實時生效

3. 叢集流量控制，精確控制 API 呼叫總量

4. 請求引數/header 維度的流控、熔斷

### 全鏈路&多語言

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

MSE 升級後的流量治理可應用於微服務的全鏈路，比如在流量入口層，可透過閘道器方式接入、在微服務層面不僅可保護微服務自身，也可以保護微服務依賴的中介軟體、如快取、資料庫等三方依賴、若您透過 ACK 或者 Agent 方式接入，則無需改造一行程式碼即可輕鬆接入，若您有高階流量治理的需求，如自定義埋點，可透過 SDK 方式接入。

## 全新的資料庫治理能力

### 典型治理場景

-   某系統對外提供某查詢介面，SQL 語句涉及多表 join，某些情況下會觸發慢查詢，耗時長達 30s，最終導致 DB 連線池/Tomcat 執行緒池滿，應用整體不可用。

-   應用剛啟動，由於資料庫 Druid 連線池還在初始化中，但是此時已經大量請求進入，迅速導致 Dubbo 的執行緒池滿，許多現場卡在初始化資料庫連線的過程中，導致業務請求大量報錯。

-   全鏈路灰度場景中，由於新的應用版本改了資料庫表的內容，灰度流量導致線上資料庫的資料錯亂，業務同學連夜手動訂正線上資料。

-   在專案初期沒有對 SQL 的效能做好考量，隨著業務的發展，使用者量級的增加，線上遺留老介面的 SQL 逐漸成為效能瓶頸，因此需要有有效的 SQL 洞察能力幫助我們發現遺留的 SQL，並及時進行效能最佳化。

-   SQL 語句處理時間比較長導致線上業務介面出現大量的慢呼叫，需要快速定位有問題的慢 SQL，並且透過一定的治理手段進行隔離，將業務快速恢復。因此在微服務訪問資料層時，實時的 SQL 洞察能力可以幫助我們快速定位慢的 SQL 呼叫。

其實針對大多數的後端應用來講，系統的瓶頸主要受限於資料庫，當然複雜度的業務肯定也離不開資料庫的操作。因此資料庫問題，也是優先順序最高的工作，資料庫治的理也是微服務治理中必不可少的一環。

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

### 核心解決方案

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

-   **慢 SQL 治理**

慢 SQL 是比較致命的影響系統穩定性的因素之一，系統中出現慢 SQL 可能會導致 CPU、負載異常和系統資源耗盡等情況。嚴重的慢 SQL 發生後可能會拖垮整個資料庫，對線上業務產生阻斷性的風險。線上生產環境出現慢 SQL 可能原因如下：

-   網路速度慢、記憶體不足、I/O 吞吐量小、磁碟空間被佔滿等硬體原因。
-   沒有索引或者索引失效。
-   系統資料過多。
-   在專案初期沒有對 SQL 的效能做好考量。

-   **連線池治理**

連線池治理是資料庫治理中非常重要的一個環節，透過一些連結池的實時指標，我們可以有效地提前識別系統中存在的風險，以下是一些常見的連線池治理的場景。

1. 提前建連

在應用釋出或者彈性擴容的場景下，如果剛啟動例項中的連線並有沒完成建立，但此時例項已經啟動完成，Readiness 檢查已經透過，意味著此時會有大量的業務流量進入新啟動的 pod。大量的請求阻塞在連線池獲取連線的動作上，導致服務的執行緒池滿，大量業務請求失敗。如果我們的應用具備提前建連的能力，那麼就可以在流量到達前，將連線請求數保證在 minIdle 之上，並且配合小流量預熱的能力，那麼就可以解決以上這個讓人頭疼的冷啟動問題了。

2. "壞"連線剔除

有時候連線池中會存在一些有問題的連線，可能是底層的網路出現了抖動，也有可能是執行的業務出現了慢、死鎖等問題。如果我們可以從連線池的視角出發，及時地發現異常的連線，並且進行及時地剔除與回收，那麼就可以保證連線池整體的穩定性，不至於被個別有問題的業務處理或者網路抖動給拖垮。

3. 訪問控制

理論上並不是全部資料庫表都可以隨便訪問的，在某些時候，有些重要的表可能對於一些不太重要的服務來說，我們希望它是一個禁寫、只讀的狀態，或者當資料庫出現抖動、執行緒池滿的情況下，我們希望減少一些耗時的讀庫 SQL 執行，又或者有一些敏感資料的表只允許某個應用去進行讀寫訪問。那麼我們就可以透過動態的訪問控制能力，實時下發訪問控制規則，來做到對於個別方法、應用的 SQL 面向資料庫例項、表的禁讀禁寫等黑白名單的訪問控制。

-   **資料庫灰度**

微服務體系架構中，服務之間的依賴關係錯綜複雜，有時某個功能發版依賴多個服務同時升級上線。我們希望可以對這些服務的新版本同時進行小流量灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，透過構建從閘道器到整個後端服務的環境隔離來對多個不同版本的服務進行灰度驗證。MSE 透過影子表的方式，使用者可以在不需要修改任何業務程式碼的情況下，實現資料庫層面全鏈路灰度。

-   **動態讀寫分離**

透過 MSE 提供的 SQL 洞察能力，結合我們對業務的理解，我們可以快速定位劃分介面請求為弱請求。將對主庫效能以及穩定性影響大的讀操作，分流至 RDS 只讀庫，可以有效降低主庫的讀寫壓力，進一步提升微服務應用的穩定性。

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

以上這些是 MSE 即將推出的一個資料庫治理能力的預告，我們從應用的視角出發整理抽象了我們在訪問、使用資料庫時場景的一些穩定性治理、效能最佳化、提效等方面的實戰經驗，對於每一個後端應用來說，資料庫無疑是重中之重，我們希望透過我們的資料庫治理能力，可以幫助到大家更好地使用資料庫服務。

## 同 AZ 優先

同城的特點是 RT 一般處在一個比較底的延遲（< 3ms 以內），所以在預設情況下，我們可以基於同城的不同機房搭建起來一個大的區域網，然後把我們應用跨機房分佈在多個機房中，以此來應對單機房出現故障時的流量受損風險。相比異地多活，這種基礎設施的建設成本較小，架構變動也比較小。不過在微服務體系之下，應用之間的鏈路錯綜複雜，隨著鏈路深度越來越深，治理的複雜度也會隨之增加，如下圖所示的場景就是前端流量很有可能因為在不同的機房相互呼叫而導致 RT 突增，最終導致流量損失。

### 使用場景

當應用部署在多個機房的時候，應用之間互相呼叫會出現跨機房的情況

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

機房 1 的 A 應用呼叫機房 2 的 B 應用，跨機房呼叫網路延時增加，導致 HTTP 響應時間增加。

開啟同機房優先後，consumer 會優先呼叫同機房的 provider 服務：

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

### 解決方案

根據路由規則，自動識別同可用區，並優先選擇同可用區減少呼叫時延，提升效能，並可實現容災場景下的流量切換，保障可用性。

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

## 結語

MSE 治理中心在限流降級、資料庫治理及同 AZ 優先方面的能力升級，有助於企業更便捷地做好系統彈性、及時感知系統 SQL 異常狀態，做好針對性治理與防護，同 AZ 優先可提升系統整體效能，構建強健而穩定的執行環境。本次升級是治理中心升級的第一階段，後續會不斷推出治理手段，為您的系統保駕護航。

MSE 註冊配置中心專業版首購享 9 折優惠，MSE 雲原生閘道器預付費全規格享 9 折優惠。點選[此處](https://www.aliyun.com/product/aliware/mse)，即享優惠！

MSE 治理中心重磅升級-流量治理、資料庫治理、同 AZ 優先

相關文章