从 15 年开始，到 19 年现在为止。各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主。是某些架构师和 PM 的新出路。各种割韭菜的讲中台的课程层出不穷。

当然，吹牛逼的时候大家都是拣好的说；苦逼的东西就只有内部人士知道，中台是靠谱还是不靠谱。只凭各路英雄的演讲内容，那看起来是靠谱的。

先来看看这些公开的观点：

中台是什么

阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战

中台实际上是通用业务的下沉，企业在一个行业耕耘多年之后，一般都会形成一些公用的业务，而这些业务是可以像中间件那样进行下沉共享的。

再往前推一些，也就是比较早期人们常说的偏业务的基础服务。在概念上并不是创新。

为什么要做中台

中台解决了什么问题？

其实和把程序内的公用逻辑封装为 library 差不多，就是尽量避免重复造轮子。一个轮子造 100 遍，对部门是没有任何好处的。一个系统造 100 遍，对企业自然是没什么帮助的。早期的企业经常借鉴腾讯经验，鼓励内部竞争。但内部竞争的度往往不好把握，经常会出现“所有部门都在造差不多的系统”的现象。

中台从公司战略角度，将这些行为进行了规范化。公共的部分交给公共系统部门去做。

中台给企业带来的收益

工程方面

就像上面提到的，首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置，并在公共服务上快速高效迭代出新的业务。

数据方面

有了统一的用户、订单系统，就不会再有各种恶心的数据打通问题，不会有跨部门的数据墙。

有了统一的中台，也就有了统一的数据规范。

对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行订制开发，浪费人力。

创新方面

这一项目也很好地诠释了之前所说的“点、线、面”的理论，在“点”上根本感知不到的问题，在“线”和“面”的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新！
钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战

有了公共的中台，意味着有了相对全局的视角，更能发现单点观察难以发现的问题。在更大的业务层面进行一定的创新。听着很有道理。

真相

中台能解决问题么？是能解决的。中台能解决所有问题么？那显然是不能的。

就像微服务架构一样，架构师吹牛的时候是天花乱坠的，你做起来却发现一条路上全都是坑。

技术方面

公用业务下沉，这个理念其实很朴素。所有程序员都知道我们公用的逻辑要进行封装，进行抽象，变成 Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。

难以应对 Cross cutting concern

根据中台进行系统拆分和部门调整之后，还是会遇到 cross cutting concern，什么是 cross cutting concern：

The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns

有些需求难以避免地会影响整个流程中的所有系统，比如从技术范畴进行的一些改造(如为了完成 tracing，所有系统增加 trace id，并在 log 中默认携带)。比如从业务范畴进行的 i18n 改造。

这些改造需求一般天生就是跨系统、跨组、跨部门的。事情一带上“跨”的字眼，就不好搞了。

举一个典型的例子，某巨型互联网公司员工抱怨，在当前的微服务和中台架构前提下，做一个需求经常要改 20+ 个模块，苦不堪言，连上线顺序都不一定搞得清楚。

当这 20+ 个模块又是跨部门的时候，就更难了。君不见某司的大佬，天天都把推动其它部门做事不可能这种观点挂在嘴上。

稳定性和灵活性的矛盾

对于一个系统来说，追求稳定性，那么必然会在修改和升级上较为消极；追求灵活性，那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一，在一定程度上就得放弃另一方面。

就像傻屌网友经常讲的不做死就不会死，没有代码才是真正的稳定之道。在 Github 上 Google 程序员发起的行为艺术项目：nocode，没有 code，就没有 bug。可谓弃疗的典范。

有很多中台系统被剥离之后，因为用户众多，一旦出现技术上的问题，影响面巨大。从我的实际观察来看，中台部门的系统虽然初始立项的时候声势浩大，但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆屎。屎在转过几手之后，后来的人基本就不太想对原来的代码进行修改了。

可能有人会讲你可以重构啊。嗯，重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有。在没有测试的情况下，我们可以根据过往的系统需求文档和 PRD 来还原当时的业务场景，并进行测试补充。但你又发现，中台的性质(大多偏技术项目，基本没什么 PM 把关或者出文档)使其基本没有什么靠谱的，详尽的文档。写的复杂的中台，连业务流程都理不清楚。还想写测试，别做梦了哦。

中台与前台的模糊业务边界

在实际实践时，中台与 FT 的边界往往划得不清不楚。比如独立为中台的用户服务，经常需要不断增加的外部系统数据，如：用户“权益”状态，这些内容可能并不是用户服务本身关心的内容。但往往需求也会提给用户服务，这时候用户服务就只是进行字段存储。而状态机变化由外部系统驱动，即中台只提供 set/get。

如果对这些数据不进行有效管理，那么有其它接入方接入时，难以解释清楚字段的含义和使用场景。倘若不接受这些不相干的数据接入，前台流程系统可能会在自己内部重新建立自己的数据系统，这部分系统又极有可能和中台有功能上的重叠。

如果想要把这些数据接管过来，那么中台又需要梳理了解所有业务场景。或者需要把所有对数据进行修改的逻辑全部收拢到中台内部。这往往又会产生与中台与前台业务边界的冲突。难以给出有效的边界，就意味着无穷无尽的撕逼。这便是很多中台的两难。有些不太好划边界的需求来了，我接不是，不接也不是。

如果你去问那些中台业务部门的系统开发负责人，某些业务要不要你们来做。连这些人自己都说不清楚。

