Apache ShardingSphere 遇上得物“彩虹桥”

Apache ShardingSphere 技术团队此前应邀到得物上海总部，与得物的技术同学关于 ShardingSphere 的使用经验进行了交流。

得物 App 是全球领先的集正品潮流电商和潮流生活社区于一体的新一代潮流网购社区。随着得物 App 用户开始快速增长，业务线日趋丰富，也对底层数据库带来了较大的压力。得物技术团队采用了 Apache ShardingSphere 来缓解底层数据库压力，并对其进行了深度改造和功能优化。

得物基于 Proxy 的改造：彩虹桥

此前，得物在多个业务场景下使用 ShardingSphere-JDBC 来进行数据分片，在使用 ShardingSphere-Proxy 时，也延续了分别部署多套 Proxy 集群这类的架构模式，并以 Apache ShardingSphere 5.0.0-alpha 版本为基础，自研了一套得物数据库代理层中间件：彩虹桥。

在与得物技术团队的交流中，发现了 ShardingSphere 在很多特殊场景下的应用潜力，未来在后续 ShardingSphere 社区版本的迭代中，得物技术团队也将会作为社区核心成员，参与到未来项目规划、功能搭建中来。

对于 ShardingSphere-Proxy 的部署方式而言，可以在面向整个集团业务之上部署一套 Proxy 集群进行统一管理，也可以根据不同业务需要，独立为每一条业务部署对应的 Proxy 集群。目前，在得物的业务场景下，绝大部分核心业务域都配置有 Proxy 集群，每个业务域下会有很多应用服务，如交易业务域下有商品、订单等多个服务，这些服务共用同一个 Proxy 集群。此外如供应链等多个业务下，都会有各自对应的模型集群，以减少其它业务变更对整体平台所产生的影响，降低业务风险。

同时在 ShardingSphere 的基础上，得物自研了一套系统，并在这个系统中实现了如集群一键切换等能力。如某个集群有问题的话，就可以将集群上服务的流量全部都切到另外集群上面去，实现无损发布。同时，得物对业务的连接池也做了一些改造。由于底层数据库与 ShardingSphere-Proxy 之间是长连接，如果要实现无损发布，就需要对连接池进行改造。首先基于当前连接池的状态，如果是空闲状态，可以先把负载均衡流量摘掉，再回到连接池里做柔性关闭。如果非空闲状态，就等连接池使用完毕后再关闭掉，进而确保灰度发布过程中保证数据无损。

Apache ShardingSphere 压测问题与全链路追踪

得物目前采用了两种压测方式，一种是用自定义 Hint 的形式，即 SQL 注释的方式，传输压测包括一些额外信息。另外一种方式，通过先发一条 SQL 到 Proxy 确认是否存在 Hint 信息，然后再发出一条真正的 SQL。但是如此一来会发送两条 SQL，导致响应时间升高。目前 ShardingSphere 社区也已经将相关问题纳入到未来规划之中，将与得物技术团队共同完成相关难题的技术攻坚工作。

与压测场景伴随着的是 Tracing 全链路追踪的问题。在得物的业务场景中，由于采用了分库分表策略，整体架构从上到下相对而言都比较复杂。得物技术团队通过 Hint 方式实现了全链路追踪，不过对性能却会不可避免地产生一定影响。

Apache ShardingSphere 推荐的影子库能力，配合 CyborgFlow，可以实现全链路在线压测。全链路在线压测是?项复杂?庞?的?作，需要各个微服务、中间件之间配合完成。借助于 ShardingSphere 强?的 SQL 解析能?，对执? SQL 进?影?判定，同时结合影?算法灵活的配置，满?复杂业务场景的在线压测需求。压测流量路由到影?库，线上正常流量路由到?产库，从?帮助?户实现压测数据与生产数据的隔离，解决数据污染问题。

利用 Database Mesh，与社区共同探索东西流量治理的新方式

