How OpenSergo Unifies Microservice and Database Governance Across Languages

Classic microservice architectures separate service providers, consumers, and a registry, but as distributed systems grow, stability and usability problems emerge, requiring comprehensive governance that covers traffic control, fault tolerance, and security.

OpenSergo was launched in early 2022 by Alibaba, Bilibili, ByteDance and others to provide an open, universal governance framework that works across Java, Go, Rust, Node.js and other languages. It defines a single configuration/DSL/protocol for service‑level governance, allowing developers to apply consistent rules without dealing with each framework’s unique syntax.

Database Governance from a Microservice Perspective

Beyond inter‑service traffic, microservices also generate significant database traffic, which can cause CPU saturation, slow queries, connection‑pool exhaustion, and environment‑specific data isolation issues. Ensuring database stability is therefore a critical part of overall microservice governance.

Collaboration with ShardingSphere

OpenSergo partners with the ShardingSphere community to create a standardized database governance model. ShardingSphere contributes extensive best‑practice knowledge, filling gaps in OpenSergo’s database capabilities.

Core Abstractions

VirtualDatabase : a logical database representing read/write splitting, sharding, shadow tables, encryption, etc.

DatabaseEndpoint : the physical database instance bound to a VirtualDatabase.

DatabaseAccessTarget : criteria that match specific instances, tables, SQL patterns, or operation types, enabling fine‑grained traffic control.

Database Traffic Governance

OpenSergo reuses its traffic‑control spec (Target, Strategy, FallbackAction) for database traffic, allowing read/write routing, sharding, shadow tables, and encryption to be expressed uniformly.

ReadWriteSplitting : directs read queries to replicas and transactional reads/writes to the primary.

Sharding : routes data based on sharding keys or automatic algorithms.

Shadow (Data Isolation) : routes test or gray‑scale traffic to shadow databases/tables.

Encryption : rewrites SQL to encrypt/decrypt data according to defined rules.

Example: Read‑Write Splitting Rule

# VirtualDatabase configuration
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"
---
# Write datasource endpoint
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
---
# Read datasource endpoints (two replicas)
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
---
# Read‑Write Splitting configuration
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"

Example: Concurrency Limit for a Specific SQL

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

Additional Database Governance Capabilities

DatabaseDiscovery : automatically detects HA status changes and adjusts traffic strategies accordingly.

DistributedTransaction : declares distributed‑transaction configurations.

Outlook

OpenSergo will continue collaborating with ShardingSphere, Database Mesh, CloudWeGo, Kratos, Spring Cloud Alibaba, Dubbo and other ecosystems to implement the standards, develop control‑plane implementations, and provide multi‑language SDKs, driving the evolution of microservice‑centric database governance.