中台之拆与不拆

字数 3338阅读 1293评论 0赞 1

最近几天又盛传阿里彻底“拆”了自己的中台。起因只是张勇对阿里的中台不满意，太重、响应慢，所以要打薄、轻量化，以求敏捷化。这是彻底拆中台吗？显然不是。有时候看到某些人在那里哗众取宠，真的又好气又好笑。阿里中台虽然不是十全十美，还是有可取之处。用批判的观点来取其精华、弃其糟粕，才是合适合理的方式。没必要一会儿把它捧到天上，一会儿又踩到脚下还要再跺几脚。否则只会显得自己的没有底线。

我们说过，中台的实现方式有 2 种，一种集成，一种重构。阿里由于其体量和对中台的理解，是用集成的方式构建的中台，是加层，所以中台会越来越重。现在阿里所谓的“拆”中台只不过是想为自己减负，要减层，打薄中台，实现快速响应。

所以什么样的中台需要拆？什么样的中台不需要拆？这要根据具体的现实情况来确认，而不是一窝蜂的建，一窝蜂的拆。效率才是中台追求的目标。所以阿里不是在拆中台，而是在优化中台。但到底会采取什么样的方式来优化中台还不清楚，但我们想一定会是做减法，而不能做加法。

中台的效率其实在于两个方面，一是复用粒度，二是调用层次。中台的本质是复用。但是很多人习惯于炒概念，把什么都当中台，眉毛胡子一把抓。所以中台就很庞大，所以中台也就可能会很臃肿。这跟我们所追求的效率是背道而驰的。因此构建中台，第一步就是要定义好中台的可复用粒度。不是把数据仓库、大数据平台等拿过来换个名字就叫中台了。那是两回事。合时的复用粒度才能尽可能多的被复用，尽可能多的减少工作量。粒度过大，可复用的机会就少；粒度过小，流程逻辑就会复杂化。我们在谈微服务架构的时候特别强调过“链路最短原则”，对于中台建设同样是适用的。要高效支撑前端应用，中台的链路就不能太长，最好一个步长，一跳完成任务。

# 一、 复用粒度

复用粒度是中台建设的一个重要指标。软件其实是一直都在追求复用的。从代码块复用，到函数、方法、过程，再到类、包、库、组件、服务、平台等，都是不同层次的能力复用。复用的粒度是不一样。在不同的阶段和不同的软件项目中，复用的需求也是不一样的。但其共同的本质是“可复用的逻辑单元”。特别随着软件系统的大型化和复杂化，为了有效地组织软件工程的实施，必然要求在不同的层次实现“可复用的逻辑单元”结构，以提升效率，减少重复工作，同时降低出错的概率。

我们一再强调中台的概念不是个纯粹的技术概念，而更多是业务系统概念。前中后台的概念也早就有之，但在这里其本质是可复用能力。但是这个“能力”多大合适，该怎么构建这样的可复用能力，并没有多少人说的清楚。所以很多人把平台当作中台，却无法抽象出真正的中台概念。我们说过“平台支撑中台”、“中台支撑应用”，而平台是构建、运行在基础设施资源之上的。把平台和中台、中台和应用（以及平台和基础设施资源）分离，不就很清楚前中后台是什么了吗？

那么中台的粒度该怎么定义 ?  其实利用微服务架构和主数据的思想把中台可复用能力服务化，就相对比较容易构建企业服务中台。虽然每家的中台可能是不一样的，但思想和实现方式是一样。

![](/home/attachment/202108/04/1216527_162804805821949.png)

首先通过顶层规划来划分前中后台层次结构，比如数据平台、技术平台或技术工具等。基于技术平台和工具等构建技术中台服务，常用的服务比如日志服务、认证服务、权限服务等都可以通过技术平台的能力提取为可复用可共享的技术中台服务（这些服务可能包含一到多个子服务），也可以通过 API 等方式对外提供服务。这就为应用的敏捷编排提供了便利。也就提升了应用开发的效率，实现了敏捷。数据中台服务的实现会更难一些。毕竟可复用数据服务的规划和定义取决于公司数据治理的能力和数据质量。在定义数据服务粒度时，主数据是绕不开的对象。其实主数据已经给我们了非常好的数据服务粒度划分依据，比如客户主数据，所有客户的行为操作都可以定义在可复用“客户数据服务”中，而根据实际情况，客户也细分，比如个人客户和机构客户是两个有较大不同属性的对象，就可以分别定义个人客户数据服务和机构客户数据服务。

