无论多么有主见的架构师，在做数据库选型的时候，也可能会犯难。
传统 SOL、NoSQL 照旧 NewSQL？架构风格是以 久经考验的关系型数据库为主，照旧方向所谓原生的分布式架构？如果提及具体产物，那选择就更多了，TiDB、OceanBase、PolarDB、TDSQL、GaussDB、MongoDB…… 现在还有许多服务于新场景的产物，比如处理时序数据的 TDengine，处理图数据的 Nebula Graph……以及最老派又最美满的 Oracle。
如果从业务场景或即将面对的迁移成原来看，标题会更加复杂。牵扯到底层数据的选型和架构设计，有时更像一锤子交易，一旦定了某种方案，再想更换代价可不是一般的大。
差不多在 10 年前，这事儿还没有那么棘手。Oracle、IBM Db2，二选一而已。但今时不同往日，这是一个数据量急速膨胀、业务高度复杂的期间，真正让人焦虑的不是单纯的选型标题，而是将“降本提效”推向极致的数字化转型标题。
那么，除了咬牙硬选一个数据库，大概基于现有数据库的基础上自研一套存储方案，真的没有其他路可走了吗？实在也有，只不外在分布式数据库热度越来越高的当下，显得有些“透明”，那就是中间件 + 多贸易数据库的解决方案。
看到这个答案，你可能会有些扫兴。中间件方案出现的时间，尚在分布式数据库成熟之前。因此在业内很多架构师看来，这种方案在技能上不够超前，只能算是某种“过渡策略”，本质上是 NewSQL 数据库成熟前的无奈之举。
但来自金融等行业的诸多落地实践证实，究竟可能并非云云。
我们为此特别采访了 全球顶级开源项目、数据库中间件产物 Apache ShardingSphere 的作者，以及背后贸易公司 SphereEx 的 CEO 张亮，他一直对分布式架构设计保持关注，曾是京东科技架构专家、当当架构部总监。关于整个数据库行业的选型和架构设计标题，张亮有着特别的思考。
可插拔架构，大概是答案
“需求是多元化的，一部门用户得当分布式数据库，一部门用户适实用数据库中间件，甚至还有一部门得当两种都用，没有太绝对的答案”，张亮说。
这是个无错的答案，但也可以得出一个推论：如果场景是多元化的，数据库是多元化的，那么架构师应该尽量规避扩展性、兼容性欠好的数据库解决方案。
不足为奇，Oracle ACE、数据库专家韩锋也在其个人公众号里发表过类似的观点：“（关于数据库选型）为了规避路线选择、厂商绑定的风险，比较现实的方法是选择一款兼容通用性协议的产物，并且在应用中仅使用尺度数据库的用法。”
二者结合起来，我们能抽离出一些关键词：中立、兼容、尺度，对于很多在选型标题上难以抉择的架构师来说，这让中间件路线看起来更加实际。
与数据库行业不同，以 ShardingSphere 为代表的中间件层由于不涉及存储引擎，现在已将目光从单纯的水平扩展标题转向业务支持和灵活性标题，也因此得以实现对异构数据库的统一管理。
灵活性、兼容性，是数据库中间件产物的核心，也是解决“数据库选型”标题的关键。据张亮透露，近两年的重要研发重点一直是可插拔架构，以将灵活性和兼容性推向极致。好消息是，ShardingSphere 的可插拔架构预计将在将来一段时间内正式上线。
所谓的可插拔架构，是指在架构层面，将整个系统分为基座和插件两部门，插件部门相互隔离、互不影响，基座可以自由接入多个插件。可插拔架构多见于相对轻量级的前端领域，属于微前端体系的一部门，但在基础软件部门则相当少见。
张亮以为，可插拔架构情势是将来数据库中间件的重要趋势之一，一则产物须要高度的灵活性，二则还有大量的本领须要被构建，比如数据安全、异构数据网关等功能，可插拔架构自然成为了产物核心。
话虽云云，但可插拔架构的设计难度却很大，让人望而生畏。这种设计难度，大致分可为两部门来谈：
第一，可插拔架构是对 OCP（Open-Closed Principle）原则的一次彻底执行，力图仅通过增加新模块来满足新需求，旧有模块完全保持 0 修改。这意味着，可插拔架构要清晰地定义出，什么是基座，什么是插件。它对上层、下层都无感知，一切面向接口。用张亮的话说，就是：“完全面向一个抽象的、虚无的东西，不涉及任何的业务细节”。
比如，ShardingSphere 转向可插拔架构后，其核心流程里已经没有分片功能了，分片会作为可插拔本领的一部门接入到服务中。对于数据库中间件来说，几乎属于产物重定义。与许多人对数据库中间件的固有认知相悖，因为在许多人的理解中，数据库中间件不就是为了分库分表而存在的吗？
但实际情况是，单体数据库的覆盖场景依然很多，分库分表并不是 0 级功能。这是在架构层面，必须具备的关键洞察。
第二，与微服务相似，只要涉及服务拆分，就会涉及颗粒度标题。对于可插拔架构来说，须要插件化的不一定只是产物功能，比如两阶段强一致事务和柔性事务，也是能够实现可插拔的。
基于这些拆分标题，ShardingSphere 把可插拔架构分为三层，分别是内核层、功能层、生态层，分别面向数据库内核、企业功能、数据库生态进行可插拔设计。此中，查询优化器、分布式事务引擎、调理引擎等是内核层的可插拔模块；数据分片、读写分离、数据库高可用、数据加密、影子库都是功能层的可插拔模块；数据库协议、SQL 方言等则是生态层的可插拔模块。
要实现可插拔架构，除了设计难度和颗粒度拆分，其工作量也令人叹为观止。ShardingSphere 有 190 多个模块，近 43 万行代码，核心 Java 代码 29 万行，张亮回忆道：“为了做可插拔架构，老代码留了不到 1/10。”这意味着，有近 26 万行的核心代码被重写了。
可插拔架构是 ShardingSphere 追求灵活性最重要的标志之一，但它对灵活性的追求又不但限于可插拔架构。
比如，ShardingSphere 还额外提供了两种部署形态，分别为 JDBC 和 Proxy。JDBC 是 Java 访问数据库的尺度接口，Proxy 是中间件最常见的服务情势，且两者经常能够在同一情况下进行混用，以满足多用户下多类型访问的需求。
如许多种类型的服务接口，一方面服务了不同类型的开发人员，另一方面也实现了性能层面的可定制化，工程师可以结合场景调解数据库分片的键值，实现不同场景下，性能的最大化提升；反之，“全包式”数据库方案，则往往须要放弃部门灵活性，以相对中庸的方案来调换无感知、低侵入的使用体验，体现了与数据库中间件方案的差异性。
真正的开源项目，是社区说了算
如果我们要做技能选型，须要注意的另外一点是，备选产物的维护主体是谁，备选产物的基因是什么，是开源，照旧闭源？这与搞清楚产物的技能方案、技能理念同样重要。
当下，无论开源的热度如何，大部门分布式中间件、分布式存储、数据库都是闭源的，这是不争的究竟。
看到的是，大量的开源创业公司正在出现，资本也在快速进入，比如 SphereEx、欧若数网、Neo4j，以及各人熟知的 PingCAP。同时也有许多数据库宣布开放源代码，比如 OceanBase、Tendis、openGauss。
为什么在数据存储领域，开源这么引人关注？
一个可能的答案是，开源在技能层面的想象空间更大，对开发者更友好。就像 ShardingSphere 的可插拔架构，架构设计完成只是第一步，后续还有海量的不同模块的开发工作。对于创业公司来说，如果不借助社区的力气，美好的可插拔架构也可能成为公司的研发黑洞。
产物的中立性，也是导致开源项目集中迎来发作的另一个要素。尤其是在数据存储领域，最美好的答案可能是无依赖、跨多云，最差的答案才是被单一产物强绑定。
当然，开源再好，也抵不外现实的骨感。开源两年，Star 几百，花钱不少，效果为零，这恐怕是浩繁开源项目标常态。社区的健康水平，往往直接定义了开源项目标生死，这导致即便架构师想做选型，也没有太多的好选择。
在张亮看来，一个开源项目能不能乐成，大致可以分为三个维度来考察：
第一，可否耐的住寥寂，团队是真的相信开源，照旧拿开源当做贸易上的捷径。一个最简朴的考核指标便是运营时间，“开源项目一定要度过‘静默期’才会迎来发作，只做了半年、一年，是没法预估项目将来的”，张亮说。
第二，一些必备的运营技巧。张亮一方面把 ShardingSphere 捐献给 Apache 基金会，另一方面也带着项目到场了许多活动，比如谷歌举办的黑客马拉松、编程夏令营，除国内用户以外，也吸引了大批的海外开发者、学生到场到社区建设中来。
第三，观念的转变，也是最关键的部门。从小处着眼，是从“自己开发”到“社区开发”；从大处着眼，就是在真正意义上拥抱开源，而不只是嘴上说说。
“ShardingSphere 的项目发展是受社区的引导。比如说，社区以为 ShardingSphere 该做基于影子库的压测和可观察性，ShardingSphere 就真的做了。这些都不是项目自上而下的设计，只要需求发作，且在项目标 Scope 内，就可以实现。但如果一个公司在运营开源项目时，遇见所谓的偏离主线设计的社区诉求，就拒掉它，那么大概率也会影响这个项目标成长，因为它不算真正扎根社区的开源项目。”
将来的发展方向
目前相关的中间件产物，照旧把核心聚焦在水平分片、弹性迁移和 MySQL 实例管理上。
但某种水平上，ShardingSphere 可能代表了将来数据库中间件发展的核心方向之一，即 0 级功能是可插拔，1 级功能才是数据分片。开源和可插拔架构结合在一起，等于打开了数据库中间件在技能和产物维度的想象空间。张亮透露，SQL 审计、基于数据的权限引擎、多租户、TTL（Time To Live）都会被提上开发日程。
除此之外，ShardingSphere 还有一个正在开发中的构想，叫做 Database Mesh，力图实现数据库上云的原生体验，但还须要一定的开发周期。
Database Mesh 会在数据库集群之上，封装一层代理，做智能的负载平衡。传统的负载层无法识别 SQL 特征，只能用轮询或权重的方式透传。但 Database Mesh 会根据不同的 SQL，匹配计算实例的标签，更加智能选择要访问的数据库计算或存储节点。
对于架构师而言，最重要的是打开技能选型的眼界与想象力。分布式数据库对业务的侵入性更低，但中间件方案规避了对厂商的依赖标题，究竟如何选择，要以实际场景为判断依据。但这并不妨碍我们给出阶段性的推论：
很可能，在将来的 5 - 10 年间，数据库中间件都是底层架构最重要的解决方案之一，值得每一个架构师认真调研。 |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
