和平讨论，中台的优缺点

[liyunyang]

今天在朋友圈看到一个图片

然后，前几天有听到几个领导再说什么中台的不好，因为我们公司也有中台组，但是我接触的不多

请问一下各位大佬，中台的优缺点是啥？不要复制粘贴可以查到的答案

[Imgur]( )

[murmur]

中台没有什么优缺点，当你们公司造轮子做基础架构的人太多了自然就有中台了

10 个人用叫 k8s 10000 个人用就叫中台了

[sentinelK]

从软件工程角度讲，中台其实就是一个数据、服务的中转实现。
主要目的在于增强复用，加强管理。

中台的不好主要体现在于管理和运营领域，不在于技术领域。
比如中台明显增加了产品的复杂度。从而降低了全线产品的可靠性。成为了一个人为的瓶颈。
比如独立的中台团队会和实际业务团队职责混乱，边界不清等等。

举个例子，就像是保时捷 Taycan 与奥迪的 e-tron GT 共用 70%的零件，那么他们有两种做法：

1 、他们分别向供应商谈判采购。
2 、奥迪、保时捷一方出面谈判，然后零件转给另外一方。
3 、大众集团出面谈判，而奥迪与保时捷共享同一个“零件中台”。

这三者各有利弊，阿里选择了 3 。

[magicxxx123]

看中台承担了多少业务，现在我们也不想全部走中台了，一个需求要谈很久。中台的 KPI 与业务系统的 KPI 也不一致，新业务的需求基本别想太多了，但是还好反正新业务可以绕开。但是如果老业务上要追加新功能，又必须要中台配合，排期真的遥遥无期

[sentinelK]

至于说中台的流行，我个人理解，主要是借了“互联网公司产品线极度扩张，与管理层试图不削弱掌控力之间的矛盾”的东风。

中台既满足了管理层的掌控欲，又讲了一个降本增效的故事，完美击中需求。

[snxq1995]

优点：不重复造轮子，复用。
缺点：kpi 不一致，非通用需求效率低下。

也就是说在通用需求框架下特别好用，个性需求嘛，看团队和领导的地位了。

[Yuanlaoer]

中台是从业务角度出发定义的概念，完全不是技术角度的，技术仅仅是实现这个所谓看起来像是“中”的台。也就是以为着没有标准定义，吵来吵去，或者说讨论来讨论去，各自说的是什么可能都不清楚。

[k9982874]

中台没什么不好，历史包袱太重的时候可以加一层中台统一架构，但是随着时间发展，中台也可能变成历史包袱

[shellcodecow]

一家 1000 人的公司的中台， 和 一家 10000+人的公司并且有不同集团负责不同业务线的中台是绝对不一样的...
后者我觉得没有好处..

[lianglianglee]

我认为中台在某些公司下失败，主要归咎于屁股问题。
1. 业务方想扩充新功能，需要联系用到的各个中台方，等排期。违背了中台快速接入的初衷
2. 中台领导想升职加薪，只维护大业务方关系。进而导致大业务方不想开发，就把不该中台承接的也交给中台承接。违背了复用的初衷。

久而久之小业务方就会想办法绕过中台，中台就变成大业务方的后台

[zzzzzzZ]

冯大辉的逆天言论多了去了，建议独立思考。这也只是冯大辉个人的主见，我也只发表我的主见：

1 、中台只是工程的架构，它本身没有好与不好，只有适合与不适合。
2 、对于很多不足规模的企业，我认为中台这种复杂度是不适合的。但是不妨碍在技术路线上做规划，有前瞻性。这就把技术发展分为三种情况。
下策：问题发生了再说，现场学学会了再升级，遇到事故反省完再成长。
中策：不论现在是否需要，只要我会的就给公司一股脑上。什么技术牛逼用什么，从大厂出来抄到什么用什么
上策：保持一定的前瞻性，做好设计和阶段性规划。将要用上的时候，再去用。
3 、冯大辉说很多公司跟着学，掉坑里。这太正常了，这就是人性的弱点。小老板盲目崇拜大厂权威，重金挖人，抄制度妄想复刻。多少创业小公司在这个坑里交过学费。能看清就改正活下来，看不清的就倒闭。
4 、这和中台无关，他只想骂别人傻逼，不懂创业，没他冯大辉懂。中台只是个引子，就跟你哪天想秀优越，指着小学生骂这个原神游戏多傻逼。
5 、中台我就一个观点，在有需要的企业它很有用，用不上的企业它只是夜壶。用的时候拿来吹牛逼，用完了放哪都嫌臭，这就是互联网风，和触达、垂类、拉齐、打法、去中心化、私域、下沉是一个东西。

