数据是架构的中心

二十年前似乎没有像现在这么热衷于谈架构。我想其中最主要的一个原因就是数据量不大。因为数据量不大，所以当数据在一个数据库中的时候没有什么问题。而一个数据库的系统中是不会有复杂架构的，甚至都没有架构这么一个概念。

今天几乎每个技术人都会说架构，那就是因为数据库很多，不管是同构的还是异构的。数据之前还要流动。之前看到过这样的话：数据的产生，数据的存储，数据的消费，数据的流动……只不过是根据不同的需求，变化数据的形态和服务方式。可以说我们的IT系统约等于= 业务逻辑 x 数据。举个例子一个电商网站，浏览商品就是对数据库发出select的命令，查询到了数据。（当然现在商品都有图片等信息这些是由CDN处理），但是基本信息都是从数据库中获得。这里的数据库有RDBMS这种关系型数据库，也有NoSQL数据库。如果下一个订单，那么就是对数据库执行一个Insert into的语句。如果进行支付，那么就是执行一个UPdate的命令进行扣款和减库存。如果两个系统要交互就是要通过接口，而接口的实质就是数据交互。可以说基本都是围绕着数据展开的。

在最近十几年的工作中越发发现很多问题都会归结到数据问题、甚至直指数据库问题。比如说烟囱建设是数据问题也是数据库问题。相互系统的数据是隔离的形成了信息孤岛。再比如说OLTP系统到OLAP系统遇到的是裁员ETL还是CDC的技术路线之争，说到底还是数据问题和数据库问题。又比如说当系统采用分库分表后的扩缩容问题，分库分表以后的数据汇聚查询问题也是数据问题和数据库问题。其实本质上的原因就出在没有将数据层打通。

当十几年前微服务开始盛行的时候，这一个问题再一次形成了历史事件。大家热衷于学习互联网公司的案例。将一个数据库拆分成若干个数据库。按照表的属性进行划分。而殊不知大型互联网企业的业务面临巨大的不确定的负载挑战，从头到尾构建了一套IT体系，完全适应这个IT基础平台和技术堆栈的。这些是完全贴合自己业务场景量身定做的。

大型互联网企业也在做技术输出，很多传统企业也接受了这种技术输出。但传统企业往往只能学其表，引入大型互联网企业的技术的同时也引入了IT的复杂性，但是并没办法掌握解决复杂性问题的方法。很多企业或者团队低估了复杂性所带来的成本，因此过于强调了敏捷和可扩展性带来的好处。

这里又提到了敏捷开发，其实不是所有场景都适合敏捷开发的。比如消费互联网的to C的业务场景会更加合适一些。实际to B的业务场景为代表的长流程的业务做不到敏捷，是因为有的需求从提出、设计、开发到测试这个过程都是以月为单位计的。这就天生注定了不会太敏捷。同时，这些企业的业务与互联网企业不完全一样，没有每秒上千的并发，甚至没有太多的并发。本来单体架构可以较好的支持业务，而采用了微服务和中台，还引入了一堆的NoSQL技术栈和各式各样的中间件，以及数据同步技术栈。使得系统架构的复杂度上升了几个数量级。

To C的互联网企业的应用场景较为简单，所输出的技术方案和产品（含数据库和中间件）纵然有过海量并发的系统压力打磨。但是遇到非互联网行业和企业还会有很多不适应甚至无法适配。

以上并非是架构错了，而是没有意识到自己的架构不能不考虑自己的特点和场景，完全照搬别人的成功经验。

如图所示，互联网公司的架构都非常复杂。对于需要长期运行的系统来说，复杂性必然带来额外的成本，增加的成本的高低取决于系统本身的属性。放弃了原有的简单设计，从而选择了一个更为复杂，似乎也更为先进的技术堆栈。不过在这些设计中引入的复杂性，早晚还是会以运营成本的方式给予回报的。这一点在现如今的经济环境下显得尤为突出。我经历过一个例子，随着成本压力，企业要缩减系统规模。要将小系统合并从而减少资源使用量，降低成本。举例：订单和购物车之前微服务时代做了不合适的拆分为两个数据库，因为不在一个数据库中，业务上需要数据就要相互调用。因为这是紧耦合的数据，所以将这两个数据库合并。既然在一个库中有些数据直接可以通过JOIN关联查询获得，那么不在需要接口或者服务调用。那么相关的服务器、中间件全部都可以关停下架。

那么没有微服务和中台的企业有没有受到困扰呢？也是有的。不少企业的各种系统都是不同阶段、不同主体以及不同开发团队构建的。数据库技术栈都是不一样的别说其他的了，这些系统慢慢的形成了前后道工序，变成了流程的上下游。每次变更，上中下游的系统都要做改动。数据的一致性、实时性都出现了问题。每个开发团队都抱怨人手不足做不过来。我分析了这些系统的数据流向得出了之前的结论。那么就把多个数据库整合成为一个数据库。不同系统以schema形式存储。相关系统的调用直接通过表查询即可获得，所有接口全部取消。因为在一个数据库实例中，所以数据的一致性、实时性全部解决。原来一个变更要多个团队在多个系统中分别完成的功能，现在只要做一次就够了。开发团队也就随之进行了整合，再也不抱怨人手不足了。

再来谈一谈多模和融合数据库对架构的影响。不少PPT上会以复杂为荣。比如技术栈越多越好。

这就是我们刚才说的系统复杂性。复杂性也是IT成本这个问题，目前也是我们国内大部分企业现阶段面对的。2021年信通院发布了数据库发展趋势白皮书，其中提到了数据库的七大趋势。分别是：趋势一：多模数据库实现一库多用。趋势二：统一框架支撑分析与事务混合处理。趋势三：运用 AI 实现管理自治。趋势四：充分利用新兴硬件。趋势五：与云基础设施深度结合。趋势六：隐私计算技术助力安全能力提升。趋势七：区块链数据库辅助数据存证溯源。这里的多模数据库实现一库多用可以简称为融合数据库。一个数据库拥有多个数据库的特性，未来（其实已经有落地实践）企业不在需要那么多种数据库，使得系统架构不再复杂。企业使用简单的架构就可以实现和支持业务运营。

这点上国外已经率先实现了。2024年5月Oracle的23AI版本，不仅融合了主流的NoSQL技术栈，而且用现在最流行的AI加持，使得一个数据库完成了系统架构的绝大部分工作。而又配合低代码实现了全栈技术的简化。这方面我们国内的厂商正在追赶。

融合数据库在数据架构和系统架构上都是一次革命。仅一JSON融合的一个特性来说，来自多个权威机构的评价是：JSON关系二元性也许是20年来信息科学领域最重要的创新之一。

尾声：数据是架构的中心，而数据库如何使用直接影响系统架构的全景。