喜马拉雅基于Apache ShardingSphere实践

背景

喜马拉雅成立之初，各个业务管理各自的数据库、缓存，个业务都要了解中间件的各种部署情况，导致业务间的合作，需要运维、开发等方面的人工介入，效率较低，扩展困难，安全风险也很高，资源利用率也不高。喜马拉雅在发展中，逐渐意识到需要在公司层面，提供统一的定制化的数据访问平台的重要性。为此，我们推出了自己的PaaS化平台，PaaS化就是对资源的使用做了统一的入口，业务只需要申请一个资源ID，就能使用数据库，达到对资源使用的全部系统化，其中对数据库的访问我们基于Apache ShardingSphere来实现，并基于Apache ShardingSphere强大功能做些优化和增强。

整体架构

我们PaaS平台建设中，负责和数据层通信的dal层中间件我们叫Arena,其中对数据库的访问我们叫Arean-Jdbc

Arena-Jdbc 层的能力基本是基于Apache ShardingSphere的能力建设，我们只是基于喜马拉雅需要的特性做了增强和优化,整体架构如下：

arena-jdbc-arch.png

Pull Frame

Consul Pull Frame 是我们对Consul 的配置自动拉起封装为统一的Pull框架，我们除了数据库，还有缓存，每种还有不同的使用方式，我们对不同的使用方式只需要实现对应的实现类和初始化，更新，切好这些接口就行，框架会统一把解析好的数据给到，具体一种场景不需要关心和Consul的交互，为后面的资源PaaS化提供了简单的接入能力。

故障容灾

• 自动重连
  我们对故障容灾在设计时就考虑了平时通用的一些故障场景，比如数据库server 挂了，我们最做自动重链，不需要业务做重启操作。
• 本地快照
  本地快照是为了防止Consul不可用时，业务不能启动，所以我们在拉到远程配置后，会本地存储一份，在拉配置时，如果远程失败，就用本地的配置，保证Consul挂了，不影响业务，每次拉到新的配置时，会更新本地的快照。
• 灰度更新
  灰度更新是为了支持配置变更时找灰度的逻辑，对于数据库层面的变更，是非常危险的，如果一下就全量变更，有可能会触发线上事故，所以通过灰度变更的机制，业务可以先选择一个容器实例来变更，没有问题后，再全量变更，把风险降到最低。
• 密码安全
  没有PaaS化之前，我们的数据库密码都是dba统一管理的，但PaaS化后，访问数据库的密码就存在配置文件中，如果明文，就太不安全，所以我们对密码统一做了加密处理，在Arean-Jdbc层统一做解密，确保密码不回泄露出去。

统一数据源

为了让业务做最低成本的改造，Arena-jdbc 需要提供一个统一的数据源，不论上层用什么框架，不影响,业务只需要替换数据源接入即可，对于数据库连接池我们默认使用HikariCP DataSource也支持个性化的业务，业务可以通过配置指定连接池。

我们基于Apache ShardingSphere的连接池封装了一个我们自己的DataSource,我们叫ArenaDataSource,通过ArenaDataSource封装了各种不同场景聚合，的使用一个ArenaDataSource支持三种使用方式：

1. 支持原生直接连接
2. 支持Proxy模式，也是Apache ShardingSphere的proxy
3. 支持直接连接分库分表

业务只需要一个DataSource，即支持分库分表，也支持简单的直接连接的模式，这样的好处是业务以后要分库分表，就不再需要升级中间件了，为了彻底解决业务升级的成本，我们做了配置自动升级，就是你之前是简单直接链接使用，为了PaaS化，后来业务发展了，需要分库分表了，以及从分库分表需要多活部署了，这些都不要再升级依赖了，只需要配置动即可。

资源动态变更

资源动态变更是PaaS平台基本的能力，接入PaaS后，业务修改数据库的任何属性，都不再需要业务方代码变更，重新发布

Apache ShardingSphere也支持数据库属性的动态变更，我们基于自己的内部系统的特征，实现了基于Consul的资源变根通知。我们的资源存在Consul。