[yanng]

中台是一个巨坑，实现 70%的通用功能之后，会不断的想扩张，扩张的部分实际上根本做不好，因为他不懂业务场景的需求。最终导致做的东西不合用，业务系统又没法自己做。结果就是效率低下，效率低下了，哪还有竞争力。
另外，面对新的场景，业务团队没办法快速响应，要依赖中台的排期，而业务团队认为重要的，中台觉得并不重要，两者之间对重要性的理解，差别巨大。

[peterxutong]

人太多，没地方放的时候，就体现出中台的优势了

[garipan]

冯大辉的言论，听听就好。
要有独立思考。

[NessajCN]

啥叫中台，英文是啥？跟 library/api/sdk 这些有没有类似之处或关联？

[Still4]

优点是当多项目完全重复的业务足够多的时候，减少重复开发
缺点嘛
1 、一般来说业务不会完全一样，A 项目多个字段，B 项目多两个字段，维护起来有时候会比较恶心
2 、需求优先级沟通起来有可能会难受，比如有个紧急需求明天就要上线，没中台的时候开发调整下优先级可能一个小时就改完了，跟中台还得协调中台的人力，部门间的合作懂的都懂
3 、中台作为全局模块一旦有异常会影响所有业务，会有额外的风险
反正我是一直坚持不要搞中台

[chendy]

图片打不开，以下为才疏学浅的我的看法：
中台的用途主要是忽悠企业买咨询建系统，“只要建设了中台，就能实现数字化，走进现代化，进入高质量发展”
竞品企业落地中台了，自己总不能落后吧；竞品企业给大客户实施中台了，自己总不能落后吧。至于中台到底建成了啥样，解决了啥问题，并不是那么重要。负责项目的领导升了职，实施项目的团队挣到了钱拿到了进一步吹牛的资本，大家都有光明的未来
个人经历，21 年左右，公司各种项目材料里都在提中台，现在是 23 年底，已经完全看不到这俩字了
现在又返璞归真回到 TOGAF 4A 架构，外加一些 华为 IPD 之类的东西，颇有一种瞎扯好多年最后回到 DDD 那种感觉，至于有什么用么，能搞到项目挣到钱就是有大用的

[cbythe434]

中台没有创造新的东西，很多东西随着业务发展自然而然就长成这样，职能就是中台的职能
只不过公司大了，各部门有的东西长的差不多，搞一堆人有点浪费，立个中台当太子，只允许中台的人做
只允许中台的人做也没啥问题，聚焦专心做好挺好的，奈何大部分中台都聚焦在吃更多的盘子，无心做事，基本盘稀碎的同时，新业务也是一地鸡毛

[nagisaushio]

点开前我以为是海峡问题😂

[shinsekai]

中台是什么，我维基百科为啥搜不到

[zapper]

@nagisaushio #18 角度刁钻

[cyannnna]

1. 中台一般收入是由项目部门结算过去的，因此一般属于支撑部门。
2. 支撑部门有自己的 kpi/okr ，在需求多的情况下一定是优先服务高收入部门。

在这两点前提下，中台的问题就暴露的很明显。

低收入部门往往只能用高收入部门留下来的固定模板，无法用中台展开创新业务，因为效率太低。但是部分业务往往靠创新业务作为未来增长机会，但是高收入部门对此类机会不一定有同等兴趣。

结果就是
1. 中台成了高收入部门的外包部门
2. 低收入部门需要自己组团队做创新业务，或者接受效率下降的中台

[Goooooos]

当你每个 N 个业务有 N 套订单系统的时候，才考虑中台

[realJamespond]

前端和后端的中间就叫中台

[winteq]

有点搞笑，大辉在丁香园也搞中台啊

[xiaocaiji111]

