在3月份写了一篇质疑中台的博客，后来在网上又看到了《中台，我信了你的邪 | 深氪》一文，该文早在今年1月份就指出了“中台”架构理念在企业实际实施中出现的一些问题。而近期又看到了诸多解释企业实施中台架构不理想的原因分析的文章，这些解释性文章总体的意思是说，因为阿里中台是成功的，所以中台架构应该没问题，实施不好主要是企业自己的原因，业务需求弄不清，企业自己的团队水平不够，企业一把手不重视，相应的组织架构调整跟不上等等。我认为不可否认存在这些因素，而且这些因素也是那些“非数字化原生”的传统企业信息化建设中或多或少一直存在的问题。但也不应否认，企业过去信息化和信息系统建设还是取得了很大的成功，很好地支撑了业务的运转，之所以企业会抱怨中台实施出现的问题，那是因为数字化转型的今天，企业对采用中台架构来来提升业务能力抱有了极大的热情与期望，这是中国软件行业的好事情，非常难得并应该珍惜。显然，当前中台架构在传统企业的实践中并未很好地满足这种期待。所以，我们不能一味抱怨客户，也有必要从偏理性或偏理论方面探讨一下“中台架构”本身是否存在了误导，是否有某些需要纠正的观点和理念，这样才有利于行业的发展，毕竟，中国在IT技术方面还是相对落后，绝大多都是以国外开源软件为基础构建平台或应用。因此，这在里从自己的编程经验与架构经验提点意见与建议，真诚希望架构师朋友们探讨一番，尤其是中台架构的推出者和推广者，本文如有误解中台理念之处，请及时指出和澄清，谢谢！

1.中台架构的定义首先更应该是非严肃的架构术语而非营销术语。它要经得起真正的CTO和架构师的质疑。在我看来，其所使用的理念还是有些相互矛盾的地方。当然技术与认识是不断进步的，这种现象很正常，我们做软件的人总是在不断解决老问题之后发现新问题，然后再推翻或改进过去认识，不断螺旋上升。

它强调中台能够快速构建业务应用，但是中台自身却需要慢慢演化提炼。前者看起来非常诱人，也是被大力推崇的，但是，后者却在实际上抵消了前者的好处，甚至所付出的代价要远远大于前者所带来的好处，二者之间存在一个收益（前者）与成本（后者）的函数关系和一个临界区间。需要不同的企业根据自身进行度量，或者说，中台架构的推行者们应该提出度量的体系。目前，后者却没有被人们重视，或者说已被忽略了。我感觉这就像一个魔术师在表演魔术，比如，头与身体分离，效果很梦幻，但实际上人的头和身体无法分离，所看到的效果是表面现象，观众想要的头与身体分离可能就是根本不存在的幻觉，当然，除非观众就想要这种幻觉，那又另当别论。

中台在强调去“中心化”，却又在制造“大中台“和“服务共享中心”。前者很好，是我们想要的，但是一个服务一旦被共享多了，必然就会产生“中心化”的问题，虽然不是技术上的中心化，但也是业务功能中心。想要去中心化，那么就只能减少重用（共享），增加“重复”。大家可以回想一下所有“去中心化”的技术是不是都这么干的。比如，从“中心化”的ZooKeeper的服务发现变为“去中心化”的基于流言传播的协议。虽然绝对的“去中心化”很难，但是以共享为目的的服务中心是否合理仍值得商榷。

它强调松耦合，却又极力推崇服务复用。前者很好，但是后者却是增加耦合的一个重要因素，我不是说耦合不好，耦合有时候非常好，没有耦合，事物之间就没有了关系，那就什么都做不成。但是，在服务这个级别的功能耦合就值得商榷。一个服务被复用的越多，对这个服务的耦合就越严重，当你有一个服务被所有其他服务与应用所复用之时，这个服务就是系统中的上帝式服务，一旦对这个服务业务认识发生了深刻变化，导致服务接口的业务语义发生明显变化，那么灾难就可能产生。

