前言

自2017年阿里巴巴分享其实践多年的共享式架构——中台以来，中台的概念迅速成为互联网的一个风口，大量企业纷纷上马中台项目，经过两年多的厮杀，这个风口也走到了成果输出的阶段。近日，一篇叫《中台，我信了你的“邪”》的文章很火，文中观点“中台不是万能药，大象吃这副药，强身健体；蚂蚁吃这副药，一招毙命”、“不是IT问题，而是组织问题”、“如果一个企业奔着中台做中台，就是死”、“做或者不做，有时候就在于CEO信或者不信”迅速击中众多入局者，已经出局或者陷入泥潭的兄弟们更是感同身受，大家再次围绕中台展开热烈讨论。

学习和实践了两年多中台思想，我更偏向于“中台既不是一套软件，也不是一套服务器，而是一种理念、一套方法论，这最终导致客户接不住”。中台战略并没有错，错的是对其方法论解读不够彻底、执行方向走偏了、执行力度不够。下面整理一下我及我的团队对中台的实践和理解。

初衷

为解决企业IT“烟囱式”系统建设模式带来的重复建设、资源浪费、数据不统一、系统间交互难等问题，构建更具创新性、灵活性的“大中台、小前台”的组织机制和业务机制，让前台业务更敏捷、更快速地适应瞬息万变的市场，而中台集中整个企业的运营数据能力、产品技术能力强力支撑前台业务。

也就是说，中台的核心价值是为前台业务提供快速强力的能力支持，延伸价值才是资源复用、数据统一和业务能力沉淀，还有提升组织效能。为什么核心价值是为前台业务提供快速强力的能力支持，而不是资源复用？因为真正提升企业竞争力的是赋予企业快速试错、敏捷调整业务方向的能力以及在确认方向正确后能迅速集中企业的所有力量扩大战果，而不是节约成本。认识到这一点很重要，它直接影响下面的建设。

建设

认真拜读了《企业IT架构转型之道·阿里巴巴中台战略思想与架构实战》，它对中台方法论进行了很全面的阐述并分享了阿里内部实践的经验，是这一领域的权威之作。烟囱式的系统建设模式带来的问题一定要解决，ESB的方式并不能彻底解决，反而引入更多问题，比如系统瓶颈、链路增长。

中台架构也不是银弹，并不是引入它就能解决所有问题，也不会因为引入它架构就变得简单了。套用复杂性守恒定律来说，软件的复杂性并不会消失，只会换一种形式存在。在我们建设中台的过程中，我们遇到了很多问题，归纳起来主要有：中台与前台的界限怎么划分？中台和前台的关系是怎么样的？中台的服务应该做到什么程度？如何检验中台的价值？

中台与前台的界限

一个功能是放在前台做，还是中台做，往往为这样的问题争论不休。中台建设的重要动力之一就是服务共享，当一个功能出现在两个前台应用的时候，往往就要考虑中台来做。但是这引发了后面一系列的问题：数据进入中台，所有的增删改查都要经过中台，尤其是查询，场景多、变化快，中台应接不暇、疲于奔命；差异化特性全部进入中台，代码上面有很多的if else，数据库表上面字段非常多，甚至有大量的扩展字段，不同的应用对同一字段的存储意义还不一样。

比如一个场景：下单服务沉淀到中台，同时服务A、B应用，A应用要在订单上增加一个佣金字段，但是B应用根本没有这个东西，如果不在中台加入，前台在查订单列表的时候，就要对查询结果再分别去查这个字段，性能极差。没办法，就中台加吧···

随着业务发展，中台的逻辑越来越庞大、复杂，表字段越来越多。但，中台不是一个筐，不要什么都往里装，不然到最后你会发现它不是中台，它是大杂烩，根本改不动。

以上是阿里巴巴共享服务五大价值定位，怎么平衡业务滋养和差异化业务进入中台呢？既不能把新业务拒之门外，也不能什么都往里装。