原来是冯大辉呀，一天到晚咋咋呼呼得。贼装逼

[astkaasa]

Middleware

[kphcdr]

歪个楼，我觉得花名文化还不错，一时想不到什么明显的缺点

[cheneydog]

纯技术上我是支持中台的，只是实践中，界限很难把控。
写代码时，通用功能函数提取出来，就叫库。
整个系统，通用功能提取出来，就叫中台。
性能瓶颈通过横向扩展来消除。

[theArrowOfCupid]

我认同这个观点： https://bilibili.com/video/BV1Dw411w74H

[777777]

为什么不学 Google 单一仓库，所有人的代码都可以复用，可能国内公司怕偷代码吧

[Goooooos]

@777777 fake news

[totoro52]

@777777 这个也会有问题， 那些仓库不是一直由一个人或一群人去维护的，甚至到了后期都没人维护了，文档缺失、代码质量下降、改动变化大， 都是一个考验，阿里开源了一大堆 KPI 项目，生命周期基本在 1-3 年，有的甚至刚出生就死了，有的版本已经更新到了两位数而文档还停留在一位数版本号。

[kloudmuka]

国内内卷的畸形产物，全球一家，你在 Google 上搜 Middle Platform 全是国内的公司，很多老外看不懂这玩意儿干脆直接用国内的拼音 Zhong Tai ，最滑稽的是很多国人还靠这个概念水了不少论文

[dddd1919]

讨厌中台这个名字，一股子阿里味
本质就是想提高技术复用，叫个公共服务公共组件也就够了，连名字都要整出花来

[Rinndy]

我还以为讨论中国和台湾问题。。

[Helios0]

个人理解，中台没有优缺点，只有适不适合。在一定程度上自然而然的，中台就出发于业务，并且始终服务于业务，叫不叫中台都没什么区别，你叫它组件库都行。而妄图通过复制其他公司而建立的中台本身就是会和自己割裂的，最终就是人人叫骂。

[ntedshen]

阿里中台用户。。。

别的不说，阿里这中台还是很成功的把我的火力从阿里转到总公司了，东西有问题我周周在周会上叨逼叨本部。。。
审批茫茫多，数据权限要审批，提交要审批，发布要审批，上线修改一下要审批，转出数据要审批，连复制粘贴都有独立的权限管理。。。
写业务五分钟，审批一天起。。。
之前疫情期间本部歇业直接导致我们这边业务给干瘫痪两个多月，就因为没人审批，mdzz 。。。
感觉这玩意没个几万几十万开发者的公司确实不适合用，这边开发部门连本部顶天三位数号人就天天在这疯狂的耗各种审批。。。

运维还要考专门的资格证书。。。
但是考试的内容除了文宣以外业务全部基本都是总部干的，我们根本就没运维权限一样要考。。。
而且各种魔改开源组件给搞出了一堆奇奇怪怪的特性，背考题还得先把常识屏蔽掉才行。。。
所以之前考试我司通过的只有俩个送去凑数的看门老大爷，业务人员全跪。。。

[omniversia]

系统规模和复杂度没大到一定程度，没必要搞中台，更没必要独立出一个中台部门，
最多就是各个部门维护一个基础服务平台，就由该部门统一维护开发就行。算作与其它部门的公共服务对接平台

[kkwa56188]

那....
先不说好不好, 单说 跟着 "起花名" 这个事情 有, 还是没有呢?

[RiceNoodle]

同样是为了不重复造轮子。
如果业务方要配合基础设施的方案，就叫“中台”的话。
我为什么不选择基础设施配合业务方的方案？哦，那种方案叫第三方库/SDK/SaaS .....

[ByZHkc3]

中台就是守着一亩三分地不想给别人，但却又想包罗万象什么都归自己管，最后变成四不像。

[xuanbg]

有一说一，中台特别好用，前提是中台别沾业务。反过来，如果中台带上哪怕一点点业务逻辑，就坏菜了，必死无疑。

[OceanBreeze]

没搞过中台系统。它和微服务，有什么本质区别呢？但是冯大辉把阿里的现状归结于中台，可谓毫无依据。在我看来，阿里的问题是个战略失误，而不是技术问题。

[opengps]