通过应用微服务架构和主数据思想，相对就比较容易划分可复用服务的粒度，从而定义适合企业自身实际的中台可复用服务。

# 二、 调用层次

调用层次或者叫链路长度是中台效率的另外一个关键的指标。链路越长，耗时可能越多，性能可能越差。因此要尽可能缩短调用链路，减少调用层次。

采用集成的方式，就像一个补丁摞一个补丁，各个系统始终不会成为一个有机整体，随着集成系统的增加，复杂性会随之增加。而调用链路也难以实现最优调用层次方案，随着对众多业务应用可复用服务需求 SLA 的变化，木桶原理的短板直接决定了可复用服务的能力，其性能往往难以满足需求。最终可能不得不拆掉重建。

由于采用集成的方式，数据往往是没有融合的，依然分散在各个系统中的，至多可能会统一汇聚到数据仓库或者大数据平台等，但这时的数据往往就不是实时数据了，数据的价值就会损失很多。分散在各个系统中的数据很难实现唯一可信数据源，随着接入系统的增多，哪怕通过 OneID 等方式，其所带来的额外工作量和维护成本可能超过想象。这也是我们一再不建议用集成方式构建中台的原因。

集成只能作为临时的方案。构建中台必须考虑最终的融合方案。不管是数据融合、平台融合或者应用融合，都是需要融合为一个有机整体，这样才能减少不必要的系统集成补丁，并最终消除这些补丁。融合意味着推倒重来，特别是数据融合，所以很多人根本不敢动。这也是中台建设比较难的原因之一。做中台，我们可能不得不提一下“愚公精神”，不是一蹴而就，而是持续的蚕食、优化，一个组件一个组件、一个服务一个服务、一个系统一个系统的逐步融合掉、替换掉。只要方向是正确的，坚持走下去，总好过来回的折腾。

![](/home/attachment/202108/04/1216527_162804807134925.png)

通过融合的方式，以减法的方式消除众多的集成层次，更高效的为业务应用提供可复用的服务能力。

# 三、 中台之拆与不拆

没有强大的技术就没有对业务全面的支持，没有正确的业务方向技术也不会长久。

中台之拆在于去其重。中台之“大”不是其体量大。中台的“大”在于全面，更好的支撑“小”应用。确保能更快、更敏捷的通过服务编排满足业务快速变化的需求，而不是临时去开发新的功能模块或新的服务。所以你就很难通过集成来构建中台可复用服务。这也是 ESB 发展这么多年逐步没落的一个原因。集成始终无法从根本上解决数据和应用的融合问题。所以拆除集成的一块块补丁，重构从而实现更高的效率和响应能力，这才是拆的目的。

其实我们以前也提过，虽然这些年有数据仓库、大数据平台、数据湖等，但都是集成加层的方法，并没有从根本上解决数据融合的问题。阿里提出的 OneData 、 OneID 也是集成的解决方案，但当前状况已然尾大不掉，难以从根本上实现数据融合。想要实现更高效率，必须逐步拆掉重建。

中台之不拆在于使其承重，中台就像人的腰部，承上启下。要灵活敏捷，腰部的力量就很重要。中台要能够承担起前台或前端业务应用的敏捷响应能力，不仅仅应用开发，应用的快速变更、弹性扩容、迁移、部署、恢复、监控等能力都需要在中台构建，所以其实中台的职责很多，管理和运维更复杂。如果没有全局的控制能力，中台其实是很难拆的，也很容易因为“拆”而带来意想不到的问题。正因为其处于中间关键位置，承担着应用的正常运行的重任，所以不能轻易拆的。

中台之拆与不拆不在于阿里拆不拆。我们也说过，虽然中台的概念是阿里提出的，但并不见得阿里理解的就深。他们天天 996 福报，也可能就没时间静下心思考，所以也可能就没那么多研究，只是先做起来，不行再换。到现在发现中台并没有达到预期，所以要改进，而不是完全拆除。

中台之拆与不拆在于自己建设的中台是否适合自己公司的实际，是否能满足业务研发和发展的需要。不是阿里怎么样就要怎么样。没必要一会儿捧到天，一会儿又踩到地。不忘初心，方得始终。

中台

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

中台之拆与不拆

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题