关于阿里云:OpenSergo-ShardingSphere-社区共建微服务视角的数据库治理标准

作者：赵奕豪（宿何）

在经典微服务架构中，咱们通常将服务调用中各角色划分为三局部：服务提供者、服务消费者、注册核心。经典的微服务架构能够解决微服务能调通、能够运行起来的问题。随着分布式服务架构的一直演进、业务规模的扩张，诸多简单的稳定性与易用性问题显现出来，这时候就须要一些伎俩来针对日益简单的微服务架构进行“治理”。微服务治理就是通过流量治理、服务容错、平安治理等技术手段来缩小甚至防止公布和治理大规模利用过程中遇到的稳定性问题，对微服务畛域中的各个组件进行治理。服务提供者、消费者、注册核心、服务治理，形成古代微服务架构中重要的几环。

微服务治理是把微服务做稳做好的要害一环。然而，业界微服务治理存在概念不对立、配置模式不对立、能力不对立、多框架对立管控较为简单等问题。比方咱们心愿配置流量灰度规定，在 Spring Cloud Alibaba 中可能须要通过 YAML 形式配置，在 Dubbo 中须要通过另一种配置格局进行配置，在 Istio 体系内中可能又须要通过 Istio CRD 的形式进行配置。 不同框架治理配置形式的不统一使得微服务对立治理管控的复杂度相当高 。另外，业界的各种框架反对的服务治理能力都不对立，且通常比拟根底，很多时候无奈笼罩生产级的场景。

基于下面这些痛点，阿里巴巴在 2022 年 1 月开始和 bilibili、字节等企业探讨服务治理如何规范化和更加遍及，从而独特发动了 OpenSergo 我的项目。OpenSergo 是凋谢通用的，笼罩微服务及上下游关联组件的微服务治理我的项目，从微服务的角度登程，涵盖流量治理、服务容错、服务元信息治理、平安治理等要害治理畛域，提供一系列的治理能力与规范、生态适配与最佳实际，反对 Java, Go, Rust 等多语言生态。OpenSergo 的最大特点就是以对立的一套配置 /DSL/ 协定定义服务治理规定，面向多语言异构化架构，笼罩微服务框架及上下游关联组件。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是规范微服务还是 Mesh 接入，从网关到微服务调用，再到微服务对数据库 / 缓存的拜访，开发者都能够通过同一套 OpenSergo CRD 标准配置进行对立的治理管控，而无需关注各框架、语言的差别点，升高异构化、全链路微服务治理管控的复杂度。

OpenSergo 提供 Java、Go 等多语言的 SDK，各个框架生态能够十分不便地通过 OpenSergo SDK 来对接 OpenSergo 标准配置，接入到 OpenSergo 生态中，通过 OpenSergo 管制立体 (Control Plane) 对立治理服务治理规定。

提到“微服务治理”，很多开发者会首先想到针对微服务之间的调用流量进行治理，但很多时候大家容易漠视掉微服务拜访存储与其它中间件的这部分流量。在一个实在的业务生产环境中，流量首先先进入入口网关（如 Nginx、Envoy），再流转到后端 Web Server，再流转到微服务之间的 RPC 调用，再流转到针对数据库、缓存、音讯等存储 / 中间件的拜访。在这样一个全链路的架构中，仅仅关注微服务之间的调用是不够的，咱们须要针对链路中的每一环别离进行针对性的治理。其中微服务对数据库的拜访是十分广泛的，也是容易呈现稳定性问题的一环。比方：

某个利用某类报表 SQL 访问量十分大，且查问十分耗费性能，把数据库 CPU 打满
慢 SQL 拜访十分多，占满连接池 / 业务线程池，导致服务无奈解决失常申请，甚至导致级联雪崩
连接池参数配置不合理，导致大量 SQL 写操作时无奈无效获取连贯，业务大量报错
数据库拜访须要按环境标进行隔离，比方灰度数据写入到灰度表中

对于大多数的后端利用来讲，零碎性能扩大的瓶颈次要受限于数据库。尤其在微服务的环境下，数据库的性能治理问题往往也是团队优先级最高的几类工作之一，数据库治理天然也成为微服务治理中必不可少的一环。咱们冀望开发者能够联合数据库治理能力，来保障微服务拜访数据库的稳定性（爱护微服务本身不被拖垮），同时也保障数据库的稳定性。

