从烟筒式重复建设到中台化赋能前台的历程

推荐先阅读本篇的引导篇【中台化导论-程序的扩展性】。

烟筒式独立开发

互联网初期更重视流量和上线速度，在初期一般会使用烟筒式开发，不同业务独立开发：

 

业务条线一和业务条线二分别开发自己的系统，各自有独立的研发团队，优点互不影响，可以快速响应需求；缺点是会出现很多相似或充足的的逻辑代码（比如示例图中的逻辑1）。

伴随业务的逐渐成熟和行业沉淀，业务条线一和业务条线二的公共逻辑越来越多；伴随公司不断开拓新的市场，不断出现新的业务条线（业务三，四。。。），新的业务条线要从头做起，无法复用业务一和业务二积累的技术积累。

组件化重用

最简单的思路就是把公共逻辑做成通用的组件，用于支持不同的业务，如下：

我们把业务不同业务条线的公共逻辑做成公共组件来支持不同的业务条线，新出现业务可以重用之前的组件；如果针对同一个逻辑有不同的组件呢？我们可以抽象出接口，支持多种实现：(此处我们为公共包重新命名为中台,每个业务条线称为前台)

 

如上图，我们可以针对逻辑A开发多个实现组件供业务前台适用；那如果我们要分模块开发，可以把前台依赖的可以扩展开发的接口统一放在一个包，称为SDK（Software Development Kit），可以扩展开发的接口称为SPI(服务开发接口)，模块关系如下：

SPI二次开发

如上图：前台业务一和前台业务二可以使用逻辑一公共实现A1或A2组件，也可以自定义组件实现自己的个性逻辑。

前台与中台的定义与常见歧义

这里的前台不是指页面前台，前台指的是不同的业务条线，中台指的是不同业务条线的公共业务，这个概念来自与阿里，拿阿里来说，天猫和淘宝是两个前台部门，天猫与淘宝公共的电商逻辑就是中台部门;

中台重沉淀，前台站在中台的沉淀基础上，快速响应业务。