*作者：趙奕豪（宿何）*

## 為什麼需要微服務治理與 OpenSergo？

在經典微服務架構中，我們通常將服務呼叫中各角色劃分為三部分：服務提供者、服務消費者、註冊中心。經典的微服務架構可以解決微服務能調通、可以執行起來的問題。隨著分散式服務架構的不斷演進、業務規模的擴張，諸多複雜的穩定性與易用性問題顯現出來，這時候就需要一些手段來針對日益複雜的微服務架構進行“治理”。微服務治理就是透過流量治理、服務容錯、安全治理等技術手段來減少甚至避免釋出和管理大規模應用過程中遇到的穩定性問題，對微服務領域中的各個元件進行治理。服務提供者、消費者、註冊中心、服務治理，構成現代微服務架構中重要的幾環。

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

微服務治理是把微服務做穩做好的關鍵一環。但是，業界微服務治理存在概念不統一、配置形式不統一、能力不統一、多框架統一管控較為複雜等問題。比如我們希望配置流量灰度規則，在 Spring Cloud Alibaba 中可能需要透過 YAML 方式配置，在 Dubbo 中需要透過另一種配置格式進行配置，在 Istio 體系內中可能又需要透過 Istio CRD 的方式進行配置。**不同框架治理配置方式的不一致使得微服務統一治理管控的複雜度相當高**。另外，業界的各種框架支援的服務治理能力都不統一，且通常比較基礎，很多時候無法覆蓋生產級的場景。

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

基於上面這些痛點，阿里巴巴在 2022 年 1 月開始和 bilibili、位元組等企業討論服務治理如何規範化和更加普及，從而共同發起了 OpenSergo 專案。**OpenSergo 是開放通用的，覆蓋微服務及上下游關聯元件的微服務治理專案，從微服務的角度出發，涵蓋流量治理、服務容錯、服務元資訊治理、安全治理等關鍵治理領域，提供一系列的治理能力與標準、生態適配與最佳實踐，支援 Java, Go, Rust 等多語言生態**。OpenSergo 的最大特點就是以統一的一套配置/DSL/協議定義服務治理規則，面向多語言異構化架構，覆蓋微服務框架及上下游關聯元件。無論微服務的語言是 Java, Go, Node.js 還是其它語言，無論是標準微服務還是 Mesh 接入，從閘道器到微服務呼叫，再到微服務對資料庫/快取的訪問，開發者都可以透過同一套 OpenSergo CRD 標準配置進行統一的治理管控，而無需關注各框架、語言的差異點，降低異構化、全鏈路微服務治理管控的複雜度。

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

OpenSergo 提供 Java、Go 等多語言的 SDK，各個框架生態可以非常方便地透過 OpenSergo SDK 來對接 OpenSergo 標準配置，接入到 OpenSergo 生態中，透過 OpenSergo 控制平面 (Control Plane) 統一管理服務治理規則。

## 微服務視角的資料庫治理是保障服務穩定性的關鍵一環

提到“微服務治理”，很多開發者會首先想到針對微服務之間的呼叫流量進行治理，但很多時候大家容易忽視掉微服務訪問儲存與其它中介軟體的這部分流量。在一個真實的業務生產環境中，流量首先先進入入口閘道器（如 Nginx、Envoy），再流轉到後端 Web Server，再流轉到微服務之間的 RPC 呼叫，再流轉到針對資料庫、快取、訊息等儲存/中介軟體的訪問。在這樣一個全鏈路的架構中，僅僅關注微服務之間的呼叫是不夠的，我們需要針對鏈路中的每一環分別進行針對性的治理。其中微服務對資料庫的訪問是非常普遍的，也是容易出現穩定性問題的一環。比如：

-   某個應用某類報表 SQL 訪問量非常大，且查詢非常消耗效能，把資料庫 CPU 打滿
-   慢 SQL 訪問非常多，佔滿連線池/業務執行緒池，導致服務無法處理正常請求，甚至導致級聯雪崩
-   連線池引數配置不合理，導致大量 SQL 寫操作時無法有效獲取連線，業務大量報錯
-   資料庫訪問需要按環境標進行隔離，比如灰度資料寫入到灰度表中

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

