图片来自Pexels自2015年阿里巴巴提出中台的概念和战略以来，“中台”这个专业名词逐渐流行起来。尤其是2019年以来，各种技术会议和各种公众号都在大力宣传中台，出版社也趁着热点出版各种中台书籍。飞入寻常百姓家的感觉”。如果你在和人谈技术的时候不发表一些言论，不讨论一些中台问题，那肯定会显得你的技术有点落伍了！如果我们仔细阅读这些文章，我们可能会发现一个有趣的现象，大部分说中台的人都在做中台，很少看到用中台的人出来评论。从人性的角度来看，那些在中期肯定不会说中期不好，毕竟要看这个，王婆卖瓜不吹牛，自然买瓜的人会少一些，偶尔有几篇说有中国和台湾的问题，比如《中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费》，?，很快就会有人跳出来说，“你的能力不行，所以中台没做好”，“中台是一个业务、组织和技术的协作hnology，你的组织一定不能保证”……总之，现在随处可见。做中台的人说起中台有多好，偶尔会有几个人跳出来说自己不好，就会被质疑自己的无能！按照我的技术哲学，没有完美的技术，也没有普遍适用的技术，如果你只看到一种技术的好处，而看不到坑，你可能真的会掉坑里。虽然我不是真正负责中台，但我做过平台和中间件。具体来说，我参与了两个基于中台的业务项目。一个项目是将手游交易系统迁移到电商平台，另一个项目是在支付平台上搭建一个从0到1的钱包。这两个项目让我亲身实践了阿里和蚂蚁的中台工作，让我有机会近距离观察中台的运行机制，我对中国和台湾也有了更深的了解和了解。以我个人的经历和理解，很多关于中泰的说法都是夸大、模棱两可，甚至是错误的。接下来我就和大家说说中台到底是怎么操作的，会有哪些坑。.既然我真的用的是阿里的电商中台和蚂蚁的支付中台，就不用质疑中台能力和组织能力的不足才会出现我说的这些问题。01.中泰的价值真的有那么神秘吗？关于中泰的价值，大家看到的是：可以让各个业务部门相对独立分散，保证业务的敏感性和创新性；另一方面，利用强大的平台对这些部门进行统筹和支持，平衡集权和分权，为新业务、新部门提供成长空间，从而大大降低组织变革的成本。中台部门细化各业务条线的共同需求，尽量减少“重新发明轮子”。来源《一文读懂「中台」的前世今生》实际的中台是这样的：①业务部门不独立。基于中台的业务会划分不同的优先级。大企业对中台的影响远大于小企业。台湾的影响力远大于新业务。从形象上看，中台抱大业务的大腿，小业务抱中台的大腿，因为中台也有KPI，中台的KPI是怎么来的？当然，大部分都是来自于配套业务，大的业务在KPI数据上自然会有优势。这会造成什么问题？不管一个大业务的创新是否普遍，中台都会全力支持。毕竟是中台判断是否有共同的需求，而不是每次有新业务都吸引所有业务方。快来评价投票吧。小企业更难过。如果中台要拒绝你，只需要一句简单的“你的业务不一般”或者“你的需求太特殊”就可以了。如果小企业不服气怎么办？没办法，不会有仲裁委员会这样的机构，即使有，你也有足够的时间自己去仲裁把生意变现5次！即使中台认为你的需求是普通需求，但如果你是小企业，很可能因为优先级的原因排在很低的位置。这里的“很低”不是几天、几周，可能是几个月半年！而恰好很多初创企业一开始的规模肯定比较小，基于中台的发展模式很可能会制约创新业务的快速发展，除非创新业务有重量级的从业者挂帅。一开始，就能在中台有足够的影响力。②中台不一定能细化共性需求。注意，这里的需求不是指电商中台“交易”的粒度，而是指“交易”系统中的实际功能点。如果硬要说“Transaction”是通用需求，其实是正确的废话。其实通用需求的抽取主要是在中台从0到1搭建的时候，因为此时已经有多个业务需求的样本，更容易分析出哪些是共性的，哪些是个别的，但是一旦完成，随着业务的发展和创新，中台和业务端自然会有不同的共性需求。业务方总是希望把自己的需求归类为普通需求，因为这样可以让中台的人去实现需求。中台始终期望不要先把需求归类为通用需求，而是在多个业务有相似需求时，再抽象提炼，最大限度的复用，否则中台的每一个需求都会被认为是如果有通用需求，中台会筋疲力尽。事实上，多个商家同时提出某项要求几乎是不可能的。除了国家颁布的法律法规相关要求外，大部分业务需求都是由某个业务方首先提出的。这时候中台无法判断是不是普通需求，只能回到上面说的潜规则去操作：优先满足大业务，忽略小业务。反正不管大业务的需求是不是通用，做完数据肯定好看，中台KPI有保障；即使未来证明小业务普遍，前期数据也不多，中台很可能吃力不讨好。③中国和台湾的“轮子”会不断变化。很多朋友看到“避免重复造轮子”就认为中台已经造轮子了，业务方直接用就行了。.但是每隔一段时间它就会换轮子。比如中台的数据模型、接口、架构，其实都需要根据业务的发展而变化。为了达到中台“再利用”的目的，通常在中台推出新轮子后，旧轮子不会长期维护。否则，如果中台同时维护4~5个相似的轮子，重用就无从谈起。上升。这就要求基于中台的业务必须在一定时间内完成轮子切换，相当于业务端的被动架构演进。当然，如果没有中台，业务端的架构也必须随着业务的发展而演进。这和中台被动进化有什么区别？主要区别在于中台的架构演进频率会比独立的更频繁业务架构的演进一定要快，原因很简单：中台集成了多个类似业务的开发！举个简单的例子：如果中台支持10个业务，其中一个业务发展很快，那么中台必须随之进化。剩下的9个业务就算没有任何发展，也必须跟着被动进化！更何况，如果这10个业务本身不断发展，中台的进化会更快！有没有什么牛逼的技术，可以让中台的进化不影响业务？在大多数情况下，这是不可能的。影响生意。这不同于技术平台（存储、消息队列等）。技术平台演进的驱动力来自技术更新，可以在不影响业务的情况下实现。④中台是某类业务的中台，不是所有的业务中台。中台的本质就是把共通的需求抽取出来，复用。如果业务差异太大，复用度不高，提炼和维护中台的成本不值得上中台复用带来的价值。所以，其实应该叫“电商平台”、“支付平台”、“物流平台”、“旅游平台”、“视频平台”、“保险平台”，而不是“阿里众平台”。台湾”、“腾讯中台”、“百度中台”、“滴滴中台”。当然，因为现在流行“中台”的概念，出现了很多中间件和技术平台团队，他们改变了“XX他们负责的“平台”到“技术中台”。从广义上讲，也是可以的，因为这确实是“所有业务线的共同需求”，毕竟存储、缓存、消息队列必须是共同的所有业务条线的需求，但通常我们说中台的“需求”还是指“业务需求”，也就是客户可以使用的功能。所以，即使你只看到一个中国的PPT-台湾项目如“茅台云商”，大概率可以推断这个项目失败的可能性会非常高：图片来源：中台我信你的邪|深氪02.中台真的能创新业务吗快速搭积木秒？关于中台的效果，大家看到的是这样的：因为阿里巴巴的生态很复杂，很多业务方本身也很年轻。具体怎么做，下层能提供什么样的支持还不清楚。有了大中台的想法之后，首先我们的系统有什么样的能力，让每个业务都能清楚的知道，也能让前端业务方去了解、选择和使用中间台的能力。第二，我们提供了一个基础的解决方案，业务方可以根据自己的业务特点，根据需要进行定制化开发，对于前端业务来说会更快一些。摘自《中台的问题，是技术的问题，还是人的问题》实际的中台是这样的：①中台系统有什么样的功能？业务方一点也不清楚，但基本都不知道。事实上，中台没有人能够完整的了解中台每个领域的各个子系统的能力，更不用说业务方更快的理解、选择和使用了。你可以随意打开某个技术大会上分享的中台架构，整页甚至几页PPT，大小框架几十上百个，对应具体的在线操作系统上百个，上千个，这样的复杂的系统，怎么会有人知道所有的功能和细节？更不用说业务方面了。至于中泰提供的完整解决方案，业务方只需定制即可快速上线，谈何容易，除非业务方要复制一个与现有业务基本相同的业务，否则基本上是不可能实现的。原因在于，中泰提供的解决方案一定是在现有业务基础上抽象出来的“通用需求”的大集合。如果这个解决方案是高度可定制的，那么就意味着可重用性比较低；if这个解决方案的定制化程度很低。虽然复用程度高，但业务扩展程度比较低。但是，从中台的本质出发，中台必然会选择“低可定制性、高复用性”的方向，这就制约了中台方案只有在复制一个非常相似的新业务时才具有很大的价值，但对于同一家公司，为什么要复制两个基本相同的业务呢？如果有中台真的选择了“高度可定制”的方案，当新业务与现有业务差异较大的时候，中台方案的价值并不大，因为很多工作都会花在定制上部分。其实我接触到的中台是这样工作的：中台会分成很多“域”，比如“交易”、“搜索”、“会员”等等，然后业务方会把他们的业务需求写出来，然后拉进来各个领域的产品接口人和技术接口人一个领域一个领域地讨论。以“成员域”为例。讨论过程中，成员域的产品接口人和技术接口人必须熟悉成员域的功能、模型和接口。业务方需要向中台子域联系人说明业务需求，然后由中台子域联系人评估成员当前能力哪些支持，哪些不支持。不支持的部分是属于通用需求还是个别需求，如果是通用需求，需要给出中台的修改方案，修改方案需要成员域的架构师审核，因为中台改造会影响所有业务。如果是个性化需求，需要设计中台与业务端交互的方式，比如提供接口、配置、扩展包等。所以如果你真的做过基于中台的项目，你会发现coding时间确实少了，但是前期的沟通，后期的联调是非常耗时的。做任何一个项目，招20~30人是正常的，稍大一点的项目招50-100人是正常的。以淘宝中台为例，下面是淘宝电商中台共享事业部中交易中心的结构：图片来源：《企业 IT 架构转型之道》注：交易中心只是共享事业部的一个业务域，而同级别的业务领域，从公开资料来看??，大约有10个，交易中心有13个子功能，而这些子功能最终可能对应一个或多个实际操作系统。②中泰所谓的“牢度”是没有严格衡量的。目前各种文章都会说中泰成立后业务发展会很快，但是究竟有多快，并没有具体的案例和分析。只能看到几个案例听起来很夸张，但是没有详细的背景描述，是没有说服力的。比如新业务上线快，是因为第一个版本功能简单，还是第一个版本投入了很多人力，还是真的是用了中台？其实这两个中台项目的访问速度是不是很容易看出。从实际开发经验出发，对业务端和中台的需求进行说明和讨论，业务端和中台方案的设计和讨论，以及后期业务系统和中台系统的衔接。这些调整的工作量没有减少，反而会有所增加。因为中台在分析需求、设计方案、联调测试时需要考虑对其他业务的影响。中台能够带来的效率提升主要体现在两个方面：第一，编码的工作量确实会减少。毕竟还有很多代码可以复用。二是中台人员熟悉现有同类业务和技术。需求的确认和方案的设计会更有效率。综合看整个过程，很难判断效率高低。其实我之前在阿里游戏做过几个从0到1的项目。因为老板很重视，他们总是拉着已有的类似系统的核心开发人员去开发新项目，而原来的代码也是从原来的系统上抄来的。开发效率也很高，核心原因简直就是“专家开发”。以上是我在基于中国和台湾的开发项目中观察到的一些问题，以及我总结的一些经验。总的来说，好像是在质疑中泰，其实不然。关于中台好处的文章已经太多了。本文试图从用户的角度提供中泰看到的一些信息和问题，旨在帮助大家更全面的了解中泰。我在《从零开始学架构》一书中提炼出的架构设计三原则中的第一条就是“适度原则”，这个原则同样适用于中台。03.综上所述，总结就是：中台不是万能的。不要想着用中台来解决问题；中台！其实，提出中台的逍遥子早就告诫过：中台并不是适用于每个公司的每个阶段。在自主业务拓展突破期，“一定要做到独立团、独立师、独立旅”，否则就会成为瓶颈；但发展到一定阶段，山头太多，就需要“关停转运，合并同类项目。要求管理高效，取消重复建设。来源《中台，我信了你的邪 | 深氪》作者：李云华编辑：陶佳龙来源：zhuanlan.zhihu.com/p/339439639
