ShardingSphere + OpenSergo，共同提升微服务体系下数据库的性能

阿里云 OpenSergo 联合 ShardingSphere 共同发布了面向微服务场景下的数据库治理标准。其中通过结合 Database Plus 以及 Database Mesh 理念，OpenSergo 及 ShardingSphere 社区共同对已有的数据库治理理念、模式、路径等进行了标准化，进一步完善了云原生环境体系下的数据库治理生态。

对于此次 ShardingSphere 与 OpenSergo 社区间的合作，双方社区创始人都对此表达了自己的观点：

Apache ShardingSphere PMC Chair 张亮：在微服务领域，服务间的交互与协作已日臻完善，而服务对数据库的访问却依然缺失行之有效的标准。ShardingSphere 自开源以来，一直持续不断的践行着“连接、增强、可插拔”的设计哲学。其中，“连接”则是希望提供标准化的协议和接口，打破开发语言访问异构数据库的壁垒。OpenSergo 提出了微服务治理的标准，并首次将数据库的访问放在了标准中，非常具备前瞻性。作为访问数据库重要入口的微服务，我非常希望 ShardingSphere 和 OpenSergo 共建标准。

OpenSergo 社区发起人 赵奕豪（宿何）：在微服务治理领域理领域中，除微服务本身的治理之外，针对微服务访问数据库的治理也是保障业务可靠性与连续性的关键一环。ShardingSphere 作为数据库治理领域的标杆项目，沉淀了非常丰富的最佳实践与技术经验，可以很好地为 OpenSergo 补充数据库治理领域的空缺。因此我们联合 ShardingSphere 社区共建微服务视角的数据库治理标准，扩充治理边界，让社区能够以标准化的方式针对不同数据层框架与流量进行统一治理管控，共同推进治理领域技术与生态演进。

注：本文的数据库治理，指的是对微服务系统中所有涉及数据库治理内容的总称。作为微服务中最重要的状态终端，所有的业务信息、关键数据都需要健壮稳定的数据库系统。

数据库在微服务体系下的重要性愈发凸出

当应用架构为了适应更加灵活多变的业务需求，将架构设计从单体式向服务化再到微服务进行转化之后，用于存储业务核心数据的数据库则成为分布式系统的下一个焦点。

另一方面，企业通过使用微服务将不同的服务独立出来，通过分布式架构来实现多个服务之间的松耦合、业务的灵活调整组合以及系统的高可用性。尤其是在业务变更频繁的今天，微服务的确带来了许多便利。

不过将服务拆分后，其对应的底层数据库也应该进行拆分以此来保证每个服务的独立部署，使每个服务成为独立的单元，实现业务的最终微服务化。因此在微服务体系中，数据库的复杂性正在被进一步拉高，这主要体现在：

• 从单体到微服务，在架构模型变化的同时，业务越来越复杂、需求越来越多元、基础设施规模越来越大、服务之间的调用关系越来越繁琐，对底层数据库的性能要求更加极致；
• 不同的事务往往牵涉到多个服务，如要做到多个服务的数据一致性却并非易事；
• 在多个服务之间进行数据查询也充满挑战。

对于大多数的后端应用来讲，系统性能扩展的瓶颈主要受限于数据库。尤其在微服务的环境下，数据库的性能治理问题往往也是团队优先级最高的几类工作之一，数据库治理自然也成为微服务治理中必不可少的一环。

关于数据库治理，目前主要集中在『读写分离、分库分表、加密、影子库、数据库发现、分布式事务』等方面。同时，决定应用消费数据库的方式以及实际数据库存储节点还依赖于『虚拟数据库、数据库端点』这两个概念。

基于此，OpenSergo 联合 ShardingSphere，从 ShardingSphere 多年的数据库治理经验中抽象出数据库治理标准，将社区之间的经验进行适配，共同推出了『微服务数据库治理标准』，以规范化当前微服务体系下的数据库治理『乱象』，降低数据库治理门槛，进而提升微服务在业务中的适用性。

ShardingSphere 数据库流量治理策略

1. 虚拟数据库 VirtualDatabase

在数据库治理中，不管是读写分离、分库分表、影子库，还是加密、审计和访问控制等，都需要作用在一个具体的数据库之上。在这里将这样的一个逻辑的数据库称为虚拟数据库，即 VirtualDatabase。VirtualDatabase 在应用看来是一组特定的数据库访问信息，并通过绑定特定的治理策略实现相应的治理能力。

2. 数据库端点 DatabaseEndpoint

在数据库治理中，通过 VirtualDatabase 向应用声明了可以使用的逻辑数据库，而数据的真实存储则依赖于这样的一个物理的数据库，这里称为数据库访问端点，即 DatabaseEndpoint。DatabaseEndpoint 对应用无感知，它只能被 VirtualDatabase 通过特定治理策略所绑定然后连接和使用。

3. 读写分离 ReadWriteSplitting

读写分离是常用的数据库扩展方式之一，主库用于事务性的读写操作，从库主要用于查询等操作。

4. 分库分表 Sharding