让我看来特别简单，一个足够大的系统，确实前台后台已经不够用了，所以需要增加分类多出来一个中台的概念
至于为什么吐槽那么多，我认为这些吐槽的大部分人是因为跟风做了没必要做的

[digimoon]

什么是中台？专门做统一接口的中间层？

[murmur]

@digimoon 不是，你可以理解成微服务+容器+监控+....+反正在操作系统之上业务逻辑之下的都是中台，中台还可以细拆技术、业务、数据

[murmur]

所以数据库允许程序员自己建的时候叫数据库，不允许每个应用有自己的数据库必须跟专门部门申请就叫数据中台

[lovelylain]

@digimoon 前面有人说了，整个系统，通用功能提取出来，就叫中台。举个栗子，一个公司有多个部门多个产品，每个产品都有营销投放需求，投广告投活动等，每个产品都自己实现活动管理和投放太低效，特别是对于一些新的小产品。于是归纳公共特性做成中台，每个产品对接几个接口，在中台系统上配置活动和投放策略，功能就实现了，而且比你自己做功能更全，在并发性安全性上都有考虑，是不是很美好？缺点嘛，中台是服务多产品的，你要的某个特性没有，对不起得等排期，现在有更高优先级的需求。

[ZZ74]

一言蔽之
优点：有绩效。除此之外都是缺点

[awefeng]

一般一个公司折腾所谓的中台的时候：1.这个公司没活了找不到下一个方向 2. 这个公司有人需要上位。 都会导致一地鸡毛结局，本人就被这种所谓中台搞到被裁员

[oamzn]

想法很好，做着做着发现跑偏了

[dzdh]

一个公司多个业务线 每个业务线 互有重复功能或技术点。有的是个算法，copy 两个文件就解决了，有些需要三方服务甚至是付费外部服务更甚至是多个不同的外部服务在内部被二次整理封装再内部开放调用接口， 咋搞。这叫啥？

[user9121]

中台不就是公用服务吗?起个这名字. 大家都发短信.那就弄一个公共的发短信服务.叫 xxx 中台.这东西一直都有.只是造词运动出来的.

[Hellokids]

中台其实就是一个工程架构，所以经常会碰到既要又要的问题。大部分人都想更简洁的使用中台能力，恨不得中台能提供全部的业务场景，串联就能用，但实际多业务场景下中台的设计和业务侵入性的度很难把握，有可能这个业务爽了那个业务开始骂了，如果不侵入业务所有人都该骂中台啥用都没有，这是从开发的角度。实际企业只会考虑人效比，如果能提高人效比是不是中台又有什么关系了。

[nothingistrue]

软件领域的绝大部分造词，只要它是真得用来解决问题的，那就没必要关注优缺点，只要它被拿到了推广人/公司的文章上，那它就只有缺点。

你现在回头去翻翻 Java 的发展史，那些用过但消失的东西，EJB 、Struts 、J2EE ，你会关心他们的优缺点吗，它们只不过是某一段时间真能解决问题，然后又自然被淘汰。

[sentinelK]

btw：楼上很多把中台比作公共库、公共函数。这个不准确
中台在公共服务的基础上，还包含管理与统计功能。最大化的压低每个产品线接触企业核心生产资料的面积。
如此，就可以实现公司对每个产品线的量化比较、功能标准化、权限统一化等等。

既，公司可以以一个上帝视角管理每个产品线调用 api 的授权情况，每个 api 的次数、频率、返回内容等等。
毕竟对于互联网公司而言，数据与功能，本质上就是一种生产资料。所以推中台的目的也是对业务线的一次权力剥夺。

因此，中台不光是为了满足降本增效的愿景，更多的还满足了公司高层对于软件产品的把控欲望。

[junkk]

@magicxxx123 #3 和我司的很像，涉及到中台合作的需求总是会压力很大，业务面向需求可以写很多定制化的代码，而中台追求一种 [通用性] ，导致很多时候反而需要业务部门去适应中台，又要适应需要又要适应中台，且中台的排期往往更久，非常难受

[8355]