中台强调“大中台，小前端”。如果您坚信“二八原则”的普适性，并且，如果用代码量来度量系统规模，那么系统关键部分的中台规模应该不大，应该只占到整个系统的20%，除非，中台不是系统的关键核心部分，或者“二八原则”不适用，又或者这里大中台的“大”不是我所理解的系统代码规模而是其他的含义，比如硬件资源的占用规模，那就另当别论。就我个人而言，感觉还是“小中台”才能衍生大量应用，才符合“三生万物”的朴素哲学。而论证“大中台、小前端”理念最具吸引力的则是这样的一个比喻：前线士兵（小前端），调用后台的导弹或者大炮兵（大中台）。我认为这里混淆了一个概念，导弹或者大炮兵是为了解决前线需要打击的大量敌人的问题（大负载量），如果前线只有一个敌人，或者根本用不上导弹或者大炮兵，前线士兵就可以解决问题。因此，调用何种作战单位（职责明确的服务类型），以及多少该作战单位（服务的实例数）取决于战场的态势（前端，其实也很复杂），这个比喻其实更适合后台服务动态部署（大炮兵集群）以解性能问题（大量的敌人），这是一个使服务实例数量按负载动态扩展的技术问题。

如果一切都是中台，那么一切都不是中台。传统三层（其实是多层，业务逻辑会分进一步层）架构中前台UI（负责人机交互），中台业务执行（负责业务逻辑），后台数据（负责数据存取），这个定义很严格。在此之前，更古老的两层架构之时，前台（负责人机交互+部分业务逻辑），后台（负责数据存取+部分业务逻辑——存储过程）。“传统三层架构中的中台”是把事务处理的业务逻前台从前、后台中剥离出来，形成了独立的业务服务层。受限于技术（主要是性能），无法把分析业务也从数据库或数据仓库中剥离出来做成现在所谓的数据服务实时地参与业务处理。现在把数据也叫中台，大概是想强调提供“数据服务”，但是数据服务不是业务吗？数据本身就是描述、记录和度量业务对象、活动过程及其结果。开发数据服务，和开发其他的业务服务没有什么本质不同，无论你使用了AI算法，又或者是传统的线性分析和统计算法，在架构层面，仍不过是业务系统中的“事务处理”与“分析处理”罢了，前者按照业务逻辑的因果关系处理每个业务活动（从一个业务事实转化为另一个业务事实而已），后者，按照业务逻辑处理大批业务活动结果（业务事实），产生高级的衍生业务数据（症状、原因、走势、指导决策），并可能进一步参与到“事务处理”业务中。也就是说，一个完整的业务过程中，事务处理与分析处理可能会实时融合，静止数据与运动数据在流计算技术的推动下能够很好地互动了。那么，在云计算和流计算技术的加持下，把大规模数据分析（本质是业务分析）做成了实时性更好的数据服务。如果数据服务的本质是这样，那么，数据服务应该是传统三层（多层）架构的进一步完整落地而已。所以，业务中台与数据中台这两个概念无非是（业务的）事务处理服务和（业务的）分析处理服务的两个漂亮的别名而已，那么“中台”这个词，还是回归传统定义为好（这不代表我赞同回归来自传统大单体应用的分层架构），以避免产生混乱。但是，实际上，感觉中台概念已经造成了混乱，还出现了“算法中台”、“技术中台”这样的术语，如果没有一个定义，我们很多人确实不知道它是指的是在物理硬件到所谓业务领域服务之间的所需要经历的操作系统、虚拟机、云操作系统、中间件平台、身份认证与访问控制等基础服务之间的哪一层。技术中台的上面、下面或前面、后面或左边、右边还有什么？另外，TOGAF架构方法论中，认为架构有四个组成部分：业务架构、应用架构、数据架构和技术架构，其中应用架构与数据架构合起来叫做信息系统架构，信息系统架构与技术架构合起来叫做IT架构。因而，业务架构在IT架构之外，指导和驱动IT架构，是IT架构的需求。中台架构里的业务中台和数据中台怎么也不应该是对应TOGAF的业务架构与数据架构吧？所以，真诚希望提出或推广这些中台概念的朋友们能给出一个系统化的解释，以消除混乱。要么，就让我们回归国际IT业主流行业术语，方便国内外的同行交流。该是领域驱动设计就是领域驱动设计，该是微服务架构就是微服务架构，该是云原生技术就是云原生技术。该是什么就是什么，或者按照TOGAF架构方法论，给出不同行业企业的业务架构、应用架构、数据架构和技术架构。

