中台的价值:

我们从来都反对“大中台,小前台”的架构设计_大数据

毫无疑问,中台能够共享复用,降本增效。

快狗打车的平台架构,中台架构是如何演进的:

1、开始

我们从来都反对“大中台,小前台”的架构设计_平台架构_02

最早,我们的架构就是如此简单。

优势:系统简单,迭代快速。

不足:三方对接耦合在业务中,三方系统稳定性影响快狗业务稳定性,三方系统切换改造成本很高。

2、发展

我们从来都反对“大中台,小前台”的架构设计_大数据_03

3、继续发展

然后,我们做了基础服务的抽象,把与第三方对接的短信、推送等抽象成基础服务。

随着业务的发展,我们遇到的新的问题。

我们从来都反对“大中台,小前台”的架构设计_大数据_04

新业务诞生,烟囱式的系统不断冒出来,数据形成了孤岛,业务之间的流量、产品、系统难以连结,消耗了大量资源去做了重复的事情。

画外音:很多公司,一般打着“闭环”“高效”的名义,推进烟囱式产品/系统/架构,其实是不作为。

4、再发展

这个时候,类似于XX中心的业务服务诞生了

我们从来都反对“大中台,小前台”的架构设计_用户中心_05

如上图所示,除了各个业务公用的,业务无关的基础服务,业务相关的用户中心,订单中心,交易中心,营销中心服务,应运而生。

此时,这类共享服务中心,增加了业务属性。

我们从来都反对“大中台,小前台”的架构设计_大数据_06

这些服务,应该归业务研发部门,还是基础服务研发部门呢?

都不是。

5、最后

此时,业务中台诞生了。

我们从来都反对“大中台,小前台”的架构设计_平台架构_07

中台,是共性业务的部分。

问题:中台,应该做厚还是做薄?

我们从来都反对“大中台,小前台”的架构设计_大数据_08

最早,阿里提出了“大中台,小前台”的中台战略。

对此,快狗打车有不同的看法,中台太厚,势必夹杂个性化业务逻辑,不要让中台成为业务发展的瓶颈,我们提倡“小中台,大前台”,只有足够通用的业务,才适合下沉到中台。