中台的核心诉求就是用研发资源统一的设计重构屎山代码，历史代码太多了，维护不了，需要一个契机把前面的业务翻一遍而已，但是你不能对外这么说，不然股东会同意吗？又不是不能用，所以研发自己解决自己的麻烦，想一套能对外说的逻辑同时可以说服老板加大投入，功能没变化还是这么多功能，但是研发干的热火朝天，通过优化技术上得到了提升对外还有吹的资本，大批 cto 跟进使用同样的方式创造业绩。

[bullfrog]

中台是一个虚无的概念，就跟气功的气一样，想让它是什么它就是什么，想怎么解读就怎么解读，也就不存在有用还是没有用

[assad]

究竟有多少公司需要做中台，适合做中台，有条件做中台，而且能去做中台，这也没个标准。各种利益纠错，技术负责人的喜好，不过不排除跟风的

[googleaccount]

总体认同的 中台是一个明显弊大于利的东西

[ihaiqing]

本人所见的中台，大概率的最终形态是一个展示业务数据的大屏系统，称之为数字化转型，满足领导全局掌控的需求

[doanything]

大公司叫中台。中小公司那不叫中台，搞这个还容易拖垮公司。

[xboy3]

中台整体是弊大于利

优点：避免重复造轮子
缺点：只要业务有变化，就得无限维护轮子，越往后成本越高

[fredweili]

我不认为国内公司可以把技术和业务清楚的切分开

[maymay5]

复用率高，但是各功能的复用率相差悬殊，需求不好加，微服务架构的还有点操作空间，单体架构的就是无限堆屎

[lbunderway]

中台是不是就是各种微服务组合

[zjsxwc]

中台 是指以 nodejs 为主的中台吗？

[jqk]

应该是弊大于利

[slzcz]

如果在业务迭代开发中做中台开发，这中台最终只会变成四不像。

[JQ]

搞中台要有掌控力，否则会失控。

[duron600]

写程序的少搞这些口袋名词为好。

[googleaccount]

@OceanBreeze 中台不是技术问题啊 中台就是战略。

[googleaccount]

看楼上 很多人都不知道阿里的中台战略是个啥东西

[Torpedo]

公司发展不同时期需要不同的架构。
当年阿里为什么搞中台？那是淘天基本盘稳固，蚂蚁、阿里云、菜鸟、国际化等等一众分公司成长迅速。整个集团希望是快速扩展，中台就是集团的发动机

现在阿里什么情况？增长乏力。最大的中台变成了阿里云。淘天营收一家独大，一众小业务和淘天协同不起来。这个时候组织架构都分散了，还中台什么？

[qingshui33]

我们现在的情况就是，中台一挂，所有的服务就都 gg ，唉

[version]

中台决定一个企业的水平...
拉跨的中台..业务部怎么厉害都没用 api 局限就在那.
中台是需要不停的变动兼容更新..如果只是发 v1.0.0 版本..那这企业也就那样.
所以一般中台都是 老板亲信..掌权之人..个个业务部都逃脱不了摆烂的中台 api 用户中台.支付中台.订单中台.

[nrtEBH]

一般没有太高的视野和岗位 不需要思考这种问题 这是 c level 才需要考虑的事情 从基层员工看中台 未免角度有些片面

[wzy44944]

中台这个概念有点泛化了，刚开始指的就是业务中台，从一个业务出发快速复制粘贴出另外一个业务，比如从淘宝到天猫，效仿的是国外一个游戏公司快速开发多个游戏的思路，在这个上面中台还是很成功的。现在的中台范围太广，把基础架构都包进去了，容易卡业务脖子，所以成熟期的业务都会去中台化，从自己的需求出发做自己的小中台。

[opengg]

降本增笑的玩意。

[Ryanel]

国内的业务都是快速试错型的，前期为了快速上线，利用中台能力没问题，确实效率高。等上线之后发展到瓶颈时，业务方就要开始玩儿花活儿达成自己的 kpi ，这个时候矛盾就出来了，想当热闹

[dif]

用别人东西，总是不放心。出问题先扯皮再找原因。
复用是个好事，过度复用那就不见得是好事了。

程序员定律，别人拉的，哪有自己拉的香。

[salmon5]

中台往往被做成了项目，项目做完了，项目组的开发领了 KPI ，拍拍屁股不管了，留下一地鸡毛