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 官网：shardingsphere.apache.org/

Apache ShardingSphere GitHub 地址：github.com/apache/shar…

SphereEx 官网：www.sphere-ex.com