我们从来都反对“大中台，小前台”的架构设计

中台的价值：

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

快狗打车的平台架构，中台架构是如何演进的：

1、开始

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

优势：系统简单，迭代快速。

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

2、发展

3、继续发展

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

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

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

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

4、再发展

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

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

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

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

都不是。

5、最后

此时，业务中台诞生了。

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

问题：中台，应该做厚还是做薄？

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

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