前言

随着得物 App 用户开始快速增长，业务线日趋丰盛，也对底层数据库带来了较大的压力。各个业务线对于数据分片、读写拆散、影子库路由等等的需要成为了刚需，所以须要一个对立的中间件来撑持这些需要，得物“彩虹桥”应运而生。

在北欧神话中，彩虹桥是连结阿斯加德（Asgard）【1】和 米德加尔特（中庭/Midgard）的微小彩虹桥。咱们能够把它当作是“九界之间”的连贯通道，也是进入阿斯加德的惟一稳固入口。而得物的彩虹桥是连贯服务与数据库之间的数据库中间层解决中间件，能够说得物的每一笔订单都与它非亲非故。

1. 技术选型

后期咱们调研了Mycat、ShardingSphere、kingshard、Atlas等开源中间件，综合了适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面，最终咱们抉择了ShardingSphere。筹备在ShardingSphere的根底上进行二次开发、定制一套适宜得物外部环境的数据库中间件。

Apache ShardingSphere 是一款开源分布式数据库生态我的项目，由 JDBC、Proxy 和 Sidecar（布局中） 3 款产品组成。其外围采纳可插拔架构，通过组件扩大性能。对上以数据库协定及 SQL 形式提供诸多加强性能，包含数据分片、拜访路由、数据安全等；对下原生反对 MySQL、PostgreSQL、SQL Server、Oracle 等多种数据存储引擎。ShardingSphere 已于2020年4月16日成为 Apache 软件基金会的顶级我的项目，并且在寰球多个国家都有团队在应用。

目前咱们次要是ShardingSphere的Proxy模式提供服务，后续将会在JDBC&Proxy混合架构持续摸索。

2.彩虹桥目前的能力

其中红色模块为现阶段以及具备的能力，绿色模块为布局&正在做的性能。上面介绍一下几个重点性能。留神，以下性能都是基于Proxy模式。

2.1 数据分片

数据分片指依照某个维度将寄存在繁多数据库中的数据扩散地寄存至多个数据库或表中以达到晋升性能瓶颈以及可用性的成果。数据分片的无效伎俩是对关系型数据库进行分库和分表。分库和分表均能够无效地防止由数据量超过可接受阈值而产生的查问瓶颈。除此之外，分库还可能用于无效地扩散对数据库单点的访问量；分表尽管无奈缓解数据库压力，但却可能提供尽量将分布式事务转化为本地事务的可能，一旦波及到跨库的更新操作，分布式事务往往会使问题变得复杂。应用多主多从的分片形式，能够无效地防止数据单点，从而晋升数据架构的可用性。

通过分库和分表进行数据的拆分来使得各个表的数据量放弃在阈值以下，以及对流量进行疏导应答高访问量，是应答高并发和海量数据系统的无效伎俩。数据分片的拆分形式又分为垂直分片和程度分片。

依照业务拆分的形式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。彩虹桥次要提供的分片能力是程度分片，程度分片又称为横向拆分。绝对于垂直分片，它不再将数据依据业务逻辑分类，而是通过某个字段（或某几个字段），依据某种规定将数据扩散至多个库或表中，每个分片仅蕴含数据的一部分。例如：依据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表），如下图所示。


程度分片从实践上冲破了单机数据量解决的瓶颈，并且扩大绝对自在，是数据分片的规范解决方案。

当然理论应用场景的分片规定是非常复杂的，咱们提供一些内置算法比方取模、HASH取模、主动时间段分片算法、Inline表达式等。当内置算法无奈满足要求时，还能够基于groovy来定制专属的分片逻辑。

2.2 读写拆散

面对日益减少的零碎访问量，数据库的吞吐量面临着微小瓶颈。对于同一时刻有大量并发读操作和较少写操作类型的利用零碎来说，将数据库拆分为主库和从库，主库负责解决事务性的增删改操作，从库负责解决查问操作，可能无效的防止由数据更新导致的行锁，使得整个零碎的查问性能失去极大的改善。通过一主多从的配置形式，能够将查问申请平均地扩散到多个数据正本，可能进一步地晋升零碎的解决能力。

与将数据依据分片键打散至各个数据节点的程度分片不同，读写拆散则是依据 SQL 语义的剖析，将读操作和写操作别离路由至主库与从库。

这里配置的形式比较简单，给指标主库绑定一个或多个从库、设置对应的负载平衡算法即可。

这里的实现形式就是通过SQL解析，把查问语句路由到对应的从库即可，然而在一些对主从同步提早比拟敏感的场景，可能须要强制走主库，这里咱们也提供一个API（原理就是SQL Hint），让上游能够指定某些模块读强制走主，还有相干全局配置能够让事务内所有读申请全副走主。

2.3 影子库压测

