这个也是我看了有些行业的有感而发

• 背景涉及微服务和中台。都是我个人观点，不代表对错
• 我们说一下20年前，那时候我觉得类似工商银行和中国移动这些的业务量远比我们现在的绝大多数非互联网公司业务体量要大吧？
• 那时候也没有微服务、没有中台更加没有Hadoop。业务也能有条不紊的进行。
• 那时候是大型机、小型机和IOE架构等。

微服务其实不一定要分库

• 但是的确如果在都在一个数据库那还做什么微服务？
• 其实有不少企业和场景不适合微服务（比如长流程的，比如to B的业务场景）
• 后来微服务让每个服务都有自己的数据库这句话带起来了分库
• 不仅仅MySQL做分库，连Oracle我看有的也分库。当然这里是为了微服务和中台去分库。而不是说去做分库分表。

有句话叫一时分库一时爽，一直分库一直爽。

• 自从分库以后带来了各种问题，但是也打开了一扇门。就是对应用程序质量直线下降。
• 原来一个数据库多少要担心自己会不会影响别人，别人会不会影响自己。
• 现在一个模块一个数据库，放飞自我了。当出现性能问题时候，先增加资源，不考虑解决问题。
• 资源无法增加，那么就继续分库。不考虑解决问题。至于反噬作用，先不考虑。

以上称之为解耦

• 数据库一拆分就是解耦了。
• 但是逻辑上来说原来在一起是有道理的，现在分开就是解除耦合了吗？有没有可能他本身就是要耦合的？

问题来了

• 很多长流程的业务，被切割成多个数据库。只要一个数据库这里有问题，影响面依然是全局（原来所有流程在一个数据库上，出问题影响面一样是全局，这里我说的是性能问题。至少我这20年数据库部署得到没发生过起不来的）
• 有不少时候这些业务流程很紧密，别说分库了，即使是两个异构数据库，但是业务上是上下游的。在一个数据库性能不行时候，整体业务依然无法完成。爆炸半径依然是全局。
• 比如一个数据库是规则，一个数据库是逻辑处理。规则无法访问，逻辑处理不下去。
• 再比如转账A用户扣款，B用户收款。按说是一个事务。但是也有为了架构而架构，把这种拆成异步处理。结果比起原来，现在慢了不少，还因为消息队列可能堵塞而迟迟数据送不过去。还有可能出现数据不一致情况。
• 本来现在绝大多数企业能上TB级别的数据也不多，核心数据还是GB级别的。好好写SQL都可以应对一般业务的OLAP。
• 但是分库导致，数据无法汇聚。这时候Hadoop全家桶到了。HDFS、Zookeeper、Hive、HBase、impala、kafka、spark等等数不清的技术栈往上堆。最后可能因为时间戳的问题，数据对不上。不是多了就是少了。为了这种事情几个部门来回拉扯能有2天到一个月的内耗。每次OLAP数据库变更，还要着急多个部门告知这次变了什么。有些数据可能还要全量重来。然后数据要重新算（等多久不知道，可能第二天还不见得算的好，更别说算的准了）
• 数据库是分了，但是如果每个数据库和其他不交互，那么就是孤岛了。交互需要通过接口，然而这个效率比本地交互差很多。select from a where a.xx in (select from B where b.yy=) 一个数据库时，关联在1ms以内。
  select from a where a.xx in 调用接口/服务 多个数据库时，走网络接口关联，可能1秒以上甚至更多，还可能级联调用。性能下降1000-10000倍。
• 最奇妙的我见过有的。原本一个数据库。由于性能原因不解决，分库。分库以后需要，调用一次，就把调用的结果自己这里再存一次。多存了一份，两边数据还不一致了。
• 为了缓解（只是缓解不能解决），又来了消息队列，甚至防止消息队列漏数据或者重复（这都是基本问题没解决带来的），数据库中再记录一些log（二进制记录消息体）。结果数据库又膨胀了。

成本，成本还是成本

• 现在降薪裁员了，这么多数据库、中间件怎么办？
• 要么合并，要么关停。有时候数据库一合并发现，接口不用做了，消息队列不用了。数据一致性有了，性能提高了。

再说说代码

• 一个表可能有几十个字段到几百个字段不等。如果作为一个底层核心公共方法，应该把最核心最共用的提供给别人。然后这才是复用。
• 但是我见到各行各业也是这样select * （这包含的最多有400多个字段）作为一个公共的。也许别人就要5个字段，但是他提供了400个字段。最后送到家门口，只取5个。而这时候你说巧不巧。如果说遇到问题，要解耦，你会发现根本解不开。最底层的是包罗万象的。一动影响全局。这就是典型的双标。
• 在企业管理中，去申请权限一般来说，给一个最小的，然后逐步放开。而select * 这种提供最大化模板，等于上来就给了最高的。无法分解了。
• 说到这里又不得不抨击一下大数据（Hadoop）。我帮别人看一个问题。发现打开一个页面，这个页面运行了100个报表，这是一个公共组件。而使用者甲，可能只需要第2和第三个，使用者乙可能只要第一个。但是这个公共组件做的大而全，无法解耦。上来先运算100个。最后99%都是无用功。

小结

• 个人观点：代码应该解耦，数据库不应该。因为有时候用着用着数据就要发生联系了。很多时候数据库层面可能解不开，因为本身就是需要紧耦合的，这是由业务造成的。强行解开，后面还要强行汇聚。代价是十分大的，大到可能你觉得你的工作就是在浪费生命。