应用架构一般演进的规律是，从中心应用演进成平台应用，然后从平台应用演进成中台应用，演进背后的底层逻辑就是"降本增效"，降本增效在软件架构中经常被提到，本是成本的意思，效是效率的意思，连起来就是降低成本提升效率，仅仅回答到这一层，还是有些抽象，这里"本"包含了哪些成本？"效"又包含了哪些效率？

软件开发的成本包含了：分析成本、沟通成本、研发成本、部署成本、维护成本……；效率包含了：沟通效率、研发效率、运维效率……。"降本增效"是应用架构演进的重要推动力，在中心式阶段，每个业务都有自己的系统，这种烟囱式开发最大的好处就是业务、研发高度自治，沟通成本很低，所有的决策不用考虑外部依赖，它最大的弊端就是重复建设，数据不通。如在国际化场景下，Lazada有店铺，AE有店铺，在最开始是各自己建设自己的店铺应用，两者之间是隔离的。正因为中心式应用有这样的问题，演进到平台式阶段，平台式应用避免了相似功能重复建设的问题，将共性的功能下沉，底层数据模型是统一的，平台式应用以功能复用为主，并且一般是在BU内部使用。当应用演进到中台式阶段，在平台的基础之上，更考虑的是产品的复用，并且打通了跨BU间的合作关联，避免跨BU间的协同（沟通成本是非常巨大的），让前台应用有更大的创新空间。

中台按类型分有技术中台、数据中台、算法中台、业务中台，本篇主要探讨的是业务中台建设，没有做过中台系统建设的同学，好比看围城一样，城外的人觉得中台建设什么都能做，城里的人觉得城外人的真能想，中台建设是非常有挑战的，也是非常难的，尤其是业务型的中台建设。

业务型中台建设第一个挑战点就是组织建设，如果业务在组织上是分隔的，想去做中台是非常困难的，例如如果AE店铺和Lazada不是在同一个组织下面，想去做国际化店铺中台谈何容易，做了中台，相当于革了对方的命，把对方的业务做没了，你也许会说可以把其余的人去安排做别的更有意义的事，这说起来容易做起来何其难。

另外一个就是我们依赖方，他们没有中台版本的API接口，中台就要抽象出一层防腐层，适配到各个具体的调用方接口上。说到防腐层，也是说起来容易，做起来难，比如搜索接口，AE有一套，Lazada也有一套，两者的调用方式也不一样，处理逻辑也有差异性，店铺中台想要包装也不是那么简单的。最为著名的就是软件界的一个“鸡猪理伦”：鸡找到猪说咱们合作卖鸡蛋火腿肠，结果猪不同意，鸡每天下蛋对鸡没有影响，但每天割猪的肉，猪受不了。所以，如果多个业务在组织上并不在一起，想要去做中台是很难的。

一般中台会提一句口号：让业务先赢，这句话并没有错，但笔者认为这个目标是终极目标，并非是初始目标，如果是初始目标，中台建设出来的效果要么是抽象层次不够，要么是中台能力很薄，发挥的作用有限。比如通过流程归纳出来的业务型中台建设一般是不理想的，新出来一个业务很有可能现有的流程是不满足的，又得在原有的流程中各种改动去兼容新的业务。让业务先跑，又要中台建设又好，本身是矛盾的，让业务先跑，怎么快怎么来；中台要好，是要花时间去设计的，好的东西是花时间去雕琢，太快反而不好。

笔者的一个观点是中台要和业务保持一定的距离，要透过业务去看业务的本质是什么，中台到底要提供哪些能力去支撑业务（不是中台的职责不要去碰），业务的产品化运维还需要中台去做哪些事，中台怎么去让业务接入更高效，中台需要多去思考这些方面的事，而不是和业务去抢活干，结果中台里耦合了太多的业务逻辑。中台与业务之间的距离越低，中台越不灵活。

