中台

中台的核心本质就是:业务为本、网络连接、数据智能,因此我们常说的中台架构可分为业务中台与数据中台,数据中台更多地偏向于中立、统一的数据治理与共享,而本篇专注于业务中台的理念与设计原则。

中台也是典型的认知折叠,提升后端的复杂性以降低前端的复杂性。中台源于平台,对其定义也是见仁见智。从笔者的角度来看,中台提供可被集成的能力,不直接构建面向终端用户的应用;平台也是能够允许第三方集成进来,或者直接面向终端用户提供服务。

业务中台,是为了提炼各个业务条线的共性需求,并将这些打造成组件化的资源包,然后以接口的形式提供给前台各业务部门使用,可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷,最大限度地减少重复造轮子的 KPI 项目。中台不同于平台,不是最终用户能直接使用的,它必须被集成到各个业务场景中。前台要做什么业务,需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发,而是在底层不变动的情况下,在更丰富灵活的大中台基础上获取支持,让小前台更加灵活敏捷。

中台源起

美军的特种部队加航空母舰的策略:10 人以内的一支特种部队在战斗的最前沿侦查,独立决策,一旦发现目标,迅速呼叫强大的中台航母群对其进行毁灭性打击。

芬兰著名的游戏公司 SuperCell,开发了部落冲突、皇室战争等现象级的手游。整个公司才 200 多号人,就被腾讯以 86 亿美金收购。在 SuperCell 里,一个游戏开发团队平均是 3-7 个人,但有一个强大的游戏中台在做支撑,可以并行开发 50 款游戏,然后通过“内部赛马”产生出一到两款经典。据说马云在带领阿里众多高官参观了 SuperCell 后,回来就在阿里整个集团层面启动了大中台战略。

从汽油车到电动车的转变,汽油车是每台车会内置一个内燃机,而电动车则将分散的内燃机收归到一个大的发电厂,从而降低前端的复杂度。这样发电厂自身的升级改造,譬如从火电到核电或其他更高效清洁的能源,就无须将复杂性透出给终端用户了。

中台与云

PaaS 提供了一种服务,客户的程序员通过二次开发使用 PaaS 服务,最终完成某个功能给最终用户。PaaS 的通用性需要非常强,这样才能获得足够大的市场,比如 IM、视频云服务等,也因此 PaaS 往往是没有界面的。SaaS 提供的服务不需要客户进行开发,只需要开通服务,在管理后台上配置一下就可以直接使用。但 SaaS 服务往往针对的是一个细分领域,其定制化能力也相对弱很多。即使是像钉钉,钉钉选择 IM 这种企业中最通用化的服务,同时做成企业服务的开放生态,目标客户也主要是覆盖中小企业。定制化需求强的大客户,也往往会需要希望借助 IM PaaS 服务来自主研发内部 IM 工具。

PaaS 和 SaaS 定位在服务外部客户,必须具备很低的使用成本。即使是需要通过技术来接入的 PaaS 服务,接入成本也一定要足够低,接口清晰,文档完善。中台首先是定位在服务公司内部客户,由于这个范围的限定,导致 中台的通用性可以在很多约束条件下来实现,可服务的领域比 SaaS 广。比如即使同样是电商,淘宝、天猫、聚划算、闲鱼、飞猪的站点都是不一样的,而阿里共享事业部就在中台层服务多个业务。此外,由于中台的用户是公司内部的程序员,大家有相似的背景,也可以频繁沟通,所以服务接入的成本可以做得比面向外部客户的 PaaS 要高。

中台的缺陷

难以应对 Cross cutting concern

根据中台进行系统拆分和部门调整之后,还是会遇到 cross cutting concern,什么是 cross cutting concern:

The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.

有些需求难以避免地会影响整个流程中的所有系统:比如从技术范畴进行的一些改造(如为了完成 tracing,所有系统增加 trace id,并在 log 中默认携带),比如从业务范畴进行的 i18n 改造。这些改造需求一般天生就是跨系统、跨组、跨部门的,事情一带上“跨”的字眼,就不好搞了。举一个典型的例子,某巨型互联网公司员工抱怨,在当前的微服务和中台架构前提下,做一个需求经常要改 20+ 个模块,苦不堪言,连上线顺序都不一定搞得清楚。当这 20+ 个模块又是跨部门的时候,就更难了。想要推动其它部门做一些短期看起来没啥收益的事,太难了。

稳定性和灵活性的矛盾

对于一个系统来说,追求稳定性,那么必然会在修改和升级上较为消极;追求灵活性,那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一,在一定程度上就得放弃另一方面。有很多中台系统被剥离之后,因为用户众多,一旦出现技术上的问题,影响面巨大。

中台与前台的模糊业务边界、距离

在实际实践时,中台与 FT 的边界往往划得不清不楚。比如用户服务、用户权益、用户在各种子系统中的状态,这些内容可能并不是用户服务本身关心的内容。但往往需求也会提给用户服务,这时候用户服务就只是进行字段存储,而状态机变化则完全在外部。

如果对系统内的个别数据不进行管理,那么有其它接入方接入时,就无法解释清楚字段的含义和使用场景。如果不接受这些不相干的数据接入,那么前台流程系统可能会在自己内部重新建立自己的数据系统,这部分系统又极有可能和中台有功能上的重叠。

如果想要把这些数据接管过来,那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部,这往往又会产生与中台与前台业务边界的冲突。