2. 5G、物联网、流计算的发展，使得响应式应用等新一代云原生应用兴起，确实更需要我们对传统的架构理念、设计理念与模式进行革新，尤其是在源于大单体的分层架构而出的架构概念确实需要革新，处于领先且务实的架构理念推广者有责任至少在以下方面为大家扫清困惑：

如何从传统数据库所提供各种便利的“幻觉”中解脱出来？我们很多老一代的程序员主要与Oracle为代表的关系数据库打交道，这些关系数据库提供了强大的功能（比如，事务，现在看起来可能是“上瘾的毒品”），使我们养成了许多基于关系数据的设计模式和思维，已不适用于当今时代，但这些设计理念仍然被传承了，而缺少广泛质疑。比如，“绝对的现在”可能根本不存在。世界在持续变化，业务在不断发生，当前所见数据在你读取之后可能马上就发生了变化。”信息总是来自过去，总是代表另一个现在，代表世界的另一个视图（例如，我们所看到的太阳总是8分20 秒前的太阳）”。因此，在高速交易流下，查看商品“当前库存有多少”可能真的没有多大实际意义。另外，很多的数据一致性方案是程序员根据传统数据库能力人为制造出来的，并非业务所必须。现实中的业务一致性需要根据领域模型中以聚合根对象为代表的“聚合”来确定，一个“聚合”才是业务一致性的最小边界，也就是说，数据库事务在一个以聚合根为代表的“聚合”维护服务中使用即可，真正需要跨系统的事务少之又少。

在领域模型设计方面，如何将我们从过去在模型设计中所受存储容量、性能等约束之中解放出来，更好地还原领域业务的客观本质？比如，过去我们只表达当前时间切片下业务的“快照模型”，转变为可以表达追溯历史的“全息模型”。比如，客户类型，过去设计为“客户”的一个属性，现在则是一个独立的业务对象，客户在其生命周期中属于哪种“客户类型”均被该对象所记录和管理。因此，任何可以知道任何时间点的客户类型。又如，过去我们为了节省内存和磁盘，把很多“值对象”设计为“实体对象”，甚至有人认为任何数据都应有一个ID，所谓的“One Data，One ID”。诚然，把所有数据对象都设计为“实体对象”的好处就是，它们都有一个“唯一ID”，引用该ID就可以节省很多存储，而且在单体应用中，使用起来还比较方便。而如果设计为“值对象”就要增加值对象的拷贝，但“值对象”拷贝所产生的冗余是合理的，这种冗余符合值对象的天然定义，也有利于“去中心化”；另外，“值对象”还可以避免“实体对象”不变ID掩盖数据变化所带来的Bug或为纠正该Bug而引起的业务逻辑复杂度。“实体对象”和“值对象”是领域驱动里面的术语，我个人认为当前时代，更应该从业务内涵出发而非技术便利性出发来考虑一个业务对象到底应该是“实体对象”还是“值对象”，这是当前领域驱动设计中一个被忽视的重要问题。

在微观与宏观架构方面，如何考虑不同粒度的软件要素（函数、类、库、微服务）之间的“耦合”，合理利用“紧耦合”与“松耦合”？并不是“松耦合（增加了独立变化的灵活性，但降低了复用性）”都是好的，也不是“紧耦合”都是坏的（增加了依赖，但可以最大程度发挥被依赖者的价值—复用更多的功能）。归根到底，业务系统中什么才是真正的“数据”，所有被存储的信息都是数据吗？“计算（一种常见的业务行为）”的本质来源是什么？数据与行为（计算）相比，哪个更稳定？什么样的数据与行为应紧密耦合。数据与数据之间、行为与行为之间，数据与行为之间到底是什么样的耦合方式更好？以什么样的软件形式来体现耦合？换句话说，什么时候设计为函数，什么时候设计为类（什么时候用继承、什么时候用混入与组合），什么时候设计为库，什么时候设计为微服务，什么时候采用同步通信，什么时候采用异步通信。所以，适合于“微观架构（函数、类、库）”的功能复用理念，对于宏观架构（微服务）并不一定适用，所以，无论提出什么样的架构理念，都必须对这些从微观到宏观的架构问题提出具体的知指导原则。

最后，鉴于漂亮的PPT很可能掩盖糟糕的代码和设计，关键的中台服务应该开源，至少对客户应该开源。因为应用并不是业务系统的核心关键部分，又在不断地繁荣发展，所以开源的必要性并不大。