基于以上背景，OpenSergo 社区冀望联合企业与开源社区的教训，抽出一套通用的、从微服务视角登程的数据库治理标准规范。ShardingSphere 作为数据库治理畛域的标杆我的项目，积淀了十分丰盛的最佳实际与技术教训，能够很好地为 OpenSergo 补充数据库治理畛域的空缺。因而 OpenSergo 社区联结 ShardingSphere 社区共建微服务视角的数据库治理规范，裁减治理边界，让社区可能以标准化的形式针对不同数据层框架与流量进行对立治理管控，独特推动治理畛域技术与生态演进。

对于此次 OpenSergo 与 ShardingSphere 社区之间的单干，单方社区负责人都对此次单干表白了本人的观点：

在微服务畛域，服务间的交互与合作已日臻完善，而服务对数据库的拜访却仍然缺失卓有成效的规范。ShardingSphere 自开源以来，始终继续一直的践行着“连贯、加强、可插拔”的设计哲学。其中，“连贯”则是心愿提供标准化的协定和接口，突破开发语言拜访异构数据库的壁垒。OpenSergo 提出了微服务治理的规范，并首次将数据库的拜访放在了规范中，十分具备前瞻性。作为拜访数据库重要入口的微服务，我十分心愿 ShardingSphere 和 OpenSergo 共建规范。

——Apache ShardingSphere PMC Chair 张亮

在微服务治理畛域中，除了微服务自身的治理之外，针对数据库拜访的治理也是保障业务可靠性与连续性的要害一环。ShardingSphere 作为数据库治理畛域的标杆我的项目，积淀了十分丰盛的最佳实际与技术教训，能够很好地为 OpenSergo 补充数据库治理畛域的空缺。因而咱们联结 ShardingSphere 社区共建微服务视角的数据库治理规范，裁减治理边界，期待让社区可能以标准化的形式针对不同数据层框架与流量进行对立治理管控，独特推动治理畛域技术与生态演进。

——OpenSergo && Sentinel 社区负责人赵奕豪（宿何）

OpenSergo 微服务视角的数据库治理规范次要包含以下几局部：

在治理规定中，咱们通常须要指定规定作用的数据库实例（或实例组），或者满足的 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 自有的流控、并发管制、熔断等策略，即能够实现细粒度的流控降级与容错。

同时数据库流量治理体系中还有一些要害的、数据库畛域特有的治理能力：

读写流量路由 (ReadWriteSplitting)：读写拆散是罕用的数据库扩大形式之一，主库用于事务性的读写操作，从库次要用于查问等操作。读写流量路由规定能够指定将读 SQL 路由到读库，事务性的读写操作路由到主库。
分库分表路由 (Sharding)：数据分片路由是基于数据属性一种扩大策略，对数据属性进行计算后将申请路由到特定的数据后端，目前分为分片键分片和主动分片。其中分片键分片中须要指明须要分片的表、列、以及进行分片的算法。
数据流量隔离 (影子库表 Shadow)：影子库表能够帮忙在灰度环境或者测试环境中，接管灰度流量或者测试数据申请，联合影子算法等灵便配置多种路由形式。
数据加密 (Encryption)：企业往往因为平安审计和合规的要求，须要对数据存储提供多种平安加固措施，比方数据加密。数据加密通过对用户输出的 SQL 进行解析，并根据用户提供的加密规定对 SQL 进行改写，从而实现对原文数据进行加密，并将原文数据（可选）及密文数据同时存储到底层数据库。在用户查问数据时，它仅从数据库中取出密文数据，并对其解密，最终将解密后的原始数据返回给用户。

以下是一个读写流量路由规定的示例：

# 虚构数据库配置
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 开源奉献小组正在炽热招募贡献者。

如果您有工夫，有激情，有志愿，欢送分割社区退出开源奉献小组，一起独特欠缺 OpenSergo 和 Sentinel，一起主导微服务治理技术与规范演进。Now let’s start hacking!

咱们在阿里云也提供 MSE 数据库治理产品，从 SQL 洞察、慢 SQL 治理、读写流量治理、数据流量隔离等方面来保障微服务拜访数据库的稳定性，欢送大家理解与体验：

https://help.aliyun.com/docum…

OpenSergo 官网：

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

ShardingSphere 官网：

https://shardingsphere.apache…

关于阿里云:OpenSergo-ShardingSphere-社区共建微服务视角的数据库治理标准

为什么须要微服务治理与 OpenSergo？

微服务视角的数据库治理是保障服务稳定性的要害一环

OpenSergo 联结 ShardingSphere 社区共建数据库治理规范

对数据库 workload 及拜访对象的形象

流量治理在数据库拜访的体现

其它数据库治理能力

瞻望

相干链接