中台的“酒”瓶

酒瓶和水

中台的概念在今年突然很火,持续地火。产品不蹭一下中台的热点,自己都觉得不好意思。于是乎,看到了高矮肥瘦的各式各样的瓶子,都说是中台的酒瓶,里面有新瓶装旧酒的,更多的是装些果汁,矿泉水,不少的直接装自来水,甚至只装空气。只要不打开看,放在架子上,装扮得五光十色,十分喜庆。

需求是第一导向

中台是个概念,是个名词,尚无权威定义,本文也不打算讨论何为中台。下定义的人多了,但被认可要靠权威,我们顶多能发表下看法。公司里面已经聚合的能力集,无论有没有中台的概念,它就摆在那,叫能力云也罢,叫中台也好,它都老老实实地杵在那里。

碰到更多的是蹭热点,言必称中台,恍惚贴上中台的标签,身价上涨。红红火火的程度,以至于这个功能好像挺不错,可不可以抽出来做中台,那个能力也很好,要不要也弄过来做中台。这些话听多了,我其实很想说,同学,你想多了。

任何产品的第一导向都是需求,成为中台不是说这个功能好不好,是否可以独立出来,这写只是成为中台的充分条件。我们需要意识到下面几点:

一、有没有成为中台的需求。

中台的最重要目的是避免重复造轮子。我们首先要看有多少人需要这样轮子,而不是说能不能做出个轮子。也就是说首要考虑是要不要的问题,而不是能不能的问题。即是有多少项目有这个需求,以及如果真成为中台,有多少项目会去用。

如果我们在公司内部做一个需求调研,问将某某做成中台好不好,多半好;问你们会用吗,不少答会。但实际做出来后,可没那么多人捧场。将接入中台作为一种可选方案纳入考虑,和最终决定是否采用中台,两者的差距不言而喻,但在调研问卷分析,经常会被忽略。如果两者数据基本一致,那针对的就是痛点问题,又或者简单粗暴的领导要求。

反过来思考,如果我们要决策是否使用某中台,我们需要考虑,这个功能是否与我们核心业务紧耦合,其流程是否视为黑盒。一般来讲,数据中台、运维中台都不会触及我们的上层的业务;而能力中台,其内部实现的流程和我们业务解耦,是我们业务调度或者业务编排的一个单位,也就是说在开发的过程中,我们不需要调整该功能的内部流程,增加新的参数或者特性,中台应能覆盖我们的需求,无需个性化定制,并在性能上提供足够的支持。

二、有没有成为中台的共享基础设施。

和大厂有自己的数据中心不同,小公司的基础设施通常不是自建的,可以是在某某公有云,某某IDC机房,客户自有机房,即使在在同一个某某云上,可能是公司自己租的,也可能是客户指定的,可能是在深圳节点,也可能是在上海节点。如果多个项目的生产环境无法在同一个基础设施上,就存在两个问题:一是网络联通问题;二是网络性能问题。

我们要考虑在生产环境的实际部署中,业务节点和中台节点的网络是否能满足需求。

三、建设中台能不能节省成本。

中台的一个重要目的是节省成本,集中力量办大事。将共性的抽离出来,作为平台实现,不用每个项目组开发,另外将分散到各个项目组从事相似工作的开发人员集中起来,可以构建一个功能更为完善,性能更为强大的平台。

但请不要忘记,中台本身是有成本的,而且成本还不小,需要有专门的中台团队来进行开发和维护,存在跨团队合作(如,想中台团队提需求)的沟通和时效成本。最终能否节省成本,在于边际效益,接入的项目越多,中台成本摊分越薄。所以,中台适合大厂,对于小公司,先算一算帐,到底是增加成本还是节省成本。

选择和演进

前面讲到中台是有成本的,需要单独的运维。就开发而言,项目内部一个边界清晰的模块,要独立出来成为一个平台,成为一个多个项目共同使用的内部产品,也不是那么容易。最大的就是模块和产品的差异:

  1. 作为一个模块用于某个项目,相当于单租户;作为产品用于多个项目,就是多租户了,就要有租户的配置、管理、授权,不同的统计视图,独立的运维系统,这些在单项目内都无需考虑。
  2. 原来的一些控制功能,如限流,是由项目统一实现,例如在第三方接入网关中实现,模块本身可以不考虑,但是作为平台产品,这类的控制功能就必须要有。
  3. 作为平台,服务的量级不同,量变引发质变,很可能会引发实现的架构的不同,需要进行重构。

中台并不是解决重复造轮子的唯一方法。

最简单的就是代码复用。以java为例,就是封装为jar包,提供其他项目组使用。我们在自己的项目中也会复用到很多开源项目的代码,例如json的解析,如此细小的功能,有时会让我们忽略掉,其实这也是个开源项目。

人员复用也是一种变相的代码复用。对于某方面资深程序员,专职从事某特定领域的开发,被不同的项目组共享。他可以根据各项目不同的需求,快速地定制地开发出各项目的所需。

进一步,可以采用第三方接入的方式。对于一个服务提供方来说,除了推广自己的应用外,还可以把服务以 API 方式开放出来,让更多的应用接入自己的服务。也就是某个项目开发出来的业务或功能,如果其他项目组所需,是可以采用第三方接入的方式,通过Restful API接口来接入该服务,相关授权方式比较流行的是OAuth2.0。

如果项目的某业务或功能集有越来越多的内部第三方接入,并慢慢地以此为主要的请求来源,就可以开始考虑中台化。这是逐步演变,水到渠成的过程。对内服务,我们称之为中台,对外服务,我们称之为云能力。很多时候,内和外的界限是模糊,有内有外,反正就一称呼,不要太纠结。

天花乱坠:数据聚合

在各类的中台中,数据中台比较特殊,我总有种以中台之名实施数据霸权的感觉。

“中”就是在“前”和“后”之间。一般来讲,输入是项目A,输出也是项目A;输入是项目B,则输出为项目B,项目A和项目B的数据是隔离的。然而,数据中台实现的是数据汇聚,从不同的项目中获取数据来源,将这些数据综合起来,一起进行数据分析,在更宏大的视角中得到更精确的图谱。

数据为王,数据中台在大型互联网公司中具有很高的价值。很多时候,已经不是“前”和“后”的中间,仅仅将项目作为一个数据源。

一旦将各方的数据汇聚,想象的空间就大了,至于多大,看心有多大,可以天女散花,可以天花乱坠。

©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值