对国内流行的“中台”架构的困惑与质疑

“中台战略”作为一个企业的战略，作为战略的伟大成果，是无可厚非的。阿里基于自己的中台可以快速构建和丰富前端的应用，并且对外分享了这种经验与体验，我们都会非常感谢。同时，阿里中台的成就，让IT公司的老板，以及企业CIO甚至CEO们也心动不已，都期望有自己的“中台”，这一愿望也是无可厚非的。

但是，现在业界把它作为一种“架构思路或标准”进行推广，那么确实令人不解，阿里分享了中台建设成果，及若干重要原则（比如功能重用、职责单一、去中心化）和所采用的技术之外，并未就中台自身极其构成要素给出明确定义。我认为国内同行可以对其进行参考，甚至可以批判，但不能作为一种架构标准或者理念。因为阿里仅是分享自己的经验，也未将其作为一种架构标准或架构思路。或许是因为阿里的光环以及业界的地位，这个“中台”似乎变成了一种架构标准。如果是这样，我就会提出以下疑问：

1.除了中台之外的东西还有什么，有没有前台和后台，如果有，它们又是如何划分的？中台与非中台之间的区别是什么？划分界限是什么？划分中台按照业务视角划分还是按技术视角划分？中台划分的好处是什么？为什么有人又按照中台这个架构思路还提出了“业务中台，数据中台，乃至技术中台”这些概念，还有没有其他什么中台，难道一切皆中台吗？

2.有人说：“小前端，大中台”，是前端的个体与中台整体比较呢？还是前端整体与中台整体比较呢？还是前端个体与中台中个体比较呢？如果是前端个体与中台整体比较，那么我信服这个结论，但这个比较没有意义。如果前端整体与中台整体比较，或者前端个体与中台中的个体比较，我认为结论未必正确，很多重视前端的企业它的前端整体和个体未必比中台整体和个体小。更主要的是，前端和中台的界限在哪里？一般而言，有过模块化的多层结构的单体应用设计经验的架构师都会知道，从最底层的“数据访问服务”到最顶层的“人机界面”之间可能存在N多层的服务组合，到底到哪一层才算是前端呢，仅仅是人机交互界面才是前端吗？如果这样划分，中台中会存在大量跨领域功能组合的服务给前端UI调用，这些组合服务主要是为了前端人机交互提供服务，会很不稳定，是否与中台提出的初衷相违背？如果这些为前端提供交互提供服务的服务组件不算作中台，而放在前台里，前台怎么能说“小”呢，而中台又怎么能算“大”呢？而且，从朴素的哲学角度出发，也是越少的东西才能衍生越多的东西，比如老祖宗所说的“三生万物”，怎么中台大了反而好呢？

2.如果说为了打破烟筒或竖井，那么与“微服务架构”有什么不同？为什么不用“微服务架构“这个IT界普遍能够接受的一种架构模式，因为微服务架构并不限定“服务”分为多少层次，无需非要把什么安在前、中、后。如果说是为了共享能力，或者说为了复用\重用业务能力，那么一个服务组件被共享的越多那么这个系统对其耦合与依赖不就更严重吗？这些个中心化的服务不就成了“上帝式服务吗”？一旦这个服务的接口发生变化，大量依赖这个服务的其他服务不都要变更吗？除非我们所有的业务服务都能像DNS或身份认证这类系统级服务那么简单且稳定，但是企业中的业务服务根本很难一次或少数几次就可以做到这么稳定，因为我们对业务的领域认识是不断深化的，越大型的企业，涉及原材料、劳动力产品&服务、生产调度、存货管理、销售和客户关系管理等多个领域，领域越多，企业业务就越复杂，就越难一次性把一个服务的业务职责范围界定的很准确，更何况“业务职责”本身也是一个主观上范围可大可小，可继续细分的概念呢。因此，我非常怀疑被广泛复用的共享中心这种理念之下所产生的体系架构是否真的有利于演进，因为其前提是能够存在稳定的服务。

3.另外，有人拿阿里最著名的双十一的海量交易来证明其中台架构的强大。我认为阿里双十一唯一能够证明的就是阿里技术架构的高明，可以吞吐海量的业务。如果你证明它是中台架构的成功，我会误以为中台是一种技术架构。如果这样，那么为什么不直接提分布式计算的相关的技术架构呢？

4.自从“中台”这个架构思路被国内业界所大力倡导的两年多来，我看过了很多国外架构师和大咖的博客和著作，没见到有人提过类似的术语和概念，甚至微服务的提出者们认为“微服务”应该 shared nothing（什么都不共享）,那么提出这个中台架构是否与他们的理念相悖呢？我们一方面倡导去中心化，一方面提建设“XXX共享中心”是否矛盾？我觉得通过多将服务多实例化部署消除技术上的单点故障这种去中心化的思路完全没问题，但是一旦共享了某个服务，而且这个服务被很多其他服务或应用所共享，那么这个服务不就成了业务上被严重耦合的“中心”之一吗？

5.中台架构，你到底是为“解藕”还是为了“重用”呢？如果你为了解藕，那么你就很难复用，因为你一旦复用，就会增加耦合，如果你为了复用，为何不用“库”来在编译期进行复用呢？运行时的服务复用的代价和风险很高啊！

6.阿里中台的形成走了大概十多年的道路吧？也就是说以阿里公司的实力，仅仅就线上销售平台（包括支付）和物流平台就用了这么多年才把业务想的比较通透，才能提炼出现在的中台里面这么多可复用的服务，更何况零售业还有NRF这样的领域模型和国外电商平台模型可以参考。如果换一个新行业，哪位大神能够在较短时间对自己并不熟悉的大型企业提炼出来稳定的中台服务呢？如果中台服务无法稳定，我们有关中台的一切美好愿望是否会落空呢？对于阿里而言，目前的中台结果是好的，成就也很了不起，但其他公司走相同的路短期未必可以获得同样的结果。同时，如果阿里各大中心真的是出于重用目的而设计的话，那么这些中心中最底层服务一旦不能满足未来业务或性能发展的需要而进行改造的话，对于阿里的程序员来说，也将是一场苦战吧！对于很多公司而言，如果我们连自己当前和未来的业务都没想通透，那么怎么可能提炼出稳定的服务呢？如此说来，基于不稳定的服务构建的应用您改得起吗？总之，阿里所得到的这个中台结果是好的，阿里如何提炼出当前中台的代价或许是我们所承受不了的，阿里提炼中台过程中，起决定性作用的是架构师的业务能力，不是技术能力或架构能力。换作阿里的架构师去提炼华为的中台，也许要很久才行，我相信吃透一个行业的业务不是短时间就可以做到的，何况具体企业的业务还有所不同呢？所以，当我们身处数字化转型时代，面对不断创新业务的局面下，考虑如何构建一个松耦合的，可演进的架构，使我们的系统随着对业务认识的不断深化而不断演进是不是更加现实，也许有一天，我们对业务世界的认知达到了一定高度，使得架构中的某些服务能够较长一段时间的稳定，但从架构本身来讲，它仍然保留灵活的向前演进的能力。

因为国内企业界如此推崇中台架构，不得不多方学习，仍不得其解，所以上述困惑和质疑，憋了好久。如能释疑解惑，感激不尽，因为不仅是我，我从有些同事、朋友甚至客户那里都或多或少听到过有关中台在上述某一方面的困惑与质疑！为了进一步表达我的质疑来源，我会整理一些大咖有关“功能重用与耦合及重复造轮子”这个话题观点，以及我自己的认识。