背景

上周一个保险的销售人员来找我完成一定的售后流程。其中有一项是请我下载一个叫 金事通的 APP。说实在的我根本没听过。她说这是政治任务。我想不是有你们保险公司的APP了嘛。为什么还要我安装。没办法先安装吧。

经历了注册、人脸识别的步骤后。可以登录了。注册短信发来的 中国银保信。很有意思不是某个保险公司，而是银保监会的。

安装以后带来的效果

然后我就看到了我所有保险公司的业务数据，什么中国人寿、太平洋、平安、新华。寿险、财险、交强险。只要是我身份证下的不同保险公司的全部可以查询。而且我觉得吧，比这几个保险公司的APP做的简洁（不拖泥带水的）。

去年退税的时候我被个税APP的数据库震惊了。现在我被这个保险的数据库震惊了。

思考

以下全部是个人猜想，这个数据库应该是银保监会作为上级监管单位，要求所有被监管的机构将数据送过来。我觉得可能有两种做法，一种是数据通过CDC这种技术数据同步。

还有一种就是接口。后者可能大一些。但是前者也不是没有可能。

我国监管类的用一句外行话说就是“应集紧集，应采尽采”。

我能排除的不是所谓的用ETL这种进行数据集中到Hadoop。而是一定是一个交易型的数据库中。因为这里的查询都是硬件是范围查询等使用到索引的场景。

这种其实很像企业中一堆子系统，尤其是微服务场景把数据库拆的七零八碎的。要查询跨数据库的业务，而进行的数据融合。比如我今天这个案例，一个用户身份证下的不同保险公司的保单（这还是跨公司的都做到了，别说那种在一个公司的会员库和订单库了）

早上看到这个文章，我转发了。公司不少人看到我说我转的好。看来都是深受其害的。

这些年，我不遗余力的说微服务的问题。因为我的工作中（特指我），几乎没看到的所谓微服务的好处。只看到带来的问题。这里有反驳的声音就是把一个数据库拆成ABCDEFG后，当A数据库故障后，BCDEFG数据库还可以工作。

但是实际是我就只见过SQL写的不好导致数据库出现问题而已。而这种问题微服务不是根本解决之道。而且纵使BCDEFG数据库还可以工作，而实际上这是一个整体流程。全流程还是走不下去。例如订单数据库CPU满了，是不影响会员数据库登录。但是不能下单啊。对用户来说最终不可用。

这里我脑洞再大一点。现在这种做法，那么是不是可以银保监会把所有保险公司的保单的数据库直接放在一起（这是脑洞，先不说合理性）。这样监管就更加彻底的监管了。各个保险公司的数据库数据隔离。至于是租户还是其他方式都可以考虑。有些数据库是有这些功能的。

架构

对于这种我曾经在《一个数据库拆分成十几个数据库的意义》中论证。我观点鲜明还是对这种持负评价的。今天有人留言说：有些项目，也没有经过充分架构讨论，可能就是一个普通程序员的决定。 确实有这种情况。毕竟他不是从数据库角度去考虑的。那么有人说为什么要从数据库角度？我也在《应用适配数据库还是数据库适配应用》中阐述过。

这里我应用黄东旭老师的话：不同行业不同系统，从技术层面来说，抽象到最高，总结成一句话就是：数据是架构的中心。数据的产生，数据的存储，数据的消费，数据的流动……只不过是根据不同的需求，变化数据的形态和服务方式。系统 = 业务逻辑 x 数据。可以说很多架构问题都是出在数据层，例如常见的「烟囱式系统」带来的种种问题，特别是数据孤岛问题，其实本质上的原因就出在没有将数据层打通。

DBA对以上话非常赞同，但是开发人员不一定赞同。

有钱时候，觉得能提高开发效率比啥都重要。然后隐形投入的运维人力和机器成本视而不见。现在穷了后，啥都要省。而且从谷歌的数据来看节约了90%的成本，谁不心动？尤其是当初被忽悠上微服务的。不是每家公司都适合。

因为微服务和中台是阿里推广的，而这两个在其发祥地基本没什么声音了。有人说这些是利好云厂商，因为可以大量卖云资源了。也是一个理由。

最后我想说的如果能意识到数据是架构的中心。其实很多问题就好解决了。就看你能不能认清楚。然后要做的就是一件事情，控制好开发的SQL质量。