值得推荐的Docker专用基础

02.中台真的能够以搭积木的方式来快速创新业务么?

关于中台的效果，你看到的是这样的：

因为阿里巴巴的生态非常复杂，很多业务方本身也很年轻，要怎么去做，下层到底能提供什么样的支撑是不清楚的。

当有大中台思路之后，第一，我们这个体系里有什么样的能力，可以让各业务很清楚的知道，也可以让前台业务方更快的理解、选择和使用中台能力。

第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。

摘自《中台的问题，是技术的问题，还是人的问题》

实际的中台是这样的：

①中台的体系有什么样的功能，业务方根本不是很清楚的知道，而是基本不知道

事实上中台自己也没有人完整的知道中台里面各个域各个子系统的能力，更加谈不上业务方更快的理解、选择和使用了。

你可以随便打开一张某个技术大会上分享的中台架构，满满的一页甚至几页 PPT，大框小框几十上百个，对应到具体的线上运行的系统可能几百上千个，这么复杂的一个系统，怎么可能有人知道所有的功能和细节?更何况是业务方了。

至于说中台提供完整的解决方案，业务方只要定制一下就可以快速上线，说起来容易做起来难，除非业务方是准备复制一个和已有业务基本一样的业务，否则基本上是不可能实现的。

原因在于中台提供的解决方案，必然是基于已有的业务来抽象出来的“共性需求”的大集合，如果这个解决方案可定制化度很高，那么就说明可复用度比较低;如果这个解决方案的可定制化度很低，虽然可复用度高但业务可扩展度比较低。

而从中台的本质出发，中台必然会选取“可定制度低可复用度高”的方向，这就约束了只有复制一个非常类似的新业务的时候中台的解决方案才有很大价值，但是对于同一个公司来说，为何要复制两个基本一样的业务呢?

如果真的有中台选择了“可定制度高”的解决方案，当新业务和已有业务有较大差异的时候，中台的解决方案并没有什么很大价值，因为大量的工作量会耗费在定制那部分。

实际上我接触的中台是这样运作的：中台会分为很多“域”，例如“交易”、“搜索”、“会员”等，然后业务方将自己的业务需求写出来，然后拉上各个域的产品接口人和技术接口人，一个域一个域的讨论。

以“会员域”为例，讨论的时候，会员域的产品接口人技术接口人肯定很熟悉会员的功能、模型和接口。
 

最主要的区别是中台的架构演进频率会比独立的业务架构演进要快，道理很简单：中台融合了多个相似业务的发展!

举个简单例子：如果中台支持 10 个业务，其中有 1 个业务发展很快，中台就必须跟着演进，剩余的 9 个业务即使没有任何发展，也必须跟着被动演进!更何况如果这 10 个业务本身都在不断发展，那中台的演进会更快!

那是否存在某种牛逼的技术，让中台的演进不影响业务呢?绝大部分情况下都不可能，这是由中台演进的本质决定的：中台演进的绝大部分动力来源于业务，它的演进不可能做到反过来不影响业务。

这点和技术平台(存储、消息队列这类)不一样，技术平台演进的动力来源于技术更新，是可以做到不影响业务的。

④中台是某类业务的中台，不是所有业务的中台

中台的本质是提炼共性需求复用，如果业务差异太大的话，复用度不高，提炼和维护中台花费的代价抵不上中台复用带来的价值。

所以，实际上应该叫“电商中台”、“支付中台”、“物流中台”、“出行中台”、“视频中台”、“保险中台”，而不应该是“阿里中台”、“腾讯中台”、“百度中台”、“滴滴中台”。

当然，因为现在“中台”概念火爆，出现了原来很多做中间件和技术平台的团队，纷纷将自己负责的“XX平台”改为“技术中台”。

从广义的角度来说也可以，因为这确实是“各业务线共性需求”，毕竟存储、缓存、消息队列这些肯定是各业务线的共性需求，但通常情况下我们说中台时所指的“需求”，还是指“业务需求”，即客户可以使用到的功能。

所以，即使只是看到“茅台云商”这种中台项目的 PPT，也能大概率是可以推断这个项目失败的可能性会非常高：

 

（编辑：淮南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!