得物目前在多个业务域上都分别部署了一套 Proxy 集群，在上层有很多模块，如订单、商品、供应链等等，因此需要探索一种 Proxy 多集群之间洞悉流量的治理方式。

Proxy 下可能存在多个节点，如何合理分配节点资源，如订单、商品、供应链等分别只访问其中两个节点，底层数据库是一样的。得物的做法是通过在多个节点上挂负载均衡，在负载均衡上基于某开源项目自研了一个连接池，通过该连接池选择负载均衡。进而实现集群能够在业务层面的无感动态切换。

这和 ShardingSphere 目前在做的方向不谋而合。ShardingSphere Sidecar 定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问，根据算法规定 SQL 的路径。通过无中心、零侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。

在逻辑库之间实现隔离

在后台，一个 Proxy 集群下会挂靠多个逻辑库，大部分情况下这些多个逻辑库都是共用一个性能池。那这样的话其实我们之前也发生过一些事情，比如说某一个逻辑库下面 RDS 挂了，会导致阻塞，如何实现逻辑库之间的隔离？

得物这里采用了基于线程池的隔离方案，引入了独占&共享线程池的概念，优先使用逻辑库独占线程池，当独占线程池出现排队情况再使用共享线程池，共享线程池达到一定负载后会在一个时间窗口内强制路由到独占线程池，在保障隔离性的前提下，最大化利用线程资源。

但是每一个逻辑库对应一个线程池，如果逻辑库很多，线程池就会增加。目前在得物的实践场景中，有百余个逻辑库用于真实生产环境，会自然启动几千个左右线程。虽然目前对于机器的压力并不大，但随着逻辑库的增加，线程池的数量也会增加，问题也会逐渐涌现出来。但是可以通过控制单个集群挂载逻辑库的数量来避免这一问题。

目前，Apache ShardingSphere 要求所有 RDS 都在线，未来规划为 RDS 增加多种状态，使其具备在线状态、离线状态、disable 状态等。通过状态来分辨 RDS 的情况，根据状态的不同来进行管理操作，进而实现逻辑库之间的隔离。

ShardingSphere 是两套执行逻辑，分别为底层执行线程，上层接收线程。Proxy-RDS 实例级别的熔断，目前支持在从库中利用读写分离功能实现熔断。如果是主库熔断，就涉及到高可用的部分，相对更加复杂。

版本迭代所带来的烦恼

配合自身业务诉求，在功能层面，得物目前已经对 ShardingSphere 进行了比较深度的改造。但与此同时，ShardingSphere 社区版本的更新，也为得物内部的需要带来了一些复杂性。由于此前是基于 Apache ShardingSphere 5.0.0-alpha 版本所做的改造，加之社区版本变动比较大，对于内部合并来说，还是带来了一定的困难。因为无法确定社区开源版本更改的内容，会不会对现有业务产生影响，以及目前得物所做的改动如何合并到社区中等。

未来 Apache ShardingSphere 社区团队也会和得物技术团队展开密切交流，分别就各自的改动进行升级评估，平衡开源版本对用户进行改造后的影响。

【联系我们】

如果您在业务中有应用 Apache ShardingSphere，想要快速了解、接入 Apache ShardingSphere 5.X 新生态，希望借此机会在团队内部举办一场关于 Apache ShardingSphere 的技术分享，欢迎在公众号后台中留下您的姓名、公司、职位、电话等信息，或添加官方小助手（ss_assistant_1），备注“走进企业”，会有专人与您对接。

在沟通过后如果双方认为产品和场景均非常匹配，Apache ShardingSphere 社区的核心团队将会走进您的企业，与各条研发线的工程师们现场沟通，解答关于 Apache ShardingSphere 的任何疑问。

欢迎点击链接，了解更多内容：

Apache ShardingSphere 官网：https://shardingsphere.apache.org/

Apache ShardingSphere GitHub 地址：https://github.com/apache/shardingsphere

SphereEx 官网：https://www.sphere-ex.com