本文系转载于公众号得物技术
前言
随着得物 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 自身其实曾经足够弱小，然而针对得物外部环境，还是存在一些缺点和性能缺失，次要分为以下几点：
-
易用性
- 分片、读写拆散等规定配置文件过于简单，对于业务开发不够敌对
- 规定动静变更齐全依赖配置核心，缺失欠缺的变更流程
- 连接池治理能力不欠缺
- Hint 形式不够敌对，须要业务写 RAL 语句
- 自定义分片算法须要公布
- SQL 兼容性
-
稳定性
- 多集群治理性能缺失
- 逻辑库之间的隔离性缺失
- 限流熔断组件缺失
- 数据源、规定动静变更有损
- 双活架构下流量纠偏性能的缺失
- 公布有损
-
可观测性
- SQL Trace 性能不欠缺
- 监控指标不够全面
- 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 团队的大牛们包含亮哥也来到了咱们得物总部和咱们做了一次线下交换，给咱们分享了很多干货，咱们也提出了一些咱们当初遇到的一些问题，亮哥也给出了十分有用的思路和领导。十分期待后续能够再来一次线下交换。
欢送点击链接，理解更多内容 ：
Apache ShardingSphere 官网：https://shardingsphere.apache…
Apache ShardingSphere GitHub 地址：https://github.com/apache/sha…
SphereEx 官网：https://www.sphere-ex.com