引文：随着数据库百花齐放的时代到来，多样化需求让传统数据库架构已无法满足。一方面通过提供更为强大数据库来应对上述挑战，另一方面通过数据库上层扩展也是一种思路，因而数据库增强引擎应运而生。作为一种数据架构领域的革新，其注重于云原生、分布式、多源异构、数据安全合规等方面能力的提升，旨在在数据库之上提供统一的接入能力，并在查询、存储、管控和生态方面提供功能增强，同时提供云原生和分布式的转化能力，以满足企业对于构建大规模、高效、安全的数据架构需求。本次分享将从 Apache 顶级开源项目 ShardingSphere 出发，介绍新一代数据库架构增强引擎的设计理念、技术特点和应用场景。
ShardingSphere
嘉 宾 介 绍
代野
Apache ShardingSphere 贡献者
SphereEx 解决方案工程师
以下为视频回放（温馨提示：视频长 23 分 11 秒，建议在 Wifi 条件下观看）
以下为回顾正文：
1
ShardingSphere 发展历程回顾
Apache ShardingSphere 第一个版本发布在 2016 年，最初 1.0 版本叫 Sharding-JDBC ， 18 年发布的 3.0 版本支持代理端 Proxy，呈现数据库的形态，面向 DBA，面向运维，有更友好的维护方式，支持异构开发语言。同年，进入 Apache 基金会，在 2020 年毕业，成为 Apache 基金会顶级项目。2021 年 ShardingSphere 核心团队成立了商业公司 SphereEx （思斐软件）。
2
ShardingSphere 商业“秘籍”
ShardingSphere 是Apache 顶级开源项目 ，SphereEx 是基于 ShardingSphere 高效、稳定和开放的内核，打造的新一代数据库增强引擎。面向架构、面向研发、面向运维等角色，在不同的场景中提供更便捷和高效的解决方案。
上图是 SphereEx-DBPlusEngine 的产品架构。对上层的应用，DBPlusEngine 可以支持多种开发语言。对下面的数据库，在开源的基础之上，DBPlusEngine 增加了包含开源数据库、商业数据库以及国产数据库等更多数据库产品的兼容和支持，未来还会不断地增加。中间的可插拔的引擎部分是众多的功能模块，可以独立使用，也可以组合使用的功能集，包括了分布式数据库解决方案、数据安全解决方案，以及数据库替换解决方案等。
核心优势:站在数据库角度来解决各种各样的问题。面向应用和数据库做到免改造。
3
三大核心解决方案
第一：分布式数据库的解决方案
解决海量数据的高并发场景下，数据操作的效率和存储的这个扩展的问题；
第二：免改造的数据安全的解决方案
在数据安全的场景当中，通过 SphereEx 对数据进行加密的存储，包括数据的脱敏展示，权限管控，包括高危操作的拦截等；
第三：数据库替换解决方案
这个方案目前在国内，尤其是近几年，热度比较高，解决了数据库替换成国产数据库的过程中，平滑替换，包括替换过程当中双轨运行，也就是数据的双写，以及我们面对各种各样的系统， SQL 转换等问题。
SphereEx
分布式数据库解决方案
1
免替换分布式数据库解决方案
免替换：以保留原有数据库技术栈为前提，通过中间层进行扩展。一句话总结：在不更换原有数据库架构的前提下，通过 SphereEx 来实现近线性的提升性能，在兼顾单机数据库的稳定的同时，满足存储和计算的动态扩容。
研发视角：
对于研发大家非常关心的是，如果改系统，可能改多少？对研发影响有多大？工作当中要投入多少；
左侧的水平分片，可以时间将原来的大的物理表，通过中间层，去切分成多个小表，它的逻辑都是在我们这一层，原来的 SQL 是什么样，现在还是什么样；
通过物理拆分，灵活的分片策略，也能保证多种业务的对接，包括自定义的分片算法。启用之后，SphereEx 还可以搭配读写分离的能力、负载运行的能力来为业务启动提供最大吞吐。
运维视角：
管控：右下角的这个可视化的一个管控端，图形化的方式对资源进行管理，包括配置以及监控。
重分片：使用一段时间之后，比如我们的业务可能增长得特别快，现在已经拆分的表，之后它单表又特别大的情况，我们还提供了在线的二次扩容，也就是重分片能力，可以为企业业务快速发展保驾护航。
右上角图是大概的一个过程，实现的原理，后台做全量的数据同步，日志是做位点，去追增量，还可以支持在线数据比对，在合适的时间进行一次版本切换，这样就完成了重分片。
使用这个方案，对于底层数据库来讲，高可用怎么保证？
SphereEx 产品在中间层可以去主动探测底层角色的变化。比如，主库故障了，会根据设定的探测机制，一秒、两秒探测一次，去重新纠正流量，整个过程对上层无感。
以上，就是属于分布式数据库方案的整体的简介，希望以上介绍能让大家对SphereEx 这一部分二次扩容做了快速的了解，这个方案在海量数据的存储，高并发低延时的场景较为适用。
2
性能表现
左上角是 sysbench 测的数据通过一拆五的方式来提升性能，结果可见，因为网络路径比较短，中间最高的这部分都是 JDBC 。右侧数据是一张过亿的大表，通过对它进行拆分之后，得出的结论，性能可以提升到 200% 以上，性能提升的同时，延时还做了一定的减少。
ShardingSphere 之前做过和 openGauss 的实测记录是 8 节点， openGauss 测出超过 1000 万 TPMC 的性能表现；从压力端可以看到，表格当中使用的是 7 个 JDBC 接入端，然后 Proxy 端只作为管理的输入端，这是 openGauss 的场景。
右上的部分是 ShardingSphere 灵活可插拔架构的设计，开放的功能生态，去年我们也基于创新可插拔架构的设计，在数据库顶级会议 ICDE 上发表了一篇论文，奠定了工程化理论基础。
3
分布式数据库解决方案
第一种是轻量级数据库分片：就是数据分片，解决了性能瓶颈的问题，中间这张图的展示，通过中间层来实现这个性能提升，灵活扩展，平滑的迁移过渡。
第二种是统一数据库服务平台 DAS 平台，通过中间层来构建出统一服务平台。包括使用到 Driver 端以及 JDBC 端， Proxy 端来对接各种各样的开发语言，来做统一接入层，这样去对整个系统做统一治理，包括底层对接各种各样的类型的数据库。 可以实现统一接入，提升数据库性能，提升运维效率。
分布式数据库解决方案可以解决的问题：
数据存不下
数据查得慢
架构扩展难
分布式数据库解决方案的核心优势
海量数据存储
高并发 低延时
高弹性 易扩展
SphereEx
数据安全解决方案
1
数据安全解决方案
数据安全解决方案：在不改动原有代码的情况下，快速实现数据安全的改造。
随着国内近几年相关安全相关的法律的一个落地和实施，数据安全已经上升到国家层面，科技发展越来越快，生活越来越便利，同时用户隐私的泄露事件并不罕见，因此数据安全合规是所有企业迟早要面临的一件事情，我们的主要目的是让用户的数据得到合理保护，符合法律规定，同时也能够避免企业名誉受损。
在数据层面， SphereEx 提供了免改造的数据加密方案，对于业务而言， SQL 不需要改造，对于运维来说据库不需要做大的调整。那么与基于加解密接口的调用，或者是 TDE 的等业内常见的方案有哪些差异呢？SphereEx 是通过 SQL 拦截解析，在中间的过程当中，做加解密或者脱敏操作，这样可以将影响面、投入的时间降到最少最低。
当前痛点：
不清楚如何开展数据加密、脱敏合规这方面的工作，甚至不知道哪些数据值得关注；
不知道按照国家指定的某个法律法规应该怎么去做。
SphereEx 的支持
实现多种敏感数据识别算法，可满足多种法律法规合规要求；也支持用户选取指定算法来企业个性化需求；
实现表、字段级数据细粒度扫描，扫描后提供报告；用户可从中了解企业内哪些数据库中的表、字段，需要进行合规性改造（如加密或脱敏）。
此报告可直接导入安全控制台，根据这样的配置生成明确的指令。然后授权平台，也就是对接到业务侧做生效，这是整体的操作流，操作完之后它的效果就是左上角所展示的一样，对于应用程序来讲， SQL 没有转换好，所查到或者说检索到数据都是明文的，但实际上底层已经是密文存储的了，这个时候如果遭遇到安全事件，比如违规查看，数据对于他来讲是没有用的。此外包括对于一些营销场景，需要指定一些特别的账户，需要查询数据，但是有些敏感数据不能直接去看。是动态在前端的展示。就是上图中第二个黑色框中所展示内容，在屏幕前做了一定的这个遮盖，这是脱敏能力。
对于已经上线的业务，提供洗数的能力，也就是说对于存量的数据的加密改造，同时这块是不需要去开发某些小工具再去清洗，SphereEx 可以在线提供洗数，在后台可以结合用户资源情况设置对应的并发，在后台批量清洗，然后选择合适时间进行切换。
性能方面：相比很多库级表空间级，我们可以精细地精细化到字段级或者是行级，通过企业最需要的方式实现加密，避免相关的资源的消耗。
稳定性方面：产品是发展过程经历过京东大促的验证，稳定性是值得信赖的。
2
数据加密审计应用场景
数据加密安全合规，SphereEx 提供零改造、免改造的零停机的数据加密的能力。
上图中间案例，是 AWS 的一个客户，通过安全平台和 AWS 的 KMS 的整体方案，完成出海业务的在线改造。
最右边的第二个场景是与集成硬件的加密集，这种常见于像政府、央企，符合指定场景的加密诉求。
3
加密上线 & 逃生 & 密钥轮换流程
新系统上线，应用程序接入到我们之后，将原来连的数据库 URL 指定成我们，配置好相关的规则，就可以直接上线；
已上线业务的加密改造，区别就是中间有一个洗数的过程，使用 SphereEx 产品配置好加密规则，然后启动明文转密文的 Job，在后台做批量的明文密文转换，不需要业务停机。
逃生：对于逃生大家应该是比较关注，在上线过程当中会担心有些问题没有覆盖到，或者是某一天系统想降级了，不需要加密了，怎么做？首先 SphereEx 的方案是支持明文密文同时在线，对于同时在线情况回退比较好说，直接回退到明文；那么如果已经明文已经下掉的情况，比如说我明文已经删了，同时还运行了半年，这个时候我需要回退，需通过我们产品的反洗数能力，可以实现密文的数据洗回到明文。
最后是密钥轮换，结合不同的场景在指定的时间，比如是半年需要换一次密钥，通过两次的洗数即可以完成密钥的一个轮换，这个也是 SphereEx 产品内置的一个能力。
数据安全解决方案可以解决的问题：
业务改造成本高
政策解读难落地
平滑切换难度大
改造风险不可控
数据安全解决方案的核心优势
安全合规免改造
快速定位敏感数据
存量数据在线洗数
安全低风险
SphereEx
数据库替换解决方案
1
数据库替换解决方案
在信创的这背景之下，数据库替换是大家比较关注的问题。这项复杂的系统工程让很多人比较头疼。在这期间需要考虑兼容可用性，包括风险、性能、生态对接等等，这么多方面缺一不可。
怎样高效落地，出于这项工作的本身的复杂性，替换过程更多的是采取流程加工具支撑方式，流程上大概包括调研、实施、上线、运行，不同的阶段需要对应的工具来支持。SphereEx 提供了平滑迁移的方案，包括全流程的产品和服务支持。
设计阶段，安全和回退必然是要考虑的一环。SphereEx 的异构数据双写能力，可以在代码不需要调整的同时为前提，实现数据双写，可以将所有请求去分发到异构数据库两个库当中，同时能够识别到两端数据库集群的整体状态，可以回退，如果目标端整体都挂掉了，会回退到这个 local 的事务，就是只写这些源端，保证业务为优先。
实施阶段，改造工作是相对重量级的工作，就是左下角， SphereEx 提供了自动转换的一个差异的语句，可以适应对应的方言。举个例子， Oracle 和 MySQL 的方言一定是有差异的，通过 SphereEx 可以实现相应的转换。尽量去减少业务改造的成本，尤其是对于一些用户使用的比较老旧的系统，甚至集成商已经可能不再合作了，也不太好改源码，这种情况下风险转换就体现出它的对应价值。
上线投产阶段，数据一致性校验也是必不可少的，包括频繁的切换，就是右侧的这两项的能力了。SphereEx 提供异构数据库的数据比对，以及在上线过程当中源端和目标端流量的切换，保证异构数据库和目标端压力的可靠性。无论在研发还是运维角度，SphereEx 目标都是尽可能减少企业在其中精力的投入，提升替换的效率，降低风险。
性能优化：由于架构替换带来性能问题，目标端性能不足，SphereEx 通过横向的这个数量来去弥补，提供更多的可扩展性。
以上就是 SphereEx 数据库替换解决方案的快速介绍。
2
典型场景
数据库替换主要是面向监管类，或者是在信创过程中有明确改造指标的一些企业。中间的这张图是通过 SphereEx 中间层做了双写，是一个国企的案例，从 Oracle 迁移到某国产库，然后通过双写能力双轨运行。
最后这里再回顾一下数据库替换的整体方案，对于兼容的改造的成本，平滑挑战的问题，以及风险的问题，通过 SphereEx 的数据库替换方案可以来避免。
从开发角度：SphereEx 提升了开发效率，降低成本，缩短研发周期，减少重复的劳动。
从运维角度：SphereEx 产品希望可以帮助用户降低运用访问和数据安全分配的风险。
从管理角度：SphereEx 产品提供了统一数据库的访问管理功能，用户可以也可以通过我们做这个统一的管理监控，降低风险。
最后在 SphereEx 的方案的里面，我们可以对接不同的数据库，也在增加更多数据库的支持，希望后续大家有机会做更多的交流。
*本文由 SphereEx 根据分享嘉宾代野在“开源江湖 1024”活动中的分享实录整理编辑
