什么是中台?

什么是中台?

没有XX台的时代 - 烟囱式的架构

在传统IT企业,项目的架构是什么样的呢?无论项目内部的如何复杂,都可简化分为前台后台两部分,也就是垂直的烟囱式架构(业内人士把见招拆招、垂直化发展、未做足够抽象通用的架构称之为烟囱型架构)。什么是前台?所谓前台即包括各种和消费者用户直接交互的界面业务功能,比如web页面(PC端),手机app(无线端或移动端)。什么是后台?后台是面向运营人员的配置管理系统,比如商品管理、物流管理、结算管理。后台为前台提供业务管理等。前台、后台、用户之间的关系,可以用下图简单表示:

起初,项目的发展相对稳定,并不需要快速的去迭代,所以垂直的烟囱式结构并没有什么问题。但在互联网快速发展的今天,企业之间的竞争越来越激烈,只有以用户为中心,快速响应用户的需求,不断迭代和试错,才能让企业在竞争当中立于不败。在传统的前台-后台架构中,各个项目相对独立,许多项目都在重复发明同样的轮子(比如用户中心,支付业务等),即让项目本身越来越臃肿,也让开发效率越来越低。这种时候,为提高开发效率,我们有必要整合出一个中间组织,为所有的项目提供一些公共资源。而这个中间组织,就是人们所说的平台。

垂直烟囱的进化 - 平台化的架构

为什么会出现平台化架构,还得从烟囱型架构说起(参考上一节)。但烟囱型架构并非一无是处,在早期业务死活未知的情况下,不过度设计架构,能直接有效的支持到业务。不过,当业务发展起来之后,烟囱越树越多,成长的烦恼就如期而至了。

第一个问题是人不够,业务响应慢了下来。我们以一个5人研发团队为例来说明一下这个问题。起初团队一个产品都没有,5个人1个月干出一个简单版本的红包系统;几年之后团队增加到10人,但手头要维护10个系统。那么平均人手一个系统,这时候,又来了2个新业务,团队派出3个人去干,大约要干4个月,严重不符合前端业务的响应预期。

第二个问题是重复建设,同类烟囱系统中80%的功能是类似的,从数据库模型到主要业务逻辑,都是copy-paste加补丁,一步留神又踩到一个坑。

第三个问题是维护成本高。日常升级包、咨询支持服务,团队疲惫不堪。基于此,80%甚至90%的共性问题,能不能抽象出来呢?核心领域模型是否可以是稳定的呢?从下图可以看出,这是可以做到的。

​ 在既要支持不断出现的各种业务,又要支持建设新平台。企业便启动了平台化建设,对前后台业务提供统一的能力露出,由能力组装编排内部服务。研发规则运营、统一后台管理服务等。

总结下来,平台化架构有以下好处:一是快速支撑、响应业务;二是抽象共性,边界清晰。快速支撑,响应业务是以终为始的出发点。架构如果不服务业务,再高大上都是扯淡。技术不是炫技,要服务商业。再谈谈抽象共性的问题,业务平台化要解决业务共性问题,比如天猫、淘宝都有各类营销活动。那么就抽象出一个营销平台来管理营销活动、营销工具的整个的生命周期管理。

中台的架构思想 - 大中台小前台

中台的起源

SuperCell

SuperCell 是一家芬兰的手机游戏公司,这个名字或许有些陌生,但是说起下面几款游戏,大家一定会很熟悉:部落冲突、海岛奇兵、皇室战争等。SuperCell 公司就像是一个高产的游戏孵化器,在几年内开发出了10款以上的游戏,但是大部分用于试错的游戏都在研发过程中被腰斩了,最终呈献给用户的几款游戏都是经典中的经典。是什么让 SuperCell 公司能够如此高效地试错和迭代呢?他们依靠的是强大的平台资源,支撑起各个游戏开发的小团队。他们开发出的游戏看上去风格迥异,却存在许多共同之处。在业务上,共通的东西包括支付系统、用户系统等等,在技术上,共同的东西包括游戏引擎,内部开发工具等等。而这些共通的资源,都可以由一个强大的“中台”来提供。Supercell 的中台,指的是公司将游戏开发过程中公共和通用的游戏素材和算法整合起来,并积累了非常科学的研发工具和框架体系,构建了一个功能非常强大的中台。这样强大的中台可以支持若干个小团队在短时间内开发出一款新的游戏。

阿里巴巴

马云在2015年的一次欧洲之旅(访问SuperCell公司),将中台的思想结合阿里的现状,提出了大中台、小前台的战略架构,从而将中台架构思想引入国内,开启了中台化热潮。

中台的定义

中台是什么?简言之,中台是给业务团队提效为目标的,可复用的技术能力及业务能力的集合。有业务能力说明理解业务,能复用说明能提效。从这个定义可以看出,中台更接近是一个解决方案。

中台的分类

中台 是 可复用的技术能力和业务能力的集合;与此相对应的,中间件、技术框架、技术平台 是 可复用的技术能力的集合;中台和中间件的共同点就是他们都需要被复用才能发挥价值,并不能出去单打独斗。