在基于微服务的分布式应用架构下，业务须要多个服务是通过一系列的服务、中间件的调用来实现，所以单个服务的压力测试已无奈代表实在场景。在测试环境中，如果从新搭建一整套与生产环境相似的压测环境，老本过高，并且往往无奈模仿线上环境的复杂度以及流量。因而，业内通常抉择全链路压测的形式，即在生产环境进行压测，这样所取得的测试后果可能精确地反馈零碎实在容量和性能程度。

全链路压测是一项简单而宏大的工作。须要各个微服务、中间件之间配合与调整，以应答不同流量以及压测标识的透传。通常会搭建一整套压测平台以实用不同测试计划。在数据库层面须要做好数据隔离，为了保障生产数据的可靠性与完整性，须要将压测产生的数据路由到压测环境数据库，避免压测数据对生产数据库中实在数据造成净化。这就要求业务利用在执行 SQL 前，可能依据透传的压测标识，做好数据分类，将相应的 SQL 路由到与之对应的数据源。

这里配置的形式相似读写拆散，也是给指标主库绑定一个影子库，当SQL携带了影子标就会被路由到影子库。

2.4 限流&熔断

当DB的压力超过本身水位线时，会导致DB产生故障。当咱们预估出某个维度的水位线后，能够配置对于的限流规定，回绝掉超过自身水位线以外的申请来爱护DB。让零碎尽可能跑在最大吞吐量的同时保证系统整体的稳定性。维度方面咱们反对DB、Table、SQL以及DML类型。


彩虹桥上面连贯了上百个RDS实例，每个RDS实例都有可能呈现各种故障，当单个实例呈现故障会影响到整个逻辑库，会迅速造成阻塞诱发雪崩效应。所以咱们须要一种疾速失败的机制来避免雪崩，目前咱们是反对DB实例级别的熔断，基于获取连贯&SQL执行2种行为，以及执行工夫跟失败比例来实现熔断，以达到在DB故障时疾速失败的成果。

2.5 流量纠偏

在双活架构下，彩虹桥作为数据库的代理层，能够保障双活架构下流量切换过程的流量做兜底拦挡，保证数据一致性。原理就是基于SQL Hint携带的userId与机房规定做匹配，拦挡不属于以后机房的流量。

3. 基于ShardingSphere咱们做了哪些革新

尽管ShardingSphere Proxy自身其实曾经足够弱小，然而针对得物外部环境，还是存在一些缺点和性能缺失，次要分为以下几点：

  • 易用性
    a.分片、读写拆散等规定配置文件过于简单，对于业务开发不够敌对
    b.规定动静变更齐全依赖配置核心，缺失欠缺的变更流程
    c.连接池治理能力不欠缺
    d.Hint形式不够敌对，须要业务写RAL语句
    e.自定义分片算法须要公布
    f.SQL兼容性
  • 稳定性
    a.多集群治理性能缺失
    b.逻辑库之间的隔离性缺失
    c.限流熔断组件缺失
    d.数据源、规定动静变更有损
    e.双活架构下流量纠偏性能的缺失
    f.公布有损
  • 可观测性
    a.SQL Trace性能不欠缺
    b.监控指标不够全面
    c.SQL洞察能力缺失
  • 性能
    因为多了一次网络转发，单条SQL的RT比直连会上浮2~3ms

为了解决以上问题，咱们做了以下革新与优化。

3.1 易用性晋升

针对数据源、规定的配置、变更、审计等一系列操作，集成到管控台进行对立操作。通过图形化的形式升高了分片、读写拆散等规定配置文件的复杂度，并且加上一系列校验来躲避了一部分因为配置文件谬误导致的低级谬误。其次加上了审计性能，保障了配置动静变更的安全性和可控性。

管控台新增了连接池治理，基于RDS连接数、Proxy节点数、挂载数据源数量等因素主动计算出一个平安正当的连接池大小。

新增Client，针对Hint做一系列适配，比方影子标传递、双活架构用户id传递、trace传递、强制路由等等。应用方只须要调用Client中的API，即可在收回SQL阶段主动改写成Proxy能够辨认的Hint加强语句。

管控台新增了集群治理性能：因为咱们部署了多套Proxy集群，为了最大水平的保障故障时的爆炸半径，咱们依照业务域对Proxy集群进行了划分，尽量保障对立业务域上面的逻辑库流量进入同一套集群。

新增了Groovy来反对自定义分片算法，在后盾配置好分片逻辑后审核通过即可失效，无需Proxy发版

3.2 稳定性晋升

3.2.1 Proxy多集群治理

（1）背景
随着Proxy承载的业务域越来越多，如果所有的流量都通过负载平衡路由到Proxy节点，当一个库呈现问题时，可能会导致整个集群瘫痪，爆炸范畴不可控。而且因为DB的连接数资源无限，这就导致Proxy的节点无奈大规模横向扩大。

