可能有些朋友听过系统架构但是未必听过数据架构。其实架构是围绕着数据库而展开的。我们举几个例子：
1、如果一个系统就一个数据库（没有数据库的系统几乎没见过，至少有要一个吧），那么这个架构复杂不到哪里去。
2、如果一个系统有多个数据库（这里指的是同构的数据库），那么这些数据库如果全部都是独立的，那么就是烟囱架构。
3、如果一个系统有多个数据库（这里还是同构数据库），这些数据库之间有相互关系的，那么这就是微服务架构或者中台架构。
4、如果一个系统有多个数据库（这里是异构数据库），那么就是复杂多了。涉及到了异构数据库之间的数据同步、涉及到了关系型和非关系数据库之间的交互、涉及到了NoSQL的缓存、分片、节点、分布式这些听起来可以唬人的，其实大同小异的概念。
5、如果又觉这么多同构异构数据库分的太多了，要统筹查询，这里就要把这些数据进行集中到一个平台上来进行查询和分析。这就是大数据。
以前套用三国演义的一句话分久必合合久必分。
分是因为数据量多了加上优化到极致硬件还是处理不了，就分。20年前的硬件处理TB级别的数据就差不多了。PB级别的处理不了。
合是因为分的实在太开了，使用起来非常不方便，必须合在一起，分的代价比合在一起还要大。现在的PC服务器和20年前的小型机比起来，属于一个级别的。
有一次帮别人参加一个会议，主题是架构评审。当时问题是用了MySQL的主从架构，设计的是一个事务写的操作在主库，读的操作在从库。遇到了较大的问题，说白了这样做几乎不可能达到他们想要的效果。别说MySQL，其他的数据库也没有这样做的。其他数据库的架构上都没有说一个节点上的写和其他节点上的读有一致性的。当然强一致的可以，比如Oracle的RAC和MySQL的MGR等等吧，我就不一一列举了。
我们别说现在主库上执行的SQL有好几秒，就是主库上执行10ms，从库接收和执行也要几个ms，不能做到实时。真正应该做的读写分离是，事务内的读写都在主库，而报表、运维之类的读在从库。而不是事务跨主从读写。
不少人还是担心全部在主库压力承受不了。其实大可不必担心，我拿一个数据2005年财付通一天10万笔交易，用的是MySQL4的单机。今天我估计大部分企业的交易没有达到一天10万笔。如果有这个担心，我们就把表设计好、SQL写好、实现逻辑写好。那么绝大部分问题都解决了。
天龙八部扫地僧说：少林绝技每一项都可以致人于死地，所以每一项都要相应的佛法来化解。只有佛法越高深、慈悲之心越高的高僧才能练习这些绝技，否则内在修为达不到，强行运功，早晚有一天会走火入魔。最后伤及五脏六腑，性命不保。而佛法达到一定程度的人，反而不屑于学习更多的绝技。
其实经历过强压和高并发的人知道，真正的绝杀一定是简单、简单再简单。越复杂的越难以高并发。每次遇到不停的扩展机器、分库分表、以及引入各种缓存、中间件、消息队列、流式计算、大数据等等就发现其实根本没发现问题的本质。即使这样以后发现实时性和一致性都不能保证。