数据分片是基于数据属性一种扩展策略，对数据属性进行计算后将请求发往特定的数据后端，目前分为分片键分片和自动分片。其中分片键分片中需要指明需要分片的表、列、以及进行分片的算法。

5. 加密 Encryption

企业往往因为安全审计和合规的要求，需要对数据存储提供多种安全加固措施，比如数据加密。数据加密通过对用户输入的 SQL 进行解析，并依据用户提供的加密规则对 SQL 进行改写，从而实现对原文数据进行加密，并将原文数据（可选）及密文数据同时存储到底层数据库。在用户查询数据时，它仅从数据库中取出密文数据，并对其解密，最终将解密后的原始数据返回给用户。

6. 影子库 Shadow

影子库可以帮助在灰度环境或者测试环境中，接收灰度流量或者测试数据请求，结合影子算法等灵活配置多种路由方式。

7. 数据库发现 DatabaseDiscovery

数据库自动发现指的是根据数据库高可用配置，通过探测的方式感知数据源状态变化，并对流量策略做出相应的调整。比如后端数据源为 MySQL MGR，那么可以配置数据库发现类型为 MYSQL.MGR，指定 group-name，并配置相应的探测心跳节律。

8. 分布式事务 DistributedTransaction

声明分布式事务相关的配置，在这里声明事务的类型，没有额外的配置。

数据库治理示例

# 虚拟数据库配置
apiVersion: database.opensergo.io/v1alpha1
kind: VirtualDatabase
metadata:
  name: sharding_db
spec:
  services:
  - name: sharding_db
    databaseMySQL:
      db: sharding_db
      host: localhost
      port: 3306
      user: root
      password: root
    sharding: "sharding_db"  # 声明所需要的分库分表策略
---
# 第一个数据源的数据库端点配置
apiVersion: database.opensergo.io/v1alpha1
kind: DatabaseEndpoint
metadata:
  name: ds_0
spec:
  database:
    MySQL:                 # 声明后端数据源的类型及相关信息
      url: jdbc:mysql://192.168.1.110:3306/demo_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: ds_1
spec:
  database:
    MySQL:                              # 声明后端数据源的类型及相关信息
      url: jdbc:mysql://192.168.1.110:3306/demo_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: Sharding
metadata:
  name: sharding_db
spec:
  tables: # map[string]object 类型
    t_order:
      actualDataNodes: "ds_${0..1}.t_order_${0..1}"
      tableStrategy:
        standard:
          shardingColumn: "order_id"
          shardingAlgorithmName: "t_order_inline"
      keyGenerateStrategy:
        column: "order_id"
        keyGeneratorName: "snowflake"
    t_order_item:
      actualDataNodes: "ds_${0..1}.t_order_item_${0..1}"
      tableStrategy:
        standard:
          shardingColumn: "order_id"
          shardingAlgorithmName: "t_order_item_inline"
      keyGenerateStrategy:
        column: order_item_id
        keyGeneratorName: snowflake
  bindingTables:
  - "t_order,t_order_item"
  defaultDatabaseStrategy:
    standard:
     shardingColumn: "user_id"
     shardingAlgorithmName: "database_inline"
  # defaultTableStrategy: # 为空表示 none
  shardingAlgorithms: # map[string]object 类型
    database_inline:
      type: INLINE    
      props: # map[string]string 类型
        algorithm-expression: "ds_${user_id % 2}"
    t_order_inline:  
      type: INLINE    
      props:
        algorithm-expression: "d_order_${order_id % 2}"      
    t_order_item_inline:
      type: INLINE    
      props:
        algorithm-expression: "d_order_item_${order_id % 2}"
  keyGenerators: # map[string]object 类型
    snowflake:
      type: SNOWFLAKE

关于 Apache ShardingSphere

Apache ShardingSphere 是一款分布式的数据库生态系统，可以将任意数据库转换为分布式数据库，并通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。ShardingSphere 以 Database Plus 为设计哲学，旨在构建异构数据库上层的标准和生态，关注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。它站在数据库的上层视角，关注它们之间的协作多于数据库自身。

🔗Apache ShardingSphere GitHub 地址：​​https://github.com/apache/shardingsphere​​

关于 OpenSergo

OpenSergo 是一套开放、通用的、面向分布式服务架构、覆盖全链路异构化生态的服务治理标准，基于业界服务治理场景与实践形成服务治理通用标准。OpenSergo 最大特点是以统一一套配置/DSL/协议定义服务治理规则，面向多语言异构化架构，做到全链路生态覆盖。

无论微服务的语言是 Java，Go，Node.js 或其它语言，无论是标准微服务或 Mesh 接入，从网关到微服务，从数据库到缓存，从服务注册发现到配置，开发者都可以通过同一套 OpenSergo CRD 标准配置针对每一层进行统一的治理管控，而无需关注各框架、语言的差异点，降低异构化、全链路服务治理管控的复杂度。

🔗OpenSergo GitHub 地址：​​https://github.com/opensergo/opensergo-specification​​

本文转载自公众号：ShardingSphere官微