我经历过很多项目，从前就一个数据库支持上万并发，存储上百亿行数据的级别是非常容易得。现如今的玩法不是这样了，而是将一台数据库能解决的事情，拆分成几十个数据库。有一次我的群里有人说有个项目将一个Oracle拆了100个MySQL，每个MySQL一主两从。也就是2比300的这样的比例。(因为Oracle也是主从，算两个吧)。这技术难度和成本上都陡增。这和最近几年流行的微服务和中台有一定的关系。以下之言代表我个人的愚见。如有冒犯请见谅。

我和多个业内大师的认同一样：架构师 喜欢 重复 造轮子。我特意分开写，这样突出一下 喜欢 和 重复，造轮子也就算了，有的时候为了生活被迫。但是如果是主观就不对了。而且还是重复。为此有些经验丰富的人不仅感慨“一台一体机能搞定的事，有些人强行拆成几百台x86，不知道图的啥，收益是啥，投入产出比高不高?”答案是一定是比原来成本高的。不仅仅是硬件，还有人工。本来可能开发人员30人，现在每个300人根本搞不下来。接下来运维也要加人。由于数据库一堆，没法出报表了，来Hadoop做大数据吧。别人都有，我们也要有。有了Hadoop数据要加工，做主题，再来30-50人。从促进就业的角度是积极的。不过如今全国都是降薪裁员不知道还有多少企业还是能这样搞下去?那回答刚才的提问，这是在图什么?

余窃以为：想想天龙八部中慕容博为什么要鼓动宋辽开战，就明白了。这是一个意思。原文如下：慕容博道：“不错，其时我慕容氏建一支义旗，兵发山东，为大辽呼应，同时吐蕃、西夏、大理三国一时并起，咱五国瓜分了大宋，亦非难事。你看不乱我怎么有机会? 如果一个系统一个数据库再加几十个tomcat。10个人搞定了。那么我还怎么凸显我的能力?根本没机会。回归到工作中来，我经历过三个典型的缩容架构。给大家说说。

案例1：某公司要做一个登录系统，用到了Oracle、MongoDB、Redis、Memcache、Cassandra。我开始不明白这是为什么?答：说要承载每秒1000个的用户登录需求，怕扛不住。我一听就笑了。如果懂数据库的就知道任何一个关系型数据库，如果用户登录这种信息采用关系型数据做的话，就是一个点查的场景，建立好索引。每秒几万都不是问题。为什么1000都担心?其实质就是全表查呀。我问到如果你担心登录?那么登录以后得浏览和下单等动作任何一个都比登录验证用户密码的动作要复杂，你不担心吗?而且据我了解，这个方案的架构是把以上5个串行的，不知道那个架构师是不是培训机构出来的。估计是想一层层减缓冲击，但是不懂数据库就这样设计了。结果任何一个环节的问题都导致整个不能用。在我的建议下，去掉了MongoDB、Memcache、Cassandra。其实Redis也可以不用。但是领导说留下吧。再去掉实在是太丢脸了。一个Oracle能每秒1000次吗? 我搭建了模型给他演示了一下，每秒3万。领导尴尬的说，嗯，够用就行。Redis还是留着吧。我知道如果这个再去掉，就实在太打脸了。为此系统稳定性急剧上升。该公司还省了一笔钱。

案例2：某公司有几十个业务系统，希望用户系统打通。结果各个系统之间要对用户的注册、注销、变更做同步。接下来就是开发人员喜欢的接口了。大量的接口。结果是不是丢了，就是慢了。同步慢导致这里能登录那里不能立即生效。丢了导致过了一天，都登录不上去。为此运营和运维压力都大。我了解了以后说你们几十个系统都是一个数据库实例，就是不同的schema，甚至有的还是一个schema。为什么要做接口?最后一个开发组长受不了了。搞毛线啊，直接访问吧。不做接口了。最后就直接走表与表之前的访问，所有系统都访问一个用户会员表。效果是，系统稳定性急剧上升。数据永远一致，而且访问效率提升1000倍以上。其实接口这个是针对外部是不得不做的，为了是保护数据。比如支付宝对银行，这是不同的企业。但是一个企业内部，其实没有必要。

案例3：某公司有三个业务系统。分了3个开发团队，分别用了Oracle、MySQL和SQLServer数据。结果流程是紧耦合的。一个公司业务的必然是耦合啊。结果是一个需求下来，三个开发团队都要做，之间还有接口，每个团队都说人力不足。结果最后该公司领导受不了了。三个数据库合并。结果是稳定性急剧上升。原来说人力不够的，现在够了。因为同样事情只做一次了，接口统统没有了。

但是如果都是这样做，天下太平了，那慕容博没机会了。你身边有这样的吗?