（2）解决方案
为了不同业务域之间的隔离性，咱们部署了多套Proxy集群，并且通过管控台保护各个逻辑库与集群之间的关系。保障同一业务域上面的逻辑库流量进入同一套集群。并且在某个集群产生故障时，可把故障集群中的逻辑库迅速、无损的动静切换至备用集群，尽可能减少Proxy自身故障给业务带来的损失。

而针对连接数治理方面，Proxy在初始化连接池的时候会判断一下以后逻辑库是否在以后集群，如果不在把最小连接数配置设置成最小，如果在则依照失常配置加载，并在集群切换前后做好指标集群的预热以及原集群的回收。这样能够极大水平上缓解DB连接池资源对Proxy节点的横向扩大。

（3）实现原理
上游利用引入Rainbow（自研连接池）后，在连接池初始化之前会依据逻辑库读取以后库所在集群，并动静把Proxy的域名替换成其所在集群的域名。同时还会新增对集群配置的监听，这样在管控台切换集群操作后，Rainbow会依据切换后的集群域名创立一个新的连接池，而后替换掉老的连接池，老的连接池也会进行延时优雅敞开，整个过程对上游利用无感知。

（4）架构图

3.2.2 Proxy工作线程池隔离

（1）背景
开源版本的Proxy，所有逻辑库共用一个线程池，当单个逻辑库产生阻塞的状况，会耗尽线程池资源，导致其余逻辑库也跟着受影响。

（2）解决方案
咱们这里采纳了基于线程池的隔离计划，引入了独占&共享线程池的概念，优先应用逻辑库独占线程池，当独占线程池呈现排队状况再应用共享线程池，共享线程池达到肯定负载后会在一个工夫窗口内强制路由到独占线程池，在保障隔离性的前提下，最大化利用线程资源。

3.2.3 流控与熔断

（1）背景
开源版本的Proxy短少对库、表、SQL等维度的流控，当短时间内暴发超过零碎水位的流量时，很可能就会击垮DB导致线上故障，而且短少针对DB疾速失败的机制，当DB产生故障（比方CPU 100%）无奈疾速失败的状况下，会迅速造成阻塞诱发雪崩效应。

（2）解决方案
新增了各个维度（DB、table、SQL、语句类型）的限流，各个库能够依据预估的水位线以及业务须要配置一个正当的阈值，最大水平爱护DB。同时咱们也引入DB实例的熔断策略，在某个实例呈现故障时可疾速失败。在分库场景下，可最大水平缩小对其余分片的影响，进一步放大了故障的爆炸半径，晋升彩虹桥整体的稳定性。

（3）实现原理
流控跟熔断都是基于sentinel来实现的，在管控台配置对应的规定即可。

3.2.4 无损公布

（1）背景
在后期，Proxy每次公布或者重启的时候，都会收到上游利用SQL执行失败的一些报警，次要的起因是因为上游与Proxy之间是长连贯，这时如果有连贯正在执行SQL，那么就会被强制断开导致SQL执行失败，肯定水平上对上游的业务造成损失。

（2）解决方案
公布零碎配合自研连接池Rainbow，在Proxy节点公布或重启之前，会告诉Rainbow连接池优雅敞开利用于须要重启&公布的Proxy节点之间的连贯，在Proxy流量跌0后再执行重启&公布。

3.3 可观测性

3.3.1 运行时指标

（1）背景
开源版本对于Proxy运行时的监控指标很少，导致无奈观测到Proxy下面每个库运行的具体状态。

（2）解决方案
在Proxy各个执行阶段加了埋点，新增了以下指标、并绘制了对应的监控大盘。

  • 库&表级别的QPS、RT、error、慢SQL指标
  • Proxy-DB连接池的各项连接数指标
  • 流控熔断指标
  • 线程池沉闷线程数、队列大小指标

（3）效果图

3.3.2 全链路追踪

（1）背景
开源版本的trace只反对Proxy外部执行阶段的链路追踪，无奈和上游串联，导致排障效率低下。

（2）解决方案
次要通过RAL、SQL正文2种形式传递trace信息，实现了上游到Proxy的全链路追踪。

（3）实现原理
咱们首先想到的计划就是通过SQL正文形式传递trace信息，然而在真正投产之后却发现了一些问题，在上游应用了prepare模式（useServerPrepStmts=true&cachePrepStmts=true）时，Proxy会缓存statmentId和SQL，而trace每次都不一样，这样会导致存储缓存有限增长最终导致OOM。