理想的中台每部分都是独立自治的，业务侧可以灵活地组装出自己的业务逻辑，同时中台给予了业务侧灵活的扩展机制而非仅仅SPI扩展，扩展的部分要能够让业务侧有想象空间，业务侧不能仅仅是遵循中台的规范去做事而缺乏创造性。扩展性也是中台建设的一个挑战点，扩展点太小业务侧没有发挥空间，扩展点太大又太泛。

技术中台、数据中台、算法中台在不同的公司，一建一个成功，归功于它们基本上有统一的建设方法，以数据中台为例，底层有大数据存储、大数据计算体系，在大数据技术体系之上，建立统一的数据体系：事实数据、数据指标、数据维度、聚合数据、数据质量监控等，最上层就是具体的业务。反观业务型中台建设，它并没有统一的建设方法，大部分人是按照自己的经验、理解去建设业务型中台。

正是因为没有统一的业务型中台建设方法，也就没有标准，大家建起来就比较累，每个人都在探索。业务型中台建设除了技术上的复杂度外，还有业务上的复杂度，技术人往往忽略了业务，反而去想技术上要怎么去做，要用哪个框架去解决问题，因此在源头上缺乏定义业务问题的过程，建设出来的业务中台没有神似业务本身，而仅仅是形似业务本身，一旦变了一种场景业务中台就不灵了。

谈论中台，不能仅仅看中台系统本身，以系统的观点结合业务和中台去看，或许有不一样的视野。核心还是系统间的连接是顺畅的，如果业务与中台在很多地方是交叉的，说明拆分得不理想。

将业务与中台看作是一个整体的系统，业务和中台是系统中的子系统，两者有机地结合构成完整的系统。这里面就有两个核心的问题：中台和业务的切分是什么、中台和业务怎样融合构成一个系统。这也即是业务与中台的分合关系，“分”是为了更好的“合”，如果“分”得不好，“合”起来就比较难，或者是最终的系统并不完美。

分合也是架构设计的特性，将系统划分成职责不同的子系统，子系统各司其职，又能相互连通，构成精密复杂的系统。中台不要包含业务逻辑，中台更偏定义领域骨架，围绕领域骨架去完成相应的工作，想想Spring是怎么做的（定义Bean、识别Bean、初始化Bean，没有任何业务逻辑）？想想大数据平台平台如何执行用户自定义任务的（加载任务、调度任务、分配资源、回调业务逻辑、输出结果）？业务特性的部分交由业务侧去实现，中台侧想控制也控制不了。

在分合关系中已经提到，业务与中台的切分即是两者的边界，要回答这个问题并不那么容易，目前一般是根据一些原则去划分业务与中台的边界，比如这个业务功能是不是通用型的，如果是就放在中台。

笔者最喜欢用的方法是思考业务的本质是什么，用一两句话去给业务下一个定义（定义是模型语言版的浓缩，定义中的要素就是组成模型的关键部分），看看定义中包含的要素有哪些，要素内的内容就是在中台里面，要素以外的内容放在业务。比如店铺类目，笔者给它下的定义：店铺类目是卖家为方便买家在店铺有针对性的选购各种各样的商品而对商品做出的归类，那么它包含的要素就有类目结构、类目圈品，至于业务侧要有两级类目结构还是三级类目结构，手动圈品还是自动圈品，店铺类目投放到哪里，创建类目的规则是什么……，这些都是业务侧的内容，中台的职责就是定义好店铺类目的结构和店铺类目的圈品方式和圈品条件。

业务与业务隔离是一个技术问题，技术人对这个话题更感兴趣，隔离有物理上的隔离，也有逻辑上隔离，物理上的隔离就是一个业务只运行在这个特定的物理单元上，绝对不会影响到另外一个业务。逻辑上的隔离在国际化这边用的是多租户隔离，不同的租户加载不同的站点包。

最理想的情况是中台用同一套逻辑去处理不同的业务，但在现实中，每个业务之间是有差异性的，很难用同一套逻辑去处理，中台需要将变化的逻辑分离出去交由业务侧实现。比如通过SPI定义接口，业务侧在站点包中写自己的特有实现逻辑。