​以此类推:业务中台就是可复用的业务技术能力和组织业务能力的集合;数据中台就是可复用的数据技术能力和数据业务能力的集合;算法中台就是可复用的算法技术能力和算法业务能力的集合;

​但是,技术中台这种说法有点迷,会让人误解里面都是技术复用,而没有任何业务。如果其实是纯粹的技术复用平台,建议大家在平常交流时还是尽量别用技术中台,直接用中间件、技术平台、技术框架的原有概念来沟通即可,没必要赶时髦。

中台的用户

  • 电商交易系统,前台的用户是消费者,后台的用户是电商运营,中台的用户是谁?

  • 企业管理系统,前台的用户是员工,后台的用户是企业管理员,中台的用户是谁?

  • 数字政务系统,前台的用户是公务员,后台的用户是政府管理员,中台的用户是谁?

大中台,小前台。 这种说法的误导性在于,让人以为中台是为前台服务的。但其实中台可以服务任何业务形态。从 Supercell 这个故事可以看出,中台不会直面消费者或最终用户。中台的作用就是为业务团队服务,让业务团队更好更快的服务最终用户。

中台是必须?

从0到1的阶段

没有必要搭建中台。从0到1的创业型公司,首要目的是生存下去,以最快的速度打造出产品,证明自身的市场价值。这个时候,让项目野蛮生长才是最好的选择。如果不慌不忙地先去搭建中台,恐怕中台还没搭建好,公司早就饿死了。

从1到N的阶段

​适合搭建中台。当企业有了一定规模,产品得到了市场的认可,这时候公司的首要目的不再是活下去,而是活的更好。这个时候,趁着项目复杂度还不是特别高,可以考虑把各项目的通用部分下沉,组建中台,以方便后续新项目的尝试和旧项目的迭代。

从N到N+1的阶段

​搭建中台势在必行。当企业已经有了很大的规模,各种产品、服务、部门错综复杂,这时候做架构调整会比较痛苦。但是长痛不如短痛,为了项目的长期发展,还是需要尽早调整架构,实现平台化,以免日后越来越难以维护。

中台的FAQ

中心化/平台化/中台化异同?

中心化->平台化->中台化,更像是随着组织规模增大,分布式系统下一种架构思想的演进。在业务最早期,业务既量小又简单,一个业务系统、单机或几台机器就支持了。随着业务快速发展,团队增多,带来诸多的效率和稳定性问题,系统架构升级,开始系统拆分,正式进入分布式系统阶段,并由此开启了一段新的架构演进,如下图所示:

  • 中心化重在领域建模,通过对自身领域的抽象建模,对外提供统一标准的数据和服务;
  • 平台化重在业务抽象和架构开放,“业务抽象解决共性的80%问题,系统架构开放性解决20%的个性化问题”,既能对外提供标准的数据和服务,还能通过平台配置,或实现指定服务接口,或平台内部实现业务逻辑控制等方式支持不同业务的运行;
  • 中台化重在建立标准和机制,通过建立业务身份、能力、扩展点等业务领域概念标准,能力管控、流程编排等系统运行时标准,使大家能互联互通、共享共建,以统一的标准进行需求分析、技术开发和复用。

总的来说:中心主要负责自身单一领域的建设,而平台要负责对多个业务域的支持,而中台则是要覆盖到所有业务域,建立整个业务域的协同标准和机制。所以中台的技术连通性更强,技术生态性更突出。淘系业务系统的发展正是这个过程,业务上从淘宝时期到三淘(淘宝、天猫、一淘)时期到现在的淘系生态,系统上从商品中心、店铺中心等到商品平台、店铺平台到今天的电商业务中台。

小前台到底多小才算小呢?

小前台只是个代称,并不一定非得是前台团队, 用一个“快速反应团队”代之较为合适。也就是5人、7人、最多十几个人组成的团队,不宜过大(其实是相对“小”,不用刻意追求数量的少)。过大了惯性也会比较大,掉头就比较不容易,不利于快速反应、创新、试错。

如何下手建设中台化架构?

从哪里开始?哪种路径更适合打造一个中台?

  • 直接下手开始做中台,逐步扩展到其他业务
  • 从最擅长的业务(核心业务)入手,做中台的探索

第一种路径的好处是一开始可以做好中台的规划,技术栈保持一致性。坏处是失败的概率和成本比较高。第二种路径更保险,也是目前来看比较可能结出果实的路径。比如:阿里先有电商业务和互联网金融业务,然后才做了共享业务、星环等中台方案。头条最擅长算法业务,然后才有了算法中台。腾讯在IM领域沉淀了多年,基于IM做中台符合逻辑。

中台架构到底在学习什么?

值得我们学习的不是中台本身,而是 Supercell 模式。Supercell 模式如何实现,马老师已经给了一种路径:大中台,小前台。 但也许这不是唯一路径,但至少是种思路。18年到19年,有种功利化、蹭热度化、浮躁化的氛围,弥漫在中台的圈子里。大家一哄而上,咋咋呼呼的大跃进式的建设大中台,逢人必谈中台,周报写中台,开会说中台,晋升提中台,甚至借中台之名,行平台之实。

参考资料

作者

卫恒

发布于

2020-05-19

更新于

2022-04-23

许可协议

评论