對於大多數的後端應用來講，系統效能擴充套件的瓶頸主要受限於資料庫。尤其在微服務的環境下，資料庫的效能治理問題往往也是團隊優先順序最高的幾類工作之一，資料庫治理自然也成為微服務治理中必不可少的一環。我們期望開發者可以結合資料庫治理能力，來保障微服務訪問資料庫的穩定性（保護微服務自身不被拖垮），同時也保障資料庫的穩定性。

## OpenSergo 聯合 ShardingSphere 社群共建資料庫治理標準

基於以上背景，OpenSergo 社群期望結合企業與開源社群的經驗，抽出一套通用的、從微服務視角出發的資料庫治理標準規範。ShardingSphere 作為資料庫治理領域的標杆專案，沉澱了非常豐富的最佳實踐與技術經驗，可以很好地為 OpenSergo 補充資料庫治理領域的空缺。**因此 OpenSergo 社群聯合 ShardingSphere 社群共建微服務視角的資料庫治理標準，擴充治理邊界，讓社群能夠以標準化的方式針對不同資料層框架與流量進行統一治理管控，共同推進治理領域技術與生態演進。**

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

對於此次 OpenSergo 與 ShardingSphere 社群之間的合作，雙方社群負責人都對此次合作表達了自己的觀點：

在微服務領域，服務間的互動與協作已日臻完善，而服務對資料庫的訪問卻依然缺失行之有效的標準。ShardingSphere 自開源以來，一直持續不斷的踐行著“連線、增強、可插拔”的設計哲學。其中，“連線”則是希望提供標準化的協議和介面，打破開發語言訪問異構資料庫的壁壘。OpenSergo 提出了微服務治理的標準，並首次將資料庫的訪問放在了標準中，非常具備前瞻性。作為訪問資料庫重要入口的微服務，我非常希望 ShardingSphere 和 OpenSergo 共建標準。

**——Apache ShardingSphere PMC Chair 張亮**

在微服務治理領域中，除了微服務本身的治理之外，針對資料庫訪問的治理也是保障業務可靠性與連續性的關鍵一環。ShardingSphere 作為資料庫治理領域的標杆專案，沉澱了非常豐富的最佳實踐與技術經驗，可以很好地為 OpenSergo 補充資料庫治理領域的空缺。因此我們聯合 ShardingSphere 社群共建微服務視角的資料庫治理標準，擴充治理邊界，期待讓社群能夠以標準化的方式針對不同資料層框架與流量進行統一治理管控，共同推進治理領域技術與生態演進。

**——OpenSergo && Sentinel 社群負責人 趙奕豪（宿何）**

OpenSergo 微服務視角的資料庫治理標準主要包括以下幾部分：

### 對資料庫 workload 及訪問物件的抽象

在治理規則中，我們通常需要指定規則作用的資料庫例項（或例項組），或者滿足的 SQL 條件。針對這一部分，我們在 OpenSergo 資料庫治理標準中針對資料庫 target workload 及訪問物件進行了一些抽象。

-   **虛擬資料庫 (VirtualDatabase)** ：在資料庫治理中，不管是讀寫分離、分庫分表、影子庫，還是加密、審計和訪問控制等，都需要作用在一個具體的資料庫之上。在這裡將這樣的一個邏輯的資料庫稱為虛擬資料庫，即 VirtualDatabase。VirtualDatabase 在應用看來是一組特定的資料庫訪問資訊，並透過繫結特定的治理策略實現相應的治理能力

-   **資料庫端點 (DatabaseEndpoint)** ：在資料庫治理中，透過 VirtualDatabase 嚮應用宣告瞭可以使用的邏輯資料庫，而資料的真實儲存則依賴於這樣的一個物理的資料庫，這裡稱為資料庫訪問端點，即 DatabaseEndpoint。DatabaseEndpoint 對應用無感知，它只能被 VirtualDatabase 透過特定治理策略所繫結然後連線和使用。

針對訪問物件的條件抽象：

-   **資料庫訪問物件 (DatabaseAccessTarget)** ：定義一組匹配條件，如針對某個例項/庫/表的訪問、針對某類 SQL 性質（讀/寫操作）、按 SQL pattern 匹配、按 SQL 引數匹配等。將 DatabaseAccessTarget 與具體的治理規則結合，我們可以實現細粒度的資料庫流量治理。

