喜马拉雅基于Apache ShardingSphere实践

背景 

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

整体架构

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

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

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. 支