如上图，部队运输能力矩阵，后方提供海陆空战略运输能力，前方小团队具备自己的交通运输能力。如果不划清中台和前台的界限，中台只是笼统地输出“运输”服务，前台应用走两步路都要请求中台的运输能力支持，势必造成前台应用寸步难行，中台服务混乱和疲于奔命。

要划清中台和前台的界限，必须把握好前台业务什么时候才适合沉淀到业务中台。业务下沉中台一般有以下判断依据：1是多个前台应用都需要这个服务，具有共性；2是这个服务在未来的规划中会为多个应用提供服务；3是这个服务是有建设价值的，从前台剥离后与中台对接成本更低。业务下沉中台前，首先应分析业务的构成，把核心的、共性的部分提取出来由中台建设并输出服务，差异化的部分保留在前台应用实现；其次应判断相同的服务在每个前台应用的业务、意义是否相同，如果不一样，应将其分离，用不同的业务逻辑分别实现，不要在同一段业务流程里，用很多的if else 判断。比如营销活动，团购和满减是完全不同的玩法，不能说因为都是营销活动，就把业务逻辑放到一起，然后通过活动类型再区分什么时候走什么规则。应该把他们独立出来分别实现自己的业务逻辑。

为解决数据查询问题，我们采用CQRS架构模式，将命令与查询职责分离。我们知道，在大部分的业务里面，查询需求要比写入需求大得多，且查询具有多样性、多变性，不同的使用方在不同时间的查询需求都可能不同。CQRS模式将业务数据查询能力交给专门的查询中心负责，这释放了大量的中台开发资源，让他们能更专注地做业务。同时解决了差异性业务数据保存在前台应用，又要整合中台数据的查询难题。

如上图，数据流模型，通过监听mysql binlog的方式将增量数据投递到elasticsearch，spider则用来处理复杂的、包含跨库数据的文档，采用监听主表，反查次要信息的方式投递数据。

中台与前台的关系

在领域驱动设计里面，限界之间有合作关系、客户方-供应方关系、遵奉者关系等，中台和前台应该是一种什么关系？如果上面中台与前台的界限没有处理好，将直接影响它们的关系。比如差异化业务不当下沉，对中台来说，它要对这些业务负责，中台和前台的关系就是供应发-客户方，前台有什么风吹草动，中台都得配合改。如果遇到大牌一点的中台，或者话语权弱一点的前台应用，它就是遵奉者关系，前台应用想改个什么业务，都得求着中台改，不然就无法开展业务。如果业务不下沉，中台的服务又会慢慢枯萎无人问津，最后被淘汰。以上都是不健康的关系，中台和前台应该保持合作配合的关系。

如上图，前台精兵小团队负责侦查、精准引导，后台负责提供打击能力和扩大战果，各司其职，相互配合。

服务

中台服务的粒度应该如何划分？要做到什么程度？这让我联想到政府“最多跑一次”的行政改革。同样的，中台是服务型组织，应该把每一个功能做成服务，尽可能减少前台应用输入信息，尽可能把服务范围内的业务做完，尽可能封装好响应数据。为此我们制定了以下规则：1.每个服务都能完整交付一个客户价值；2.不要让业务泄露到领域以外；3.尽量做到简单；4.扩展要向后兼容，不要轻易废止一个服务，宁愿引入一个新服务；5.用户最关注的事情要同步做，用户不太关注的事情要异步做；6.日志和行为记录是无状态的。反例：一个新增订单接口，需要前台封装商品、优惠券、地址等等详细信息，中台只根据传进来的信息做一些校验然后直接入库。这样前台会浪费大量时间精力去封装中台需要的某些信息，造成接口臃肿难用。正确姿势应该如“最多跑一次”这般，尽量减少输入，自己的业务自己去完成，不要让别人帮你做。

如何检验中台的价值