### 流量治理在資料庫訪問的體現

在微服務對資料庫的訪問中，流量路由、流量隔離、流控降級與容錯等相關流量治理能力是資料庫治理中非常重要的一塊。

在流控降級與容錯領域，我們複用了 OpenSergo 流控降級與容錯標準。OpenSergo 流控降級與容錯 spec 定義了三要素：Target（針對怎樣的流量）、Strategy（對應怎樣的流量治理策略）、FallbackAction（觸發策略之後的行為）。在針對資料庫訪問的治理中，我們將流量條件抽象為 DatabaseAccessTarget，結合 OpenSergo 自有的流控、併發控制、熔斷等策略，即可以實現細粒度的流控降級與容錯。

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

同時資料庫流量治理體系中還有一些關鍵的、資料庫領域特有的治理能力：

-   **讀寫流量路由 (ReadWriteSplitting)** ：讀寫分離是常用的資料庫擴充套件方式之一，主庫用於事務性的讀寫操作，從庫主要用於查詢等操作。讀寫流量路由規則可以指定將讀 SQL 路由到讀庫，事務性的讀寫操作路由到主庫。

-   **分庫分表路由 (Sharding)** ：資料分片路由是基於資料屬性一種擴充套件策略，對資料屬性進行計算後將請求路由到特定的資料後端，目前分為分片鍵分片和自動分片。其中分片鍵分片中需要指明需要分片的表、列、以及進行分片的演算法。

-   **資料流量隔離 (影子庫表 Shadow)** ：影子庫表可以幫助在灰度環境或者測試環境中，接收灰度流量或者測試資料請求，結合影子演算法等靈活配置多種路由方式。

-   **資料加密 (Encryption)** ：企業往往因為安全審計和合規的要求，需要對資料儲存提供多種安全加固措施，比如資料加密。資料加密透過對使用者輸入的 SQL 進行解析，並依據使用者提供的加密規則對 SQL 進行改寫，從而實現對原文資料進行加密，並將原文資料（可選）及密文資料同時儲存到底層資料庫。在使用者查詢資料時，它僅從資料庫中取出密文資料，並對其解密，最終將解密後的原始資料返回給使用者。

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

以下是一個讀寫流量路由規則的示例：

```
# 虛擬資料庫配置
apiVersion: database.opensergo.io/v1alpha1
kind: VirtualDatabase
metadata:
  name: readwrite_splitting_db
spec:
  services:
  - name: readwrite_splitting_db
    databaseMySQL:
      db: readwrite_splitting_db
      host: localhost
      port: 3306
      user: root
      password: root
    readWriteSplitting: "readwrite"  # 宣告所需要的讀寫分離策略
---
# 寫資料來源的資料庫端點配置
apiVersion: database.opensergo.io/v1alpha1
kind: DatabaseEndpoint
metadata:
  name: write_ds
spec:
  database:
    MySQL:                 # 宣告後端資料來源的型別及相關資訊
      url: jdbc:mysql://192.168.1.110:3306/demo_write_ds?serverTimezone=UTC&useSSL=false
      username: root
      password: root
      connectionTimeout: 30000
      idleTimeoutMilliseconds: 60000
      maxLifetimeMilliseconds: 1800000
      maxPoolSize: 50
      minPoolSize: 1
---
# 第一個讀資料來源的資料庫端點配置
apiVersion: database.opensergo.io/v1alpha1
kind: DatabaseEndpoint
metadata:
  name: read_ds_0
spec:
  database:
    MySQL:                 # 宣告後端資料來源的型別及相關資訊
      url: jdbc:mysql://192.168.1.110:3306/demo_read_ds_0?serverTimezone=UTC&useSSL=false
      username: root
      password: root
      connectionTimeout: 30000
      idleTimeoutMilliseconds: 60000
      maxLifetimeMilliseconds: 1800000
      maxPoolSize: 50
      minPoolSize: 1      
---
# 第二個讀資料來源的資料庫端點配置
apiVersion: database.opensergo.io/v1alpha1
kind: DatabaseEndpoint
metadata:
  name: read_ds_1
spec:
  database:
    MySQL:                              # 宣告後端資料來源的型別及相關資訊
      url: jdbc:mysql://192.168.1.110:3306/demo_read_ds_1?serverTimezone=UTC&useSSL=false
      username: root
      password: root
      connectionTimeout: 30000
      idleTimeoutMilliseconds: 60000
      maxLifetimeMilliseconds: 1800000
      maxPoolSize: 50
      minPoolSize: 1
---
# 靜態讀寫分離配置
apiVersion: database.opensergo.io/v1alpha1
kind: ReadWriteSplitting
metadata:
  name: readwrite
spec:
  rules:
    staticStrategy:
      writeDataSourceName: "write_ds"
      readDataSourceNames: 
      - "read_ds_0"
      - "read_ds_1"
      loadBalancerName: "random"
    loadBalancers:
    - loadBalancerName: "random"
      type: "RANDOM
```

