作者：流士
本次 MSE 治理中心在限流降級、數據庫治理及同 AZ 優先方面進行了重磅升級，對微服務治理的彈性、依賴中間件的穩定性及流量調度的性能進行全面增強，致力於打造雲原生時代的微服務治理平臺。
前情回顧
在介紹升級能力之前，先簡要回顧 MSE 產品的核心能力，分爲開發態、測試態及運行態，其中在服務治理中較爲常用的功能包括無損上下線、全鏈路灰度以及日常環境隔離三大功能。
- 無損上下線方面
支持小流量服務預熱，避免新啓動應用被流量擊垮；而預熱模型支持動態調節，可滿足複雜場景需求；並且，預熱過程支持關聯 Kubernetes 檢查。
- 全鏈路灰度方面
可進行泳道設置，支持網關、RPC、RocketMQ 等；具備流量一鍵動態切流能力，可通過監控查看切流效果；此外，提供了端到端的穩定基線環境，方便用戶快速、安全地驗證新版本。
- 日常環境隔離功能
流量在 feature 環境內流轉，實現高效的敏捷開發；各環境邏輯隔離，只需要維護一套基線環境，大幅降低成本；在 IDEA 中使用 Cloud Toolkit 的端雲互聯，可將本機啓動的應用接入到開發環境，降低開發調測成本。
下面介紹流量治理、數據庫治理及同 AZ 優先解決的問題和具體方案。
限流降級全面升級爲流量治理
對應流量治理模型在流量防護方面形成可拓展閉環，圍繞系統線上環境可能出現的各種問題，進行有效治理。模型始於‘故障識別’，發現不同層次的問題，如接口層的狀態碼與異常類型、操作系統層的指標異常；在識別出問題後，發出異常告警，方便用戶進行鍼對性的流量治理，如進行自適應限流防護或場景化限流防護；防護規則設置後，系統便按照預設的閾值與防護手段保護系統，而系統防護的效果可通過監控查看，另一方面，也可通過監控反向審視流量防護規則設置的合理性，及時調整。
對於首次接入無歷史數據參考的情況，可通過系統壓測的方式，結合業務場景設置壓測參數，爲線上可能出現的問題配置流量治理規則，做好防護策略。
單機流量防護
首先看流量控制，其原理是監控應用或服務流量的 QPS 指標，當指標達到設定的閾值時立即攔截流量，避免應用被瞬時的流量高峯沖垮，從而保障應用高可用性。本產品提供了提供單機限流、集羣流控、分鐘小時限流、關聯限流等多種限流方式，支持滑動窗口、令牌桶、漏斗桶多種限流算法。
對於併發控制，當強依賴的方法或接口出現不穩定的時候，可以通過配置併發線程數來限制不穩定的強依賴併發數，起到隔離異常的效果。若運行該請求的響應時間變長，會導致線程的併發數變大。當併發數超過閾值以後，AHAS 將拒絕多餘的請求，直到堆積的任務完成，併發線程數變少。達到將異常隔離，減小不穩定性的效果。
在系統保護方面，支持自適應流控或手動設置系統規則，自適應流控是根據系統的 CPU 使用率自動動態地調整應用程序的入口流量；系統規則是從整體維度手動設置規則，對應用入口流量進行控制。目的都是爲了讓系統的入口流量和系統的負載達到一個平衡，保證系統在最大吞吐量狀態下穩定運行。
熔斷防護可以監控應用內部或者下游依賴的響應時間或異常比例，當達到指定的閾值時立即降低下游依賴的優先級。在指定的時間內，系統不會調用該不穩定的資源，避免應用受到影響，從而保障應用高可用性。當指定時間過後，再重新恢復對該資源的調用。
主動降級防護可以指定對某些接口進行降級，被降級的接口會觸發自定義的降級行爲（如返回指定內容）而不會執行原有的邏輯。
熱點防護通過分析資源調用過程中的調用次數較高的參數，並根據配置的熱點規則對包含熱點參數的資源調用進行限流，保護系統穩定性。
最後，當系統遇到一些非致命性的錯誤（如偶現的超時等）時，可以通過自動重試的方式來避免系統最終失敗。
集羣流量防護
其中集羣流量防護用於解決單機流控存在流量不均勻、機器數頻繁變動以及均攤閾值太小的情況導致限流效果不佳的問題，集羣流控可以精確地控制某個服務接口在整個集羣的實時調用總量。較適用於以下場景：
1. 服務調用流量不均，需要緩解的情況
流量到每臺服務實例不均衡導致單機限流不夠精確（總量上“提前限流”），從而無法精確控制總量
2. 集羣小流量精確場景
對集羣總流量限制比較小的情況，單機限流將失效（比如某個接口每秒總量不超過 10QPS，但機器數爲 50 臺，即便單機閾值設爲 1，仍會超出閾值）
3. 業務集羣流控
對於有業務含義的分鐘小時級流量控制，可保護下游系統不被（如網關層限制每個用戶每分鐘調用某個 API 不能超過多少次）壓垮。
集羣流控具有場景豐富、使用成本低以及全自動管控等優勢：
場景豐富：全面覆蓋從網關入口流量精確防護、Web/RPC 服務調用精確流控到分鐘小時級業務維度流量控制的場景
低使用成本：無需特殊接入方式，開箱即用
全自動管控：自動化管控與分配 server 資源，自動化運維能力保障可用性，無需用戶關注資源準備與分配細節，只需關注業務
網關流量防護
網關流量防護則用於精確控制某個或某組 API 的流量，起到提前保護的作用，使多餘流量不會打到後端系統。如果按照單機維度配置，一方面網關機器數變化難以感知，另一方面網關流量不均可能導致限流效果不佳。
網關防護具備四點核心能力：
1. API/Host 維度的實時監控與流量控制
2. 動態規則配置，實時生效
3. 集羣流量控制，精確控制 API 調用總量
4. 請求參數/header 維度的流控、熔斷
全鏈路&多語言
MSE 升級後的流量治理可應用於微服務的全鏈路，比如在流量入口層，可通過網關方式接入、在微服務層面不僅可保護微服務自身，也可以保護微服務依賴的中間件、如緩存、數據庫等三方依賴、若您通過 ACK 或者 Agent 方式接入，則無需改造一行代碼即可輕鬆接入，若您有高階流量治理的需求，如自定義埋點，可通過 SDK 方式接入。
全新的數據庫治理能力
典型治理場景
-
某系統對外提供某查詢接口，SQL 語句涉及多表 join，某些情況下會觸發慢查詢，耗時長達 30s，最終導致 DB 連接池/Tomcat 線程池滿，應用整體不可用。
-
應用剛啓動，由於數據庫 Druid 連接池還在初始化中，但是此時已經大量請求進入，迅速導致 Dubbo 的線程池滿，許多現場卡在初始化數據庫連接的過程中，導致業務請求大量報錯。
-
全鏈路灰度場景中，由於新的應用版本改了數據庫表的內容，灰度流量導致線上數據庫的數據錯亂，業務同學連夜手動訂正線上數據。
-
在項目初期沒有對 SQL 的性能做好考量，隨着業務的發展，用戶量級的增加，線上遺留老接口的 SQL 逐漸成爲性能瓶頸，因此需要有有效的 SQL 洞察能力幫助我們發現遺留的 SQL，並及時進行性能優化。
-
SQL 語句處理時間比較長導致線上業務接口出現大量的慢調用，需要快速定位有問題的慢 SQL，並且通過一定的治理手段進行隔離，將業務快速恢復。因此在微服務訪問數據層時，實時的 SQL 洞察能力可以幫助我們快速定位慢的 SQL 調用。
其實針對大多數的後端應用來講，系統的瓶頸主要受限於數據庫，當然複雜度的業務肯定也離不開數據庫的操作。因此數據庫問題，也是優先級最高的工作，數據庫治的理也是微服務治理中必不可少的一環。
核心解決方案
- 慢 SQL 治理
慢 SQL 是比較致命的影響系統穩定性的因素之一，系統中出現慢 SQL 可能會導致 CPU、負載異常和系統資源耗盡等情況。嚴重的慢 SQL 發生後可能會拖垮整個數據庫，對線上業務產生阻斷性的風險。線上生產環境出現慢 SQL 可能原因如下：
-
網絡速度慢、內存不足、I/O 吞吐量小、磁盤空間被佔滿等硬件原因。
-
沒有索引或者索引失效。
-
系統數據過多。
-
在項目初期沒有對 SQL 的性能做好考量。
-
連接池治理
連接池治理是數據庫治理中非常重要的一個環節，通過一些鏈接池的實時指標，我們可以有效地提前識別系統中存在的風險，以下是一些常見的連接池治理的場景。
- 提前建連
在應用發佈或者彈性擴容的場景下，如果剛啓動實例中的連接並有沒完成建立，但此時實例已經啓動完成，Readiness 檢查已經通過，意味着此時會有大量的業務流量進入新啓動的 pod。大量的請求阻塞在連接池獲取連接的動作上，導致服務的線程池滿，大量業務請求失敗。如果我們的應用具備提前建連的能力，那麼就可以在流量到達前，將連接請求數保證在 minIdle 之上，並且配合小流量預熱的能力，那麼就可以解決以上這個讓人頭疼的冷啓動問題了。
- "壞"連接剔除
有時候連接池中會存在一些有問題的連接，可能是底層的網絡出現了抖動，也有可能是執行的業務出現了慢、死鎖等問題。如果我們可以從連接池的視角出發，及時地發現異常的連接，並且進行及時地剔除與回收，那麼就可以保證連接池整體的穩定性，不至於被個別有問題的業務處理或者網絡抖動給拖垮。
- 訪問控制
理論上並不是全部數據庫表都可以隨便訪問的，在某些時候，有些重要的表可能對於一些不太重要的服務來說，我們希望它是一個禁寫、只讀的狀態，或者當數據庫出現抖動、線程池滿的情況下，我們希望減少一些耗時的讀庫 SQL 執行，又或者有一些敏感數據的表只允許某個應用去進行讀寫訪問。那麼我們就可以通過動態的訪問控制能力，實時下發訪問控制規則，來做到對於個別方法、應用的 SQL 面向數據庫實例、表的禁讀禁寫等黑白名單的訪問控制。
- 數據庫灰度
微服務體系架構中，服務之間的依賴關係錯綜複雜，有時某個功能發版依賴多個服務同時升級上線。我們希望可以對這些服務的新版本同時進行小流量灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，通過構建從網關到整個後端服務的環境隔離來對多個不同版本的服務進行灰度驗證。MSE 通過影子表的方式，用戶可以在不需要修改任何業務代碼的情況下，實現數據庫層面全鏈路灰度。
- 動態讀寫分離
通過 MSE 提供的 SQL 洞察能力，結合我們對業務的理解，我們可以快速定位劃分接口請求爲弱請求。將對主庫性能以及穩定性影響大的讀操作，分流至 RDS 只讀庫，可以有效降低主庫的讀寫壓力，進一步提升微服務應用的穩定性。
以上這些是 MSE 即將推出的一個數據庫治理能力的預告，我們從應用的視角出發整理抽象了我們在訪問、使用數據庫時場景的一些穩定性治理、性能優化、提效等方面的實戰經驗，對於每一個後端應用來說，數據庫無疑是重中之重，我們希望通過我們的數據庫治理能力，可以幫助到大家更好地使用數據庫服務。
同 AZ 優先
同城的特點是 RT 一般處在一個比較底的延遲（< 3ms 以內），所以在默認情況下，我們可以基於同城的不同機房搭建起來一個大的局域網，然後把我們應用跨機房分佈在多個機房中，以此來應對單機房出現故障時的流量受損風險。相比異地多活，這種基礎設施的建設成本較小，架構變動也比較小。不過在微服務體系之下，應用之間的鏈路錯綜複雜，隨着鏈路深度越來越深，治理的複雜度也會隨之增加，如下圖所示的場景就是前端流量很有可能因爲在不同的機房相互調用而導致 RT 突增，最終導致流量損失。
使用場景
當應用部署在多個機房的時候，應用之間互相調用會出現跨機房的情況
機房 1 的 A 應用調用機房 2 的 B 應用，跨機房調用網絡延時增加，導致 HTTP 響應時間增加。
開啓同機房優先後，consumer 會優先調用同機房的 provider 服務：
解決方案
根據路由規則，自動識別同可用區，並優先選擇同可用區減少調用時延，提升性能，並可實現容災場景下的流量切換，保障可用性。
結語
MSE 治理中心在限流降級、數據庫治理及同 AZ 優先方面的能力升級，有助於企業更便捷地做好系統彈性、及時感知系統 SQL 異常狀態，做好針對性治理與防護，同 AZ 優先可提升系統整體性能，構建強健而穩定的運行環境。本次升級是治理中心升級的第一階段，後續會不斷推出治理手段，爲您的系統保駕護航。
MSE 註冊配置中心專業版首購享 9 折優惠，MSE 雲原生網關預付費全規格享 9 折優惠。點擊此處，即享優惠！