*作者：十眠*

## 背景

在分散式系統架構中，業務的流量都是端到端的。每個請求都會經過很多層處理，比如從入口閘道器再到 Web Server 再到服務之間的呼叫，再到服務訪問快取或 DB 等儲存。

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

對於我們的系統來說，資料庫是非常重要的一塊。因此無論是在穩定性的治理上，還是在開發提效等場景下，資料庫相關的治理能力都是我們系統所需具備的能力。

以下列舉一些典型的資料庫相關的治理場景：

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

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

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

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

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

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

## 資料庫治理相關常見場景

下面總結了微服務訪問資料庫層時，在資料庫治理中的常見的一些場景與能力。

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

OpenSergo 領域中關於資料庫治理的概覽

### 慢 SQL 治理

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

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

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

對於線上常見的慢 SQL 問題，MSE 服務治理提供了場景化的解決方式。

-   **SQL 洞察**

MSE 提供了秒級的 SQL 呼叫監控：

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

我們可以觀察應用和資源 API 維度的實時資料（細化至秒級），同時 MSE 還提供了 SQL 的 TopN 列表，我們可以一眼看出 RT 高的 SQL 語句，快速定位應用變慢的根因。

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

我們透過 MSE 提供的 SQL 洞察能力，可以有效分析 SQL 語句是否寫得合理，以及 SQL 執行的併發、RT 是否符合系統表現的預期，根據這些 SQL 洞察的資料，從而可以有效地評估系統的整體表現，為流控降級規則的配置提供重要依據。

-   **SQL 的流控降級**

我們可以根據 MSE 自動識別的 SQL 語句，可以對出現慢 SQL 的應用配置執行緒數維度的流控或降級規則，當出現慢 SQL 呼叫時限制同一時刻執行的 SQL 數量，防止過多的慢 SQL 語句執行把資源耗盡。

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

關於 MSE 的 SQL 流控降級能力，MSE 支援配置流控、隔離、熔斷以及熱點限流等四種規則。

1、**流量控制**：透過流控能力，為服務介面配置流控規則，讓容量範圍內的請求透過，多餘的請求被拒絕，相當於安全氣囊的作用，可以有效保證 SQL 請求訪問的流量控制在系統容量的閾值內。

> 後面 MSE 將會提供庫、表維度聚合的 SQL 洞察能力，我們可以基於此能力控制指定資料庫、表的流量控制在預估的容量範圍內。

2、**併發隔離**：當流量近似穩態時：併發執行緒數 =QPS * RT(s)，其中 RT 升高，併發執行緒數升高，代表服務呼叫出現堆積。採用流量治理提供的服務併發隔離能力，給重要服務呼叫配置併發執行緒數限制，相當於一道“軟保險”，防止慢 SQL 或者不穩定的服務過多擠佔正常服務資源。

3、**熔斷降級**：業務高峰期，某些下游的服務提供者大量的資料訪問遇到效能瓶頸，出現大量的慢 SQL，甚至影響業務。我們對部分非關鍵服務的資料庫訪問配置自動熔斷規則，當一段時間內的慢呼叫比例或錯誤比例達到一定條件時自動觸發熔斷，後續一段時間服務呼叫直接返回 Mock 的結果，這樣既可以保障呼叫端不被堆積的資料訪問請求拖垮，從而保障整個業務鏈路的正常運轉。

4、**熱點流控**：透過**熱點引數流控能力**，自動識別 SQL 請求訪問引數中的 TopN 訪問熱度的引數值，並對這些引數進行單獨流控，避免單個熱點訪問過載；並且可以針對一些特殊熱點訪問（如極熱門的搶購單品）配置單獨的流控值。引數可以是 SQL 訪問中的任意帶有業務屬性的條件，如以下 tid 引數的值。

```
SELECT * FROM order WHERE tid = 1$
```

### 連線池治理

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

1、**提前建連**

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

2、 **"壞"連線剔除**

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

3、**訪問控制**

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

### 資料庫灰度

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

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

## 總結

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

***服務治理的標準 OpenSergo***

> Q：OpenSergo 是什麼？
> 
> A：OpenSergo 是一套開放、通用的、面向分散式服務架構、覆蓋全鏈路異構化生態的服務治理標準，基於業界服務治理場景與實踐形成服務治理通用標準。OpenSergo 的最大特點就是**以統一的一套配置/DSL/協議定義服務治理規則，面向多語言異構化架構，做到全鏈路生態覆蓋**。無論微服務的語言是 Java, Go, Node.js 還是其它語言，無論是標準微服務還是 Mesh 接入，從閘道器到微服務，從資料庫到快取，從服務註冊發現到配置，開發者都可以透過同一套 OpenSergo CRD 標準配置針對每一層進行統一治理管控，無需關注各框架、語言的差異點，降低異構化、全鏈路服務治理管控的複雜度

OpenSergo 也會在 9 月推出資料庫治理相關的標準，會進一步抽象與標準化資料庫治理相關的能力。目前 OpenSergo 社群正在聯合各個社群進行進一步的合作，透過社群來一起討論與定義統一的服務治理標準。當前社群也在聯合 bilibili、位元組跳動等企業一起共建標準，也歡迎感興趣的開發者、社群與企業一起加入到 OpenSergo 服務治理標準共建中。歡迎大家加入 OpenSergo 社群交流群（釘釘群）進行討論：34826335

點選[此處](https://opensergo.io/zh-cn/)，進入 OpenSergo 官網~

資料庫治理的探索與實踐

相關文章