背景

在分布式系統架構中，業務的流量都是端到端的。每個請求都會經過很多層處理，比如從入口網關再到 Web Server 再到服務之間的調用，再到服務訪問緩存或 DB 等存儲。

對于我們的系統來說，數據庫是非常重要的一塊。因此無論是在穩定性的治理上，還是在開發提效等場景下，數據庫相關的治理能力都是我們系統所需具備的能力。下面總結了微服務訪問數據庫層時，在數據庫治理中的常見的一些場景與能力。

OpenSergo 領域中關于數據庫治理的概覽

本文將介紹 MSE 服務治理最近推出數據庫治理利器：無侵入實現數據庫訪問的讀寫分離能力。

什么是讀寫分離？

讀寫分離也就是將數據庫拆分為主庫和從庫，即主庫負責處理事務性的增刪改操作，從庫負責處理查詢操作的數據庫架構。

為什么要讀寫分離？

穩定性

一個大客戶的請求過來，查詢數據庫返回上萬條幾百 M 的數據，數據庫的 CPU 直接打滿。不知道大家是否遇到過類似的問題。

性能

在業務處理過程中，如果對數據庫的讀操作遠多于寫操作，同時業務上對于數據查詢結果的實時性要求不高（例如可以容忍秒級的延遲），那么在做系統性能優化時就可以考慮引入讀寫分離的方案，只讀庫可以承擔主庫的壓力，有效提升微服務應用的性能。

規模增長

隨著業務增長，到了一定規模之后再擴容，但很多都卡在擴容這一步，極大的限制了應對市場變化的速度，其中數據庫的擴容是最難的，目前常見的數據庫擴容方式有以下幾種方式：

• 垂直升級
• 分庫分表
• 讀寫分離

垂直升級需要中斷服務且高可用方面不及其它幾種方式，分庫分表在分區鍵的選擇上會是個難點，SQL 使用上會有諸多限制，同時對業務的改造也是非常大的工作量。相對來說讀寫分離是對業務的侵入最低也最容易實現擴容方案。根據經驗大多數應用的讀寫比都在 5:1 以上，有些場景甚至大量的高于 10:1，在對數據庫有少量寫請求，但有大量讀請求的應用場景下，單個實例可能無法承受讀取壓力，甚至對業務產生影響。

綜上所述數據庫讀寫分離方案可以滿足阿里云上大多數公司的穩定性治理、性能提升以及數據庫擴容的需求。

讀寫分離常見方案

目前業界流行的讀寫分離方案，通常都是基于上述主從模式的數據庫架構。讀寫分離的實現方案多數是通過引入 odp、mycat 等數據訪問代理產品，通過其讀寫分離功能來幫助實現讀寫分離。引入數據訪問代理的好處是源程序不需要做任何改動就可以實現讀寫分離，壞處是由于多了一層中間件做中轉代理，性能上會有所下降，數據訪問代理也容易成為性能瓶頸。

ShardingSphere 讀寫分離方案[1]（摘自 shardingsphere 官網）

ShardingSphere[2] 的讀寫分離主要依賴內核的相關功能。包括解析引擎和路由引擎。解析引擎將用戶的 SQL 轉化為 ShardingSphere 可以識別的 Statement 信息，路由引擎根據 SQL 的讀寫類型以及事務的狀態來做 SQL 的路由。如下圖所示，ShardingSphere 識別到讀操作和寫操作，分別會路由至不同的數據庫實例。

MSE 數據庫讀寫分離能力

MSE 提供了一種動態數據流量治理的方案，您可以在不需要修改任何業務代碼的情況下，實現數據庫的讀寫分離能力。下面介紹 MSE 基于 Mysql 數據存儲通過的讀寫分離能力。

前提條件

• 應用接入 MSE
• 部署 Demo 應用

在阿里云容器服務中部署 A、B、C 三個應用，并且將應用均接入 MSE 服務治理[3]，用于增加具備數據庫治理能力的 Agent。

• 創建 RDS 只讀實例[4]

我們需要創建 RDS 只讀實例，利用只讀實例滿足大量的數據庫讀取需求，增加應用的吞吐量。

配置讀寫分離規則

• 我們需要配置以下環境變量來額外開啟/配置數據庫的讀寫分離能力

• 我們可以通過控制臺配置弱讀請求的規則或者指定某些接口為弱讀請求

apiVersion: database.opensergo.io/v1alpha1
kind: AccessControlRule
metadata:
  name: read-only-control-rule
  labels:
    app: foo
spec:
  selector:
    app: foo
  target: 
    - resource:
        path: '/getLocation'
  controlStrategies:
    weak: true

上述 OpenSergo 標準的規則表示 /getLocation 接口的請求為弱讀請求。

我們針對一些大數據量查詢、對延時不太敏感的業務請求可以配置為 weak 類型

SQL 洞察

如上只需輕松的兩步我們就實現了數據庫的讀寫分離能力。基于數據庫讀寫分離能力，配合 MSE 數據庫治理的 SQL 洞察我們可以快速定位 RT 過大的查詢請求，幫助我們進一步分析 SQL 對我們數據庫穩定性的影響。

我可以觀察應用和資源 API 維度的 SQL 請求實時數據（細化至秒級），同時 MSE 還提供了 SQL 的 topN 列表，我們可以一眼看出 RT 高，查詢返回值數據量大的 SQL 語句。

總結

本文詳細描述了 MSE 即將推出的數據庫治理能力矩陣中關于動態讀寫分離能力的介紹。通過 MSE 提供的 SQL 洞察能力，結合我們對業務的理解，我們可以快速定位劃分接口請求為弱請求。將對主庫性能以及穩定性影響大的讀操作，分流至 RDS 只讀庫，可以有效降低主庫的讀寫壓力，進一步提升微服務應用的穩定性。

我們從應用的視角出發，抽象了我們在訪問以及使用數據庫時的一些常見場景以及對應的治理能力，整理了我們在穩定性治理、性能優化、提效等方面的實戰經驗。對于每一個后端應用來說，數據庫無疑是重中之重，我們希望通過我們的數據庫治理能力，可以幫助到大家更好地使用數據庫服務。

最后提一下服務治理的標準 OpenSergo：

Q：OpenSergo[5] 是什么
A：OpenSergo 是一套開放、通用的、面向分布式服務架構、覆蓋全鏈路異構化生態的服務治理標準，基于業界服務治理場景與實踐形成服務治理通用標準。OpenSergo 最大特點就是以統一一套配置/DSL/協議定義服務治理規則，面向多語言異構化架構，做到全鏈路生態覆蓋。無論微服務的語言是 Java, Go, Node.js 或其它語言，無論是標準微服務或 Mesh 接入，從網關到微服務，從數據庫到緩存，從服務注冊發現到配置，開發者都可以通過同一套 OpenSergo CRD 標準配置針對每一層進行統一的治理管控，而無需關注各框架、語言的差異點，降低異構化、全鏈路服務治理管控的復雜度