微服务的初衷大概是因为服务化成本太高，想做低成本的服务化，乃名微服务。
但病诊对了，药没开对，多数吃药的反而病情加重了，吃药后因为服务化带来的繁琐和低效更甚以前。总之，病是真病，药是错药。这一点和中台倒很像。

微服务的药方，大多是拆分邪路，restful邪路，独立布署邪路。这些都是增加成本，降低效率的。

以拆分为例批一下（这破概念毛病太多，懒得一一批了）

一个业务的复杂度不会因为拆分而减少。相反还会增加额外的技术成本，协作成本。整体复杂度是升高而不是降低的。开发效率是降低而不是升高的。

正确的做法是

1，了解拆分是业务复杂度到一定程度下，难以控制的分治之法。复杂性无法治理是前提。

简单业务用分布式微服务框架，无疑是火车拉芝麻。效率低下，成本高昂。

2，知道分治这种方法存在的问题，会增加合成成本。警惕拆分，理智分治。分治之法为不得已法。

正确的做法是一只眼看拆分，一只眼看合成。拆分以分治领域复杂度，合成兼顾学习，使用，运维低成本。

大多数人只看前者，忽视后者。这就导致大多数微服务的深入实践效果并不好。这根本上是由于微服务本身的哲学思想分治的必然结果，而大多数人难以体会掌控其中的微妙之处。很难使用的好。

但是类似springboot、springcloud等经过幸存者偏差而存在微服务框架的确是好的。

初学者使用微服务，原业务不动，基础设施换为微服务框架，最初一定会得益于大量基础设施，感觉东西好。

但是，如果不深入拥抱，只是浅尝辄止，只是将框架换为微服务，在微服务原教旨主义者看来不过是换了一件衣服。是假的微服务，是可鄙的，low的。而初学者也难以自视，多数会追求进步。而一旦深入，开始拆分业务。一定会越来越差。

这其中奥妙是第二只眼兼顾合成的要求实在是太高，兼顾合成本质是要预料未知（的业务情况）做应对，使得业务发生的时候极具针对性，使用简单底层本。这前提是大量知识和经验前提这本身已经足够pass掉大多数人了；并且内置业务变化适配也是违反内聚耦合的；其中设计还要掌握尺寸，既不过度设计，还要简单好用；玄之又玄，其难度远超普通开发甚至大多数所谓架构师的水平。很难掌控的住微妙。微服务确实是很好，却不具备方法的一般性。普通的公司、个人极少见到用的好的。

所以，大多数的微服务实践，一定是越深入越烂。所谓拆分一时爽，合并火葬场。霸王枪不是人人都hold的住的。

中台的病，不是服务低效病，而是中国式的业务驱动式开发带来的低效病，最终产生了焦油坑。本质是《人月神话》所描述的软件工程面临的深层次的痼疾。虽然是马云第一个看病，但是效者云集，一时洛阳医贵，人人皆以病为荣，以中台为荣。

虽然不少楚王细腰，但其实也是星星之火，非一日之寒。万企热热闹闹做中台，大部分还都是有病的。人月神话的病，焦油坑的病，谁没有呢？
病必定在，不过轻重缓急而已。只要软件在变，业务在变，就有病。不过是变得频率快慢，决定了病的急徐。这是软件内在的规律决定的。

中台病虽然开了一堆的药方，但仔细看看，却发现什么字都没有。另外很多数据中台，技术中台，XX中台，看起来不像药方，倒像蹭饭。

要说和微服务的不同，可能是药方都没开的出来，各种江湖偏方、野郎中纷纷上阵，万众中台，人人试药。不过至今没见到有效果的。不过吃挂了的倒不多见。这倒是不开药方的好处了，好歹乱吃的时候，还是有点辨别的；若大师开了药方，便是虽然直觉不妙，但是捏着鼻子也要硬吃下去的。