中台是成本部门，它的价值不能直接体现在盈利上，它是通过量变的积累最后产生质变，帮助企业节约成本、挖掘剩余价值、赋能组织和提高创新能力的。如果老板是务实型的，前面讲的这些东西太虚，说不过去。

那还有其他标准可以来检验中台的价值吗？在上面我们讲到，中台的核心价值是为前台业务提供快速强力的能力支持，我认为我们可以围绕这一点来检验我们已经交付的中台质量。首先，前台应用对接一个中台服务要花多少成本，它是否真的减少了前台开发人员的开发量？如果对接一个服务，（同等功能的情况下）比自己开发成本还高，那别接了，这个中台一定是失败的，它根本满足不了“快速”的定位，也不会有什么让业务提高创新能力的可能了；其次，沉淀下来的业务质量如何，它与前台的关系是怎样的，如果是客户方-供应方或者遵奉者的关系，说明其研发链路过长，一定也不能快速响应业务变化（相比前台应用自己开发）；最后，前台应用的接入量和服务的下沉量当然也是很重要的标准，如果没有人接入，也就意味着中台没有了“滋养”，它就没有必要存在了。中台的价值，我认为在精而不在多，把一两个板块做到极致，要比呼啦啦的一下把所有板块都做一遍又做不好要好，因为中台做不好，折腾的不仅仅是自己，还有前台应用和业务。

组织调整

中台战略的一个延伸价值就是优化组织结构和提升组织效能，但是，组织的调整，特别是在大中型企业，会涉及到话语权的转移和利益的重新分配，这个太难了，不是中台项目组能左右得了局面的，必须得CEO至少CIO或者CTO坚定信心强力支持，才能推行下去。大中企业我就不讨论了。在这里我想讨论的是小微企业、初创企业。正如文章开头提到的观点“大象吃这副药，强身健体；蚂蚁吃这副药，一招毙命”，我想问，蚂蚁就不适合有自己的中台战略吗？一定要把业务做起来了，业务成熟了才能开展自己的中台战略吗？这是不是有点前期是蛮荒时代，先建烟囱，等烟囱够坚固了再把它拆了建中台的意思。我认为有些人是过分关注“沉淀”这两个字了，他们认为没有业务沉淀就不需要建设中台，因为中台太贵了，贵到初创、小微企业承担不起。

在上面“中台与前台的界限”我们说到，业务下沉中台一般有三个考量，1是多个前台应用都需要这个服务，具有共性；2是这个服务在未来的规划中会为多个应用提供服务；3是这个服务是有建设价值的，从前台剥离后与中台对接成本更低。初创企业没有业务积累，但是团队应该很明确自己的创业意图和赛道，未来大概自己需要做什么是清楚的，由技术架构师和业务架构师共同制定一期中台业务，是完全可以的。而且初创企业，方向最是摇摆，当发现赛道不对的时候，需要立刻换赛道，中台积累下的能力自然有用武之地。而且这个时候没有组织调整的阻力，完全是轻装上阵。小微企业也是同理，在业务还小的时候，调整组织架构成本最低，不要等到尾大不掉才割肉放血。所以我认为，初创、小微企业，如果要做企业IT架构转型，或构建一个有竞争力的IT架构，中台战略和架构是一个很好的选择。但不要一上来就大刀阔斧，应该循序渐进。大中企业开展中台战略，我认为，即便最后组织架构要大动手术，也不要一上来就搞什么组织先行，应该先把部分板块做起来，大家看到效果，积累经验，再小步快跑推动接下来的工作。

结束语

中台只是一种理念，一套方法论，实施中台架构的贵与便宜，在于它在这个企业撬动的资产有多大，如果它要撬动几十亿的IT资产，它自然贵；如果是初创、小微企业，这时候的建设成本是最便宜的。也许不久的将来会有一种架构比中台更好，但起码现在，你看到的中台初衷还是很美的。不忘初心，方得始终。