ShardingSphere SPI 加载和编排治理

SPI 加载

官网地址

在Apache ShardingSphere中,很多功能实现类的加载方式是通过SPI注入的方式完成的。 ServiceProvider Interface (SPI)是Java提供的一套被第三方实现或扩展的API,它可以用于实现框架扩展或组件替换。

这里汇总了Apache ShardingSphere所有通过SPI方式载入的功能模块。

  • SQL解析
    SQL解析的接口用于规定用于解析SQL的ANTLR语法文件。
    主要接口是SQLParserEntry,其内置实现类有MySQLParserEntry, PostgreSQLParserEntry,SQLServerParserEntryOracleParserEntry

  • 数据库协议
    数据库协议的接口用于Sharding-Proxy解析与适配访问数据库的协议。
    主要接口是DatabaseProtocolFrontendEngine,其内置实现类有MySQLProtocolFrontendEnginePostgreSQLProtocolFrontendEngine

  • 数据脱敏
    数据脱敏的接口用于规定加解密器的加密、解密、类型获取、属性设置等方式。
    主要接口有两个:Encryptor和QueryAssistedEncryptor,其中Encryptor的内置实现类有AESEncryptor和MD5Encryptor

  • 分布式主键
    分布式主键的接口主要用于规定如何生成全局性的自增、类型获取、属性设置等。
    主要接口为ShardingKeyGenerator,其内置实现类有UUIDShardingKeyGeneratorSnowflakeShardingKeyGenerator

  • 分布式事务
    分布式事务的接口主要用于规定如何将分布式事务适配为本地事务接口。
    主要接口为ShardingTransactionManager,其内置实现类有XAShardingTransactionManagerSeataATShardingTransactionManager

  • XA事务管理器
    XA事务管理器的接口主要用于规定如何将XA事务的实现者适配为统一的XA事务接口。主要接口为XATransactionManager,其内置实现类有AtomikosTransactionManager,NarayanaXATransactionManagerBitronixXATransactionManager

  • 注册中心
    注册中心的接口主要用于规定注册中心初始化、存取数据、更新数据、监控等行为。
    主要接口为RegistryCenter,其内置实现类有Zookeeper。

编排治理

编排治理模块提供配置中心/注册中心(以及规划中的元数据中心)、配置动态化、数据库熔断禁用、调用链路等治理能力。

配置中心

官网地址

实现动机

  • 配置集中化:越来越多的运行时实例,使得散落的配置难于管理,配置不同步导致的问题十分严重。将配置集中于配置中心,可以更加有效进行管理。

  • 配置动态化:配置修改后的分发,是配置中心可以提供的另一个重要能力。它可支持数据源、表与分片及读写分离策略的动态切换。
    配置中心数据结构

配置中心数据结构

配置中心在定义的命名空间的config下,以YAML格式存储,包括数据源,数据分片,读写分离、Properties配置,可通过修改节点来实现对于配置的动态管理。

config
    ├──authentication                            # Sharding-Proxy权限配置
    ├──props                                     # 属性配置
    ├──schema                                    # Schema配置
    ├      ├──sharding_db                        # SchemaName配置
    ├      ├      ├──datasource                  # 数据源配置
    ├      ├      ├──rule                        # 数据分片规则配置
    ├      ├──masterslave_db                     # SchemaName配置
    ├      ├      ├──datasource                  # 数据源配置
    ├      ├      ├──rule                        # 读写分离规则
  • config/authentication
password: root
username: root
  • config/sharding/props
    相对于sharding-sphere配置里面的Sharding Properties。
executor.size: 20
sql.show: true
  • config/schema/schemeName/datasource
    多个数据库连接池的集合,不同数据库连接池属性自适配(例如:DBCP,C3P0,Druid,HikariCP)。
ds_0: !!org.apache.shardingsphere.orchestration.yaml.YamlDataSourceConfiguration
  dataSourceClassName: com.zaxxer.hikari.HikariDataSource
  properties:
    url: jdbc:mysql://127.0.0.1:3306/demo_ds_0?serverTimezone=UTC&useSSL=false
    password: null
    maxPoolSize: 50
    maintenanceIntervalMilliseconds: 30000
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    minPoolSize: 1
    username: root
    maxLifetimeMilliseconds: 1800000
ds_1: !!org.apache.shardingsphere.orchestration.yaml.YamlDataSourceConfiguration
  dataSourceClassName: com.zaxxer.hikari.HikariDataSource
  properties:
    url: jdbc:mysql://127.0.0.1:3306/demo_ds_1?serverTimezone=UTC&useSSL=false
    password: null
    maxPoolSize: 50
    maintenanceIntervalMilliseconds: 30000
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    minPoolSize: 1
    username: root
    maxLifetimeMilliseconds: 1800000
  • config/schema/sharding_db/rule
    数据分片配置,包括数据分片 + 读写分离配置。
tables:
  t_order:
    actualDataNodes: ds_$->{0..1}.t_order_$->{0..1}
    databaseStrategy:
      inline:
        shardingColumn: user_id
        algorithmExpression: ds_$->{user_id % 2}
    keyGenerator:
      column: order_id
    logicTable: t_order
    tableStrategy:
      inline:
        shardingColumn: order_id
        algorithmExpression: t_order_$->{order_id % 2}
  t_order_item:
    actualDataNodes: ds_$->{0..1}.t_order_item_$->{0..1}
    databaseStrategy:
      inline:
        shardingColumn: user_id
        algorithmExpression: ds_$->{user_id % 2}
    keyGenerator:
      column: order_item_id
    logicTable: t_order_item
    tableStrategy:
      inline:
        shardingColumn: order_id
        algorithmExpression: t_order_item_$->{order_id % 2}