以下是一個針對某個 SQL 進行併發控制的示例。這個規則會針對 foo 應用針對 SELECT * FROM users WHERE id = ? 的 SQL 訪問進行併發控制，單機併發數不超過 8。

```
apiVersion: traffic.opensergo.io/v1alpha1
kind: DatabaseAccessTarget
metadata:
  name: target-foo-user-select-sql
spec:
  sqlMatch:
    - exactMatch: "SELECT * FROM users WHERE id = ?"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: ConcurrencyLimitStrategy
metadata:
  name: concurrency-limit-foo
spec:
  maxConcurrency: 8
  limitMode: 'Local'
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
  name: my-sql-conc-limit-rule
spec:
  selector:
    app: foo
  targets:
    - targetRef: target-foo-user-select-sql
  strategies: 
    - name: concurrency-limit-foo
```

### 其它資料庫治理能力

-   **資料庫發現 (DatabaseDiscovery)** ：資料庫自動發現指的是根據資料庫高可用配置，透過探測的方式感知資料來源狀態變化，並對流量策略做出相應的調整。比如後端資料來源為 MySQL MGR，那麼可以配置資料庫發現型別為 MYSQL.MGR，指定 group-name，並配置相應的探測心跳節律。

-   **分散式事務配置 (DistributedTransaction)** ：宣告分散式事務相關的配置，目前支援宣告事務的型別。

## 展望

微服務視角的資料庫治理是保障微服務穩定性的重要一環。OpenSergo 社群將持續與 ShardingSphere 及 Database Mesh 社群進行合作，不斷完善與豐富資料庫治理標準及場景。接下來社群會開展 ShardingSphere 與 OpenSergo 的整合工作，將資料庫治理 spec 落地到社群實現。

微服務治理是微服務改造深入到一定階段之後的必經之路，是將微服務做穩做好的關鍵。OpenSergo 社群持續與 ShardingSphere、Database Mesh、CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo 等社群共同建設 OpenSergo 微服務治理標準，將企業與社群中微服務治理的場景與最佳實踐共同提取成標準規範，也歡迎更多社群與企業一起參與 OpenSergo 微服務治理標準的共建。

OpenSergo 社群現在處於高速發展階段，從微服務治理標準定義，到 Control Plane 的實現，再到 Java/Go/C++/Rust 等多語言 SDK 與治理功能的實現，再到各個微服務生態的整合與落地，都還有大量的演進工作，歡迎社群一起參與標準完善與程式碼貢獻。OpenSergo 開源貢獻小組正在火熱招募貢獻者。

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

如果您有時間，有熱情，有意願，歡迎聯絡社群加入開源貢獻小組，一起共同完善 OpenSergo 和 Sentinel，一起主導微服務治理技術與標準演進。Now let's start hacking! 
  
我們在阿里雲也提供 MSE 資料庫治理產品，從 SQL 洞察、慢 SQL 治理、讀寫流量治理、資料流量隔離等方面來保障微服務訪問資料庫的穩定性，歡迎大家瞭解與體驗：

> <https:>

## *相關連結 *

*OpenSergo 官網：*

*<https:></https:>*

*ShardingSphere 官網：*

*<https:></https:>*</https:>

OpenSergo & ShardingSphere 社群共建微服務視角的資料庫治理標準

相關文章