在1.2.3节中提到业务型中台没有统一的建议方法，笔者喜欢用类比的方法去看其它类似的系统是怎么建设的，从中汲取一些经验，下面从操作系统和Spring两个案例中学习业务型中台建设的方法。

我们日常看到各种各样的应用，如聊天软件、音频软件、图像软件……，这些软件的作用和功能各不一样，但它们都运行在操作系统之上。操作系统的主要能力包括：进程管理、内存管理、文件管理、IO管理，操作系统基于这些能力去承载不同的应用软件。

我们去思考下，操作系统何尝不像我们的业务型中台一样，不同的业务方好比不同的应用软件，业务型中台好比操作系统。在操作系统之上，有一些系统软件，比如编译器，在安装操作系统之时，默认会安装一些软件，如办工软件Office，浏览器软件Chrome等。操作系统安装好了之后，用户可以在操作系统上安装其它的应用软件来满足自身的需要。

操作系统的核心在于抽象，它本身没有应用的概念，而是从应用加载到内存中，将整个流程抽象出来了，提出了进程、线程、虚拟内存、IO等概念，正是抽象出了这些与应用本身无关的概念，操作系统的能力才无比强大，反而如果操作系统耦合了应用本身的逻辑，那么它就的发展就受限制了。

Spring对于后端开发来讲非常熟悉，我们在日常开发中经常使用到Spring，在Spring的底层有BeanDefinition、BeanDefinitionReader、BeanDefinitionRegsitry、BeanFactory、Bean等核心概念，在Spring的基础之上，又有一些组件，如处理数据连接的Spring-Data、处理批量任务的Spring-Batch、处理安全的Spring-Security……，业务应用只用专注于自己的业务逻辑处理，而不用关心业务Bean是如何实例化的，也可以直接使用组件能力去处理特定场景下的问题，比如批量数据处理就可以使用Spring-Batch提供的能力。

以Spring为例，思考我们日常开发面临的问题，我们使用对象的流程，先定义类，然后实例化对象，最后是使用对象。定义类和使用对象我们是要感知的，在没有Spring之前，我们还要感知对象实例化的过程，比如维护对象之间的依赖关系，这些工作就比较繁琐。Spring就能发现这个问题，通过自动化的方式去解放开发的工作量。

当确定了问题域之后，就要对问题域进行抽象，到底以怎样的概念去描述问题域中的关键要素最为关键。Spring的核心是定义Bean、加载Bean、实例化Bean，只要使用特定的Bean注解（还可以XML定义Bean），Spring就能托管Bean，在实例化之后进行属性依赖注入和初始化工作，整个过程开发完全不用感知，在使用Bean对象时从Spring容器中获取即可。

还是以上面的Spring为例，它根本没有沾上任何业务逻辑，只做了Bean的定义、Bean的识别、Bean的实例化工作，这看似没多少工作量，但Spring能够把它做到极致非常不容易。比如Bean的识别上，除了Spring定义的标准注解之外，如果业务方有自己的注解怎么加载？Bean实例化过程的分解，从更小的粒度去看Bean的实例化过程……，这里面包含的内容非常多。在Spring的基础之上，后面又有一些组件，如Spring-Data、Spring-Batch等，将日常开发中经常使用到的能力封装成一个个独立的组件供开发使用。

业务型中台也要像Spring一样，不要把手伸得太长，不要担心中台是不是太薄了，反而应该专注于中台能力的建设上、如何快速支持业务接入等问题上，站在业务使用方的角度去看，当前还有哪些痛点问题，如何让业务研发更好地使用业务中台的能力。

笔者中台建设思路是借鉴了操作系统和Spring的一些思想，业务型中台要源于业务，又要高于业务。业务型中台一定要经过深层次地抽象去还原业务本身，从业务的本质出发去推导中台能力最小集。比如在借贷系统中，最为核心的是标的（借款信息）、理财（投资信息）、债权关系（借贷关系），这三个抽象就把整个借贷系统的核心本质抽象出来了。然后就可以推导出能力的最小集，能力最小集就是整个中台系统最为关键、最为核心的能力，脱离了这些能力业务是玩不转的。

