Meetup 北京站回顾｜ShardingSphere 数据分片、加密与云上实践

9 月 3 日上周六，由 SphereEx 赞助，Apache ShardingSphere 社区主办，以面向社区开发者及开源爱好者的 Apache ShardingSphere 2022 Meetup 北京站正式落下帷幕。现场，来自 ShardingSphere 社区、SphereEx、转转、豌豆公主的技术大牛分别就各自的应用实践做了解读，围绕『ShardingSphere 5.X 以及开源生态建设』进行了相关分享，为开发者带来新视野和新思路。

一、Database Plus 下的 ShardingSphere 发展模式

在开场分享中，ShardingSphere PMC Chair 张亮分享了在 Database Plus 设计理念指导下的 ShardingSphere 发展规划。他提到，未来计划在 2023 年推出全面云化的 ShardingSphere 6.0 版本，使云上的服务更加成熟与稳定，为用户提供更加原生的多云化产品；在 2025 年，计划推出面向生态的 ShardingSphere 7.0 版本，并面向这个生态提供更多功能和数据库支持，以帮助企业加速构建异构数据库的上层应用和标准。

而落地在具体的实现中，ShardingSphere 目前工作主要围绕以下四点展开：

• DistSQL 和数据库错误码标准化：未来将会为用户提供更加标准化和贴合于数据库使用习惯的 ShardingSphere 服务；

• 数据字典和元数据体系标准化：目前 ShardingSphere 的元数据是以 KV 形式存在的，未来会提供数据字典，为用户提供全方位的数据查询能力；

• 多源异构数据库支持能力提升：未来 ShardingSphere 将会承接线上的流量，统一治理底层的异构数据库，并提供基于异构数据库的数据查询能力；

• ShardingSphere on Cloud：推出 ShardingSphere 的云上解决方案，为用户提供 Helm、Operator 等 Kubernetes 上所需要的配置和功能。

二、ShardingSphere 在转转亿级交易系统的实践落地

转转交易中台资深研发工程师王晨在分享过程中讲到，转转在使用 ShardingSphere 之前，在业务层面主要遇到了 3 个问题，分别为：

• 订单数据量大：订单主表从业务之初就被分为 8 张表，发展至今，单库单表数据量已经超过了亿级，数据库情况非常不健康；

• 数据库压力大：大促期间数据库压力非常大，单库查询 qps 上万，写入的性能大大降低；

• 数据容量大：订单库磁盘占用好几个 T，数据量太大，即将超过最大磁盘容量。

在使用 ShardingSphere 之前，转转也做了一些缓解措施，如优化事务，缩小事务范围、订单数据添加缓存、主从分离、冷热数据分离等等。通过这些手段，尽管数据库的压力有所下降，但并未从根本上解决数据库的性能问题。

在从效率、稳定性、学习成本和时间多个方面对比后，结合本身订单高并发的特性，转转最终选择了 ShardingSphere，以其良好的架构设计、高度灵活、可插拔和可扩展的能力简化了数据分片的开发难度，为转转的后台数据架构带来了灵活的扩展能力，并最终实现了以下三处收益：

• 单库容量上限问题；

• 数据分片后单库表的数据量大大减少，单表数据量由原来的近亿降为百万级别，总体性能大大提高；

• 降低了因单库、单表数据过大极端情况数据丢失风险，减轻运维压力。

三、TPC-C 场景下 ShardingSphere 性能测试实战指南

今年上半年，由 ShardingSphere + openGauss 组合的分布式解决方案突破了单机数据库的性能瓶颈，使用 16 台服务器在超过 1 小时的测试中，得到了平均超过 1000 万 tpmC 的结果。本次 Meetup 现场，ShardingSphere PMC 吴伟杰解读了 ShardingSphere 的数据分片能力在 TPC-C 场景下的设计方案，并列举了测试过程中一些关键的性能优化点，展现了 ShardingSphere 在追求极致性能过程中的细节。

ShardingSphere 能够通过水平拆分以使单机数据库的计算与存储能力实现线性扩展，性能也随着扩展准线性增长，从而有效解决单表数据量急剧膨胀，所导致的单机数据库性能问题。

ShardingSphere 在与 openGauss 的性能测试中展现了其极致性能，当然这并不意味着我们在日常业务中也要追求极致的性能。性能是一个比较复杂的问题，受非常多的因素影响，追求极致性能的过程中，往往伴随着硬件、软件、人员等各方面成本的增加，性能只要能够满足业务需求即可。