Arena-Jdbc支持对使用的资源做无损的变更，Arena-Jdbc 收到资源变更时，会先对新下发的资源做预热处理，预热后，再切换使用的数据源，切换成功后，再销毁老的数据源，业务无感知。

如果新的资源预热失败，则不会做变更处理，保证下发的资源时可用的，规避错误下发的问题。

扩容和缩容也是同理，一期数据需要运维手动迁移，迁移好了后，直接在PaaS平台下发新的配置即可，二期支持自动迁移数据和配置变更结合。

同时支持Proxy的无损上下线机制，通过PaaS平台对Proxy的变更，把需要下线的Proxy节点去掉，通知Arena-Jdbc，Arena-Jdbc会把缩容的Proxy节点去掉，做到无损下线。

读写分离

读写分离我们完全基于Apache ShardingSphere的来实现，我们根据喜马拉雅业务的特性，对强制路由做了增强，不需要规则配置为Hint模式，只要线程上下文带有强制路由的标志，就可以路由到指定的库和表，不受分表规则的影响，我们重写了ShardingStandardRoutingEngine的Sharding时路由库和表的逻辑：

private Collection routeDataSources(final TableRule tableRule, final ShardingStrategy databaseShardingStrategy, final List databaseShardingValues) {
        //先判断是否存在Hint上下文路由标，如果有,则优先根据用户指定的规则路由库
        Collection> databaseShardings = HintManager.getDatabaseShardingValues(tableRule.getLogicTable());
        if (databaseShardings != null && databaseShardings.size() > 0) {
            List list = new ArrayList<>(4);
            for (Comparable databaseSharding : databaseShardings) {
                list.add((String) databaseSharding);
            }
            if (log.isDebugEnabled()) {
                log.debug("route dataSources, find HintManager, so hint to: {}", list);
            }
            return list;
        }
        //没有Hint路由规则，则按Sharding 规则路由
        if (databaseShardingValues.isEmpty()) {
            return tableRule.getActualDatasourceNames();
        }
        Collection result = new LinkedHashSet<>(databaseShardingStrategy.doSharding(tableRule.getActualDatasourceNames(), databaseShardingValues, properties));
        Preconditions.checkState(!result.isEmpty(), "no database route info");
        Preconditions.checkState(tableRule.getActualDatasourceNames().containsAll(result), 
                "Some routed data sources do not belong to configured data sources. routed data sources: `%s`, configured data sources: `%s`", result, tableRule.getActualDatasourceNames());
        return result;
    }

路由表也是同样的逻辑，我们重写了ShardingStandardRoutingEngine的routeTables方法，和上面一样。先从Hint 的上下文获取。这样通过上下文的方式能很好的满足业务个性化的路由规则，能和Sharding 规则共存。

Database Plus

Apache ShardingSphere 除了提供基本的分库分表，读写分离的能力外，在上层还提供了很多的插件和扩展的机制，这让我们在基于数据库提供更偏向业务的起的能力非常容易，成本非常低,这叫Database Plus

Database Plus简单的说就是你用Apache ShardingSphere的数据库中间件，不仅仅是提供了分库分表这一基本能力，通过对底层数据的封装为统一的交互标准插件模式，可以在上面实现很多业务的通用的场景的需求，比如喜马拉雅除了用到Apache ShardingSphere 基础的能力外，我们也享受了Database Plus 的威力，我们在它的基础上轻松实现了支持压测的影子库和影子表，数据加解密，机房级别容灾的同城双读，分布式唯一ID

影子库和影子表

影子库影子表我们对Apache ShardingSphere做了改动，Apache ShardingSphere 需要修改sql，我们认为对业务有改造成本，同时结合我们自己的压测平台，我们和业界一样，我们也实现了影子标记，通过全链路压测标的传递来判断是否路由到影子库/影子表，业务无需任何改造，即可使用影子库影子表来做压测，同时不需要在运行时对sql改写，提升了性能，我们重写了ShadowSQLRouter,

public class ArenaShadowSQLRouter extends ShadowSQLRouter {

    @Override
    public boolean isShadow(final SQLStatementContext sqlStatementContext, final List