中台能力最小集像一个骨架一样，能勾画出一个业务的最核心的能力是什么。比如国际化店铺中台，它最为核心的是店铺装修和店铺浏览，脱离了这两个核心能力，其它的业务也就开展不了。当有了店铺之后，可以考虑是不是可以举办一个营销活动，让卖家关注领取优惠券。

判断是不是中台最小能力集一个标准是：如果没有这个能力，正常业务受不受影响？如果受影响就是属于能力最小集范围内，这也是做什么、不做什么的判断标准之一。

当中台能力最小集确定之后，它可能还不是以产品化交付的，业务侧接入的工作量可能还是非常大，如何去解决这个问题呢？中台还要提供组件化的能力，像Spring-Data、Spring-Batch一样，如店铺中台有商品查询的能力，AE有一套商品查询，Lazada也有一套商品查询，店铺中台抽象出商品查询的组件能力，在底层适配到Lazada和AE的商品查询接口之上，业务侧想使用时就引入对应的POM依赖即可。

组件化的能力是一种可插拔的能力，类似于搭建积木一样，中台提供了很多这样的能力集供业务侧选择使用，业务侧也可以自行开发，本质来讲是为了提升业务侧的研发效率。比如店铺活动，抽象出来有活动、权益、履约、优惠等要素，中台封装了这些组件化的能力，业务侧不管是店铺签到，还是关注领券，都可以复用这些组件化的能力，减少去对接第三方能力的时间。

组件化能力是丰富业务中台的生态，可能一开始组件并不太多，随着业务的发展，中台包含的组件能力越来越多、越来越丰富，当中台能力最小集建设完成之后，结合业务的发展和痛点，提前一步布局，让业务研发的体感很好，因此也就没有中台建设着建设着就没了的顾虑。

业务型中台的应用架构模式笔者认为洋葱架构模式比较适合，最里层是领域实体和领域服务，外层有适配的端口，如数据库可以有不同的实现，Mysql、SQLite，这与上面提到的商品查询是一样的，可以适配到不同的具体实现上。洋葱架构模式的思路和笔者前面提的很相似，关键是确定最为核心的能力最小集（领域模型、领域服务），在外层可以增加不同的组件能力去丰富中台能力。

业务型中台建设更重要的是对业务的抽象，抽象出来的模型能高度还原业务本身就是成功的，业务研发上手也会更快，接入效率也高。因此，业务型中台建设的关键是在于核心领域对象的抽象，这也是中台与业务分离的重要输入，从目前的经验来看，以功能、流程建设的业务中台系统只是形似业务，以领域驱动设计的业务中台系统是神似业务。

可扩展性的本质是占位符，明确标志这里有变化，至于具体的变化是什么，它并不关心。可扩展性在中台建设中非常重要，如果可扩展性设计得不好，业务研发就非常痛苦，要以对象的视角去看扩展而非流程的视角，笔者非常喜欢Spring的扩展机制，BeanFactoryPostProcessor处理BeanDefinintion的相关的扩展，BeanPostProcessor处理Bean初始化的扩展。可扩展性核心的职责是将业务与中台要合成一个有机的整体，常见的可扩展技术手段有：配置化、SPI、流程编排。

配置化是最简单的、最直接的解决可扩展性的方案，中台要有一个运营管理后台，它集中管理了各种配置，比如店铺在初始化过程中，每个业务初始化的页面类型是不一样的，如Lazada有首页、自定义页、新品页、产品页，HK只有首页、产品页，这种差异化的场景就非常适合通过配置化来解决。

