資料庫治理利器:動態讀寫分離

語言: CN / TW / HK

背景

Cloud Native

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

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

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

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

什麼是讀寫分離?

Cloud Native

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

為什麼要讀寫分離?

Cloud Native

穩定性

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

效能

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

規模增長

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

  • 垂直升級

  • 分庫分表

  • 讀寫分離

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

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

讀寫分離常見方案

Cloud Native

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

ShardingSphere 讀寫分離方案 [ 1] (摘自 shardingsphere 官網)

ShardingSphere [ 2] 的讀寫分離主要依賴核心的相關功能。包括解析引擎和路由引擎。解析引擎將使用者的 SQL 轉化為 ShardingSphere 可以識別的 Statement 資訊,路由引擎根據 SQL 的讀寫型別以及事務的狀態來做 SQL 的路由。如下圖所示,ShardingSphere 識別到讀操作和寫操作,分別會路由至不同的資料庫例項。

MSE 資料庫讀寫分離能力

Cloud Native

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 語句。

總結

Cloud Native

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

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

最後提一下服務治理的標準 OpenSergo:

Q: OpenSergo [ 5] 是什麼

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

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

參考連結:

[1]  ShardingSphere 讀寫分離方案

https://shardingsphere.apache.org/document/current/cn/features/readwrite-splitting/

[2]  ShardingSphere

https://shardingsphere.apache.org/document/current/en/overview/

[3]  接入 MSE 服務治理

https://help.aliyun.com/document_detail/425896.html

[4]  建立 RDS 只讀例項

https://help.aliyun.com/document_detail/26136.html

[5]  OpenSergo:

https://opensergo.io/zh-cn/