bindingTables:
  - t_order,t_order_item
broadcastTables:
  - t_config
  
defaultDataSourceName: ds_0
    
masterSlaveRules: {}
  • config/schema/masterslave/rule
    读写分离独立使用时使用该配置。
name: ds_ms
masterDataSourceName: ds_master 
slaveDataSourceNames:
  - ds_slave0
  - ds_slave1
loadBalanceAlgorithmType: ROUND_ROBIN
  • 动态生效
    在注册中心上修改、删除、新增相关配置,会动态推送到生产环境并立即生效。

注册中心

相对于配置中心管理配置数据,注册中心存放运行时的动态/临时状态数据,比如可用的proxy的实例,需要禁用或熔断的datasource实例。通过注册中心,可以提供熔断数据库访问程序对数据库的访问和禁用从库的访问的编排治理能力。治理仍然有大量未完成的功能(比如流控等)

  • 注册中心数据结构
    注册中心在定义的命名空间的state下,创建数据库访问对象运行节点,用于区分不同数据库访问实例。包括instances和datasources节点。
instances
    ├──your_instance_ip_a@-@your_instance_pid_x
    ├──your_instance_ip_b@-@your_instance_pid_y
    ├──....
datasources
    ├──ds0
    ├──ds1
    ├──....
  • state/instances
    数据库访问对象运行实例信息,子节点是当前运行实例的标识。 运行实例标识由运行服务器的IP地址和PID构成。运行实例标识均为临时节点,当实例上线时注册,下线时自动清理。注册中心监控这些节点的变化来治理运行中实例对数据库的访问等。

  • state/datasources
    可以控制读写分离,可动态添加删除以及禁用。

  • 熔断实例
    可在IP地址@-@PID节点写入DISABLED(忽略大小写)表示禁用该实例,删除DISABLED表示启用。
    Zookeeper命令如下:

    [zk: localhost:2181(CONNECTED) 0] set /your_zk_namespace/your_app_name/state/instances/your_instance_ip_a@-@your_instance_pid_x DISABLED
    
  • 禁用从库
    在读写分离场景下,可在数据源名称子节点中写入DISABLED表示禁用从库数据源,删除DISABLED或节点表示启用。
    Zookeeper命令如下:

    [zk: localhost:2181(CONNECTED) 0] set /your_zk_namespace/your_app_name/state/datasources/your_slave_datasource_name DISABLED
    

支持的配置中心和注册中心

ShardingSphere在数据库治理模块使用SPI方式载入数据到配置中心/注册中心,进行实例熔断和数据库禁用。 目前,ShardingSphere内部支持Zookeeper和Etcd这种常用的配置中心/注册中心。 此外,您可以使用其他第三方配置中心/注册中心,例如Apollo、Nacos等,并通过SPI的方式注入到ShardingSphere,从而使用该配置中心/注册中心,实现数据库治理功能。

应用性能监控

APM是应用性能监控的缩写。目前APM的主要功能着眼于分布式系统的性能诊断,其主要功能包括调用链展示,应用拓扑分析等。

ShardingSphere并不负责如何采集、存储以及展示应用性能监控的相关数据,而是将SQL解析与SQL执行这两块数据分片的最核心的相关信息发送至应用性能监控系统,并交由其处理。 换句话说,ShardingSphere仅负责产生具有价值的数据,并通过标准协议递交至相关系统。
ShardingSphere可以通过两种方式对接应用性能监控系统。

  • 使用OpenTracing API发送性能追踪数据。面向OpenTracing协议的APM产品都可以和ShardingSphere自动对接,比如SkyWalking,Zipkin和Jaeger。

  • 使用SkyWalking的自动探针。 ShardingSphere团队与SkyWalking团队共同合作,在SkyWalking中实现了ShardingSphere自动探针,可以将相关的应用性能数据自动发送到SkyWalking中。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在 Java 中,SPI(Service Provider Interface)是一种服务发现机制,它允许开发者定义一组接口和抽象类,然后由第三方厂商提供实现,这些实现可以在运行时动态被发现和。JDK SPI 机制通常用于服务框架的扩展,比如 JDBC 驱动、日志框架等。下面简单介绍 JDK SPI和卸过程。 ### JDK SPI过程主要涉及到以下几个步骤: 1. 开发者在 classpath 下定义 `META-INF/services` 目录,并在该目录下创建一个以服务接口全限定名为命名的文件,其中每一行都是该接口的一种实现类的全限定名。 2. 应用程序通过 `ServiceLoader` 类的 `load(Class<T> service)` 方法服务接口的实现类,该方法返回一个 `ServiceLoader` 实例。 3. 应用程序通过 `ServiceLoader` 实例的 `iterator()` 方法获取一个迭代器,遍历该迭代器可获取所有服务接口的实现类的实例。 具体代码示例: ```java ServiceLoader<IService> serviceLoader = ServiceLoader.load(IService.class); Iterator<IService> iterator = serviceLoader.iterator(); while (iterator.hasNext()) { IService service = iterator.next(); // do something with service } ``` ### 卸 JDK SPI 没有显式的卸机制,因为所有服务实现类都是在应用程序启动时被的,并存储在 `ServiceLoader` 实例中,直到应用程序退出才会被释放。如果需要对服务实现类进行卸,可以通过动态修改 classpath 的方式实现。比如,将服务实现类所在的 jar 包从 classpath 中移除即可。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值