配置化常用的场景是规格化的配置，就像我们购买云机器一样，要买多少核、多少内存的云服务器，将这些规格信息通过配置化存储起来，在使用的时候读取配置化信息并完成相应的操作。不要小瞧了配置化的作用，它实质也是对业务领域的高度抽象，比如像上面的云服务器一样，怎么去和用户讲清楚，规格信息是领域实体的关键属性。

有一些场景比较复杂，使用配置化还不能解决，还需要通过代码来完成，比如店铺类目创建的规则，不同的类目方是不一样的，通过配置化是解决不了，业务方要编写创建类目的检查逻辑，中台定义创建类目检查SPI接口，各个业务方在站点包中实现各自的逻辑即可。

SPI需要注意的一点是扩展接口的粒度，太小太大都不好，有些中台的扩展接口太多，这对于接入方来而言并不友好，开始接入的时候要花很多时间去了解，接入成本比较高。

有一类场景就是各个业务方的实现流程是不一样的，比如业务A要经过6个步骤去完成业务逻辑，而业务B要经过4个步骤去完成业务逻辑，每个步骤的差异性还比较大，此时使用配置化和SPI都不适合，流程编排的作用就发挥出来了，流程编排有点像搭积木一样，将各个分散的逻辑整合在一起。使用流程编排的复杂度是比较高的，建议一般不是特别复杂的场景下不要使用流程编排。

所有的扩展实现机制都是要依赖第三方去实现，比如流程编排有一个流程编排的配置文件，SPI有一个SPI接口，配置化有一个配置变量……。

店铺的本质是一个"场"，连接了卖家和买家，促进导购链路上的转化。卖家装饰店铺这个"场"地，让自己的商品、卖点等信息在这个"场"地上进行展示，吸引买家购买。店铺的核心是怎么装修好这个"场"地，吸引更多的买家成为粉丝，从而成为潜在的购买客户。

店铺中台有四类角色在里面：买家、卖家、ISV、业务研发。这四类角色，他们的诉求是不一样的。

从店铺业务的本质和四类角色的关注点，店铺中台的能力最小集需要包含如下能力：

当有了店铺中台的能力最小集之后，中台还可以提供一些组件化的能力，比如卖家需要创建一个活动给卖家发放优惠券，或者店铺签到给卖家发放一些权益……，店铺中台可以像Spring一样提供一些组件化的能力，业务方需要就引入对应的组件能力即可，而不需要自己重新开发，例如，优惠券能力，中台底层是对接了Lazada、AE的能力，不需要业务方重新去接入。

中台需要去了解业务侧最想要什么，痛点是什么，然后思考去怎么解决，这也是让业务快跑的一种体现。

目前店铺中台可扩展机制使用了配置化和SPI，接下来还要做店铺中台的运营系统，让业务方接入效率更快。这里举一个例子，比如店铺浏览时，有底部导航和顶部导航，之前做到的是店铺中台抽象出了导航和tab的模型关系，业务侧可以自己注册tab，这的确是解耦了中台与业务的工作。如果新来一个业务还要在站点包里写各个tab注册的逻辑，虽然工作量不大，但也有改进的空间，比如通过配置化，在新建站之前，配置好需要tab的具体的信息，在系统运行时，从配置化信息中读取tab信息，并完成tab实例化，可以不需要业务研发参与。业务型中台要让业务方少做事，将时间花在更多业务策略的实现上，比如如何提升店铺转化率；中台要做的事给业务研发一个稳定、开放的环境，高效地完成业务需求开放。

理想中的中台，还是立足中台本身去做一些工作，中台的核心还是要让业务研发的效率更快、接入效率更高、研发的感受更好，因此图中分成了5部分：站点包、组件、内核、运营系统、度量系统，它们在逻辑上构成了店铺的全景图。

通过操作系统和Spring的设计思想去思考业务型中台建设的思路，通过中台能力最小集+组件化的思路去构建业务型中台，中台能力最小集是核心，它是中台最基础、最核心的能力，脱离了它业务就玩转不了；通过组件化封装常用能力，业务侧可以选择使用，提升业务侧的研发效率。欢迎大家一起探讨、交流。