今天有点极端就是抨击微服务和中台了

微服务的确适用于一些企业但是不适合的企业更多

这不是我第一次在公众号说微服务的负面了。我也不是第一个说的。网上从微服务切换到单体的案例也有，都是为了企业降低了大量的成本。

主要是微服务拆分的不合理

基本都是傻子过年看街坊的做法，阿里怎么做，我怎么做。问题是阿里的业务是简单的场景，比如支付，比如电商购物。换到to B的场景中，你看看。
有很多时候我们说传统企业SQL复杂，为什么复杂？因为设计复杂。为什么设计复杂？那是因为业务复杂。为什么业务复杂？因为你和他说理发时候要坐着，他说爷我就要站着。这种太多了。
所以很多传统企业不适合，我这里说的都不绝对。凡是说的都是说大部分，请不要钻牛角尖。

所以阿里的拆分是和业务对应的。而传统企业的是长流程，甚至上下游本身是紧耦合的。比如仓储和合同、结算都有关系。你问为什么？比如我有货物在仓库那就是资产。那货物一变，资产就变了。不变就不对了。有时候在这种时候我听到解耦，我就不明白怎么解？能做的就是异步缓解。其实做过传统行业应该知道。没有什么并发，就是量大。比如事务大，处理量大。甚至我都觉得很多场景就应该使用Oracle，而不要使用MySQL。那种场景实在是让人抓狂的和想象不到的。

在这种长流程的业务中，一个出问题和几个出问题一样都是影响全局。比如原来一个Oracle，后来10个MySQL。由于是流程型，那么任意一个MySQL宕机全流程会收到影响（只是不是每个环节都有问题，但是就是全流程无法完成）。在这种情况下，任意一个MySQL数据库宕机，和一个集中在一起的Oracle宕机的惩罚是一样的。而且10个MySQL的概率还高。

经济下行不得已要合并

其实如果发现回到10年前的技术栈，你会发现没有微服务没有中台，日子也能过。然后发现系统规模大大缩小，技术人力大大缩小。变相达到了裁员的目的。

有人说那这回到了从前，不是这些年白做了？我说基本是的。因为我们做错了。追求的错了。发现错了就是要改嘛。十年动乱不是也错了就改吗？

玄学的中台，阿里都拆了

下毒的和解毒的都是阿里。可怜传统行业没法前面建设后面拆。我见过也是一个数据库拆成了N个数据库。然后接口或者服务互相调用。这是何苦啊？本来就是子查询完成的，现在要去外面走一圈或者几圈，性能和效能都降低了。
然后有人在群里问我问题。我后来从截图中发现，他的MySQL database A和database B是一个数据库实例，然后他说要走微服务。无独有偶也见过有人Oracle上schema A和schema B，也要走微服务。可见这个和数据库无关。也许读者会说，两个系统逻辑上做隔离没错。我要说的是下面的，我问如果你们把表合在一起，在一个下面也要走微服务吗？回答说是的。所以你看就是要一条路走到黑。必须拥抱微服务。
那么如果不用微服务呢？那么以上的就非常简单了。简单的在校学生也不是不能做。我想起一个段子：说国足，面对空门这种踢进去容易，踢不进去难的情况下，往往选择难度大的作为表演。也许很多时候不是为了实际，而是为了观赏效果。

万变不离其宗

架构的核心是数据（很多人意识不到这一点。还是很多人认为数据库+NoSQL+中间件这种堆起来才是架构），其实就是因为如果只有一个数据库（为了融合数据库是一个趋势），那么一个数据库承担起所有也是很正常的。ALL in one已经来了。我一直秉承着一个数据库如果能解决的事情，就绝不多一个数据库。试想在一个数据库下，架构能多复杂。复杂不起来嘛。
对于中小企业来说（中国银行和建设银行一定是各自不同的数据库），这里说的是中小企业，都是自己的财产的话，能一个就一个。不用互相隔离和调用了。ABC三个系统如果是上下游关系的话，合成一个数据库。会发现一致性问题解决， 效能问题解决了，人手问题（原来不够的现在够了，原来够的现在多了）解决了，成本问题也解决了。

觉得说的有道理的就看看，不感兴趣的就过吧。