人情方面

如果要做中台，那往往需要将业务部门的一部分系统进行下沉。下沉并不仅仅是一个技术问题。如果要把系统从一个部门变到另一个部门，这一定会带来人员的调动。从情感上来讲，人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化，同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。

也有些公司在调整中进行粗暴的系统交接，如果系统需要下沉，那我直接从原来的维护团队手里夺过来，交给中台部门来管理。这时候一样会引起双方的反感：

• 交接方： 这是我们加班加点，辛辛苦苦开发出的系统，凭什么交给别人？奋斗了半年难道就是为了给别人摘桃子？
• 被交接方：这个系统原来的维护团队水平极低，代码就是一坨屎，他们不想搞了就随便扔给我们？凭什么啊我们又不是接盘侠。

即使贵司运气好，在系统交接过程中没有出现问题。那在交接后也不好说。被交接的系统在交接后往往陷入消极维护状态。这时候前台业务接入中台会比以往更加困难，这种困难使前台业务的不满积累到一定程度之后，会再次催生前台部门重新造一套新的自己的中台，而部分或全部放弃原来的中台。这样原来的中台部门便会陷入尴尬的境地。

生存空间被挤压，人也自然很难待得下去，各公司的中台部门，人跑的比香港记者都快。

部门、公司、组织架构方面

跨部门沟通障碍、跨部门目标差异

进行部门划分之后，每个业务部门会有自己的一套目标体系。部门与部门的目标(KPI)一般是不相同的，如果相同的话，那也就没必要分多个部门了。

实践中很可能的情况是：中台部门的目标是迭代策略，提高某个商业指标，让公司更赚钱/省钱。前台因为业务需要，希望能更快地修改流程，经常需要中台部门配合，但这些需求与中台部门的 KPI 不在一个航道上。

中台部门还得把需求排排优先级，把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪，不如自己实现了。

前台业务也有自己的理由：“自闭环”嘛，这词真是好用。

公司利益分配

毫无疑问，距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。中台看起来是业务，但又是公共业务，既然是公共业务，那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中，中台的强大、便捷是重要原因。

这会导致什么问题呢？没有人愿意接手中台项目，中台项目变成烫手的山芋。大佬无法在中台项目上获得红利，小弟们没法在中台项目上获得利益。中台功能确定以后，只有出事故的时候大家才想起你来。稳定运行是应该的。出事你是活该啊。

利润中心？其实是成本中心

最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营，到那个时候，这个部门将成为企业最为宝贵的资产。
钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战

在大多数公司，中台部门和基础架构一样。会被当成是包袱而不是财富。可能有些人读到这里会不太爽。我们来看看，一个公司的老板是怎么看待其技术部门的呢？

在 DDD 相关的书里提到两个概念：成本中心、利润中心。技术对业务参与不强的情况下，技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标，必须不情不愿地花钱去养你们这些技术团队。对应业务侧开发来说，想要改变老板的这种看法，需要让业务系统和业务人员之间进行强联动，将一部分业务人员变成系统人员架构中的业务专家角色，或者是研发人员自己变成一个业务领域专家，就是有些人常说的你得跟老板穿一条裤子。

从这方面来讲，大多公司的基础架构角色就比较尴尬。业务驱动的公司，基础架构并不是其致胜要素。所以不管你做的再好，只要公司没有用技术赚钱，那么这部分的支出就只能被当作单纯的成本。当然了很多做基础的大佬也根本不在乎，公司只是个练兵场。练成了带小弟们跳槽就好。

中台也是一样的，从业务一线剥离到后方之后。中台离业务的距离越来越远。公司高层渐渐看不到继续对中台进行投入的价值。对待中台的态度便渐渐变成了纯粹的成本中心。是公司财务的包袱而不是财富。

行业方面

中台建设一般是要考虑公司的实际情况的，这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向，可能来自于行业内其它公司的模式挑战。

理论上来说，只要一个公司的业务系统架构建设完成了，便已经完成了一种架构上的固化。这时行业内如果有新的模式获得了成功。公司肯定要进行跟进。但是新的模式一定意味着对原有系统、原有架构的挑战。试想，原来系统架构是针对线上交易设计的，突然有一天，O2O 模式被证明有利可图，大多数公司都开始转向线下。原有的流程、模式当然想要复用，但是这时候复用的成本很可能比重新开发还要高。眼睁睁看着竞争对手们甩掉包袱，轻装上阵，以更低的成本更短的时间攻城略地，挤压自己的生存空间。

这时候怎么办呢？大多数公司给出的方案是成立新的业务部门，在新趋势新阵地冲锋陷阵。新部门肯定也要用到原来公司的老服务，又碰到了我们的老问题：跨部门合作。新部门的成功并不会让老部门多得到多少好处，配合自然不会太积极。

如果新部门的尝试获得了初步成功，得到了后续的公司资源倾斜，获得了有效的人力资源补充。之后又会带来新一轮重复造轮子，互相不合作，互相撕逼的腥风血雨。

简直是一个轮回。

结语

经常有小伙伴说，国内某公司中台非常好，大家都在学。嗯，我倒是想问问了，如果真的做的好，某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构，和好几朵云？

作为一个技术人员，在各种乌七八糟花里胡哨的概念轰炸时，应该能够保持清醒理智，不要被各种人带节奏。