所以通过SQL正文形式传递trace信息只实用于非prepare场景。于是咱们又新增了一种计划就是在每次SQL执行之前发送一条RAL语句来传递trace信息，并在Proxy中缓存channelId与trace信息的对应关系，因为单个channel所有的SQL都是串行执行，加上channelId数量可控，不会有限收缩。然而这种计划绝对于每次SQL执行之前都有一次RAL语句的执行，对性能的影响还是比拟大的。从监控上看下来每次SQL执行的RT会上浮2-3ms（网络传输），对于一些链路较长的接口来说还是挺致命的。

（4）总结
综合下来2种计划其实都有比拟显著的毛病，针对这个问题之前ShardingSphere的小伙伴来过咱们得物进行过一次深度沟通，亮哥给出了一个比拟可行的计划，就是通过虚构列传输trace信息，然而须要上游对SQL进行改写，这可能会减少上游利用的累赘，目前这块咱们还没有开始做。

3.3.3 SQL洞察

（1）背景
目前Proxy尽管有打印逻辑SQL和物理SQL的日志，然而因为生产申请量较大，开启日志会对IO有较大挑战。所以目前咱们生产环境还是敞开的状态。而且这个日志也无奈与上游串联，对于排障的帮忙也是比拟无限。

（2）解决方案
目前也只有个大略的思路，还没有欠缺的计划，要达到的成果就是收集所有Proxy执行的逻辑SQL、物理SQL以及上游信息，包含JDBCDatabaseCommunicationEngine以外的一些SQL（比方TCL等等），并通过管控台实时查问。最终的成果相似阿里云RDS的免费服务-SQL洞察

3.4 bug修复

因为历史起因，咱们是基于Apache ShardingSphere 5.0.0-alpha上做的二次开发，在理论应用的过程中遇到了很多bug，大部分都给官网提了issue，并且在彩虹桥版本上做了修复，当然ShardingSphere社区的小伙伴也给与了很多帮忙和修复的思路。

3.5 JDBC&Proxy混合架构

（1）背景
下面4项内容大多数针对Proxy模块或上游连接池模块的革新，然而还是有一些问题是Proxy模式临时无奈解决的，比方后面提到的SQL兼容性和性能问题。还有就是如果整个Proxy集群全副宕机状况下咱们没有一个兜底机制。所以Proxy模式并不适用于所有场景。在Apache ShardingSphere的官网文档能够看到这样一段内容：

于是咱们筹备在JDBC&Proxy混合架构上做了进一步摸索。

（2）解决方案
在管控台实现对逻辑库的模式配置，并通过自研连接池Rainbow感知并依据不同模式启动不同类型的数据源。并且能够在后盾切换模式后无损动静调整，这样对于使用者来说是齐全无感知的。对SQL性能、兼容性要求比拟高的利用能够调整为JDBC模式。同时当Proxy所有集群瘫痪时也有个兜底的计划，不至于全站解体。

（3）实现原理
Rainbow连接池启动的时候会查问以后逻辑库对应的模式，如果是Proxy模式则间接连贯Proxy来启动连接池，如果是JBDC则依据该逻辑库的数据源配置以及分片&读写拆散&影子库等等规定来加载JDBC模式的数据源，对应的DataSource为GovernanceShardingSphereDataSource。并且会监听这个模式配置，当模式发生变化后会动静无损替换以后连接池。具体的无损替换计划与后面提到的集群切换相似。同时须要解决的还有监控问题和连接池资源的治理，Proxy切换至JDBC模式后指标的裸露由Proxy节点变成了上游节点，对应的大盘也须要做对应的交融，连接池治理这块也应用了新的计算模式做了对应的适配。

4. 目前的困惑

因为历史起因，咱们是基于Apache ShardingSphere 5.0.0-alpha上做的二次开发，目前社区最新的版本是5.1.2-release，从5.0.0-alpha~5.1.2-release做了大量的优化跟bug修复，然而咱们没有很好的方法将社区的代码合并到咱们的外部代码，因为无奈确定社区开源版本更改的内容，会不会对现有业务产生影响，短时间内也无奈享受社区带来的红利。同时咱们也在寻找一种形式将咱们做的一些优化后续合并到社区中，也算是一种反哺社区。为中国开源做一份奉献~

5. 写在最初

ShardingShpere的源码十分优良，很多中央的设计十分的奇妙，模块划分的也很清晰。但总体的代码十分宏大，刚开始浏览起来还是十分吃力的。尽管文章的大部分是在指出目前开源版本的问题，但再优良的产品也不可能实用所有场景。今年年初ShardingSphere团队的大牛们包含亮哥也来到了咱们得物总部和咱们做了一次线下交换，给咱们分享了很多干货，咱们也提出了一些咱们当初遇到的一些问题，亮哥也给出了十分有用的思路和领导。十分期待后续能够再来一次线下交换。

*文/陈浩
@得物技术公众号