四、ShardingSphere 加解密能力在豌豆公主的工程实践

豌豆公主 SRE 工程师陈硕实对应用 ShardingSphere 的加解密能力做了重点分享。随着社会对于隐私关注的提升，国家对于隐私数据的要求，因此豌豆公主决定『将数据库里与用户隐私相关的明文数据变为密文数据来实现区域标识化』，在数据库层面对涉及隐私的数据进行加密。

由于在原有的业务方案中需要改造所有涉及隐私字段增改查的部分，因此选择了 ShardingSphere 从 SQL 层入手，在增改语句中实现加密，在查询语句中实现解密。

在豌豆公主的实践中，加密部分，需要添加一个密文列，就可以在增改时双写明文和密文；解密部分，默认读取明文列返回，再将所有明文加密后，最后通过配置读取密文数据并解密返回。整个过程对上层业务系统都是透明的，减轻了业务系统改造的压力。

ShardingSphere 为用户提供了一套完整、安全、透明化、低改造成本的数据加密整合解决方案。对于像豌豆公主此类已经上线的成熟业务，用户不仅需要考虑历史数据的清洗，还需要考虑新旧功能的切换。接入 ShardingSphere encrypt，用户就可以方便地完成系统的加密改造，它还能够帮助用户安全快速地切换新旧功能。用户无需改动任何业务逻辑和 SQL 就能够透明化地使用加解密功能。

五、ShardingSphere 的云上之旅快速部署 + 开箱即用

微服务带来了快速响应市场的能力，以 Kubernetes 为代表的云原生浪潮帮助解放了运维的生产力，使得微服务上线发布和治理提升了一个新台阶。随着业务场景越来越多元，数据应用的方案呈现烟囱状，对数据的管控有孤岛化的趋势，摆在技术人员面前的是“选型难、成本高、管控复杂”等问题。SphereEx 云研发负责人苗立尧，现场介绍了目前 ShardingSphere 在云上的具体实践以及未来规划。

1. 快速部署

云上的部署效率极高，ShardingSphere-Proxy 得益于其简洁的部署架构，将治理节点、计算节点和存储节点分离开，并根据需要组合不同的实例，进行快速的部署。

2. 云上高可用实践

在云上，通常会引入 Region、Availability Zone 的概念用来描述部署位置，并基于此构建不同的高可用方案。ShardingSphere 自身的去状态化保证其良好的弹性能力，此外还提供了 Database Discovery 能力，帮助用户实现数据库维护升级和灾备切换过程中的应用无感知。

3. 云上数据迁移

ShardingSphere 在面对存量数据分片、分片键变更等场景里同样支持数据迁移，配置简单，最小化数据不可用的时间窗口以及保证数据的正确性，以并行任务的方式将数据从本地或原有的云服务上迁移至现有的云平台上。

4. 云上可观测性实践

ShardingSphere 利用 Agent 采集数据，弥补了从原有监控的不足，帮助用户更清楚地发现热点分片、慢 SQL 瓶颈、DistSQL 统计信息等，形成完整的监控洞察链路。其中 CloudWatch 指标还可以被展示到 Grafana，构成完整的端到端监控大屏。

5. 云上影子库

此前，Apache ShardingSphere 联合 Apache APISIX 和 Apache Skywalking 共同推出了 Cyborgflow 项目，实现从网关到数据的全链路、可观测的压测方案。在云上，通过将 ShardingSphere 影子库能力与 AWS 上用于压测的数据库实例进行结合，通过 Hint 或基于列的影子算法，将数据请求路由到影子库，实现全链路的压测能力。

6.云上加密

ShardingSphere 提供了强悍的数据加密能力，通过逻辑列、密文列、明文列和查询辅助列的组合，实现对业务影响最小、用户体验友好的数据加密体验。

7. 云上日志审计

用户可以通过 ShardingSphere 进行表级别的权限控制以及敏感操作事件推送，这些事件记录会被存储在 CloudWatch LogGroups 对应的 S3 中，以满足审计检查需要。

未来，ShardingSphere 将会进一步丰富数据库计算增强能力在公有云上的实践，进一步优化 ShardingSphere 在云上快速部署、高可用、迁移、安全合规、可观测性等能力，也会通过 Operator 优化 ShardingSphere-Proxy 集群部署结构、自动扩容、混沌工程等。

视频回放及 PPT 下载请点击阅读原文链接查看。