中台是近两年软件开发领域的热点话题，相关的文章也成为了各个技术社区和媒体争相报道的网红内容。作为企业支撑业务开发的核心系统，中台的重要性不言而喻，很多企业也开始尝试中台的构建和落地工作。Biz-UI 的业务中台孵化于 BSAP（Business Service Architecture and Practice）项目，经过一年多的积累，终于开花结果。本文将从中台的基本概念讲起，带你一起探寻 Biz-UI 团队的业务中台构建之旅。

2015 年阿里制定了“大中台，小前台”的战略方向，中台一词由此诞生。作为一个国人创造的词汇，中台没有一个原生的英语词汇来表示，我个人更倾向于使用“middle-end”或者“middle-platform”来表示。但可以确定，中台是介于前台和后台之间的产物。所以在理解中台概念之前，我们先来看一下它和前后台的区别。

我们先来为前台和后台做一个宏观的定义。

前台： 企业交付给终端用户（客户）所使用的系统，是企业与客户进行交互的平台，例如用户直接访问的网站、App 等都可以算做前台。对于 FreeWheel MRM 核心业务系统来说，前台就是提供给客户使用的前端页面，以及为页面提供业务逻辑支撑的微服务系统，也就是我们内部所说的 Domain services。

后台： 管理企业核心信息资源（数据）的后端系统、计算平台、基础设施。后台不会和终端用户直接交互，不（也不应该）具备业务属性。对于 FreeWheelMRM 核心业务系统来说 ，搜索平台，数据访问层，基础设施都属于后台的范畴。

稳定、可靠是后台所追求的目标。而前台因为和客户交互的原因，需要快速响应客户频繁的需求变化。因此，前后台之间在目标诉求、响应速度等方面具有不可调和的矛盾。它们就像一大一小两个齿轮，因为齿比密度的不同，难以平滑的协调运转。

在软件开发领域流传着这样一句话：“软件设计与开发过程中出现的任何问题，都可以通过增加一层来解决”。在这里我们不去探讨它的对错和适用范围，但可以确定的是，中台的出现，就是为了解决前后台运转效率不同的矛盾，通过中台这个变速齿轮衔接前台和后台，消除两者在效率上的差异性，以此达到系统整体的平衡。

很多人难免混淆中台与平台的概念。我们拿 Supercell 公司举例，阿里的中台战略缘起于对 Supercell 公司的参观访问，他们惊叹于如此小规模的团队却能够快速的开发和复制出成功的产品。而背后功臣，就是 Supercell 所拥有的具有业务复用能力的系统，比如玩家系统、技能系统、装备系统、道具系统等等。这些业务系统可以让其快速的复制出新的产品，而无需重复开发相似业务。Supercell 的这些系统，都是真正的业务系统。

那么，Supercell 拥有的是中台还是平台？让我们来定义一下它们之间的区别：中台是支持多个前台业务且具备业务属性的可复用系统；而平台是支持多个前台但不具备业务属性的系统。业务相关性和业务无关性，是衡量中台与平台的唯一标准。因此，要区分中台和平台，只需要基于一点去考虑，就是判断它们是否具有业务属性。

我们常常会听到各种各样的中台：业务中台、数据中台、技术中台等等。在中台分类这一点上，我非常认同网易副总裁汪源的理念：“所有的中台都是业务中台”。从广义上讲，所谓某某中台，都是为业务服务的，是为了企业可以以更低的成本、更高的效率，快速响应业务需求并推出新产品。比如所谓数据中台，就是对业务数据进行二次加工，并将输出结果再次服务于业务。本质上讲，数据就是业务的载体。而所谓技术中台，其实是将基础设施、中间件的能力进行整合与封装，提供统一的可重用接口。从这一点来说，它仅仅是一个中间件平台。

中台需要具有实现业务系统所必需的业务元素，并封装了问题域（业务领域）的通用解决方案，这也是本文所主张的业务中台的核心描述。

中台是业务抽象层面的复用平台，其核心是将具有共性的业务抽象出来，并提供复用。复用定义了中台的核心价值，具备可复用性才能达成降本提效的目的，为企业带来效益。中台的搭建也不仅仅是个技术问题，还应该跳出单一的业务线，从企业架构的层面上去考虑，站在企业的视角来审视业务全貌。

另一方面，我们也可以认为中台是产品的平台化产物。通过将产品中具有共性的业务下沉，形成一个可复用的平台；反过来理解也可以，即平台产品化：为平台植入业务属性，使其具有部分产品的特性，为构建具体产品提供必要的业务元素。

当然，每个人对中台的理解不尽相同，我们也无需强加一个统一的定义。理解中台的本质，并通过它降低开发成本、提升开发效率，为企业产品赋能，这才是构建中台的关键点。

从定义可以看出，中台的存在会改变业务的开发与交付方式，并以一种更高效的方法来响应业务需求。构建中台背后的诉求，其实是希望对多业务进行支持，快速响应前台的变化和创新，并构建新的业务和产品线。中台是平台发展到一定阶段的产物，当我们的业务扩展和变化速度超过了平台的服务能力后，需要将一部分具有共性的业务抽象出来并下沉到平台，以便可以快速的支持新的业务开发。因此，中台也可以理解为是平台向业务进化的产物。

作为 MRM 核心业务系统的开发团队，迁移到微服务架构后痛点也逐渐显露出来。在服务链路的梳理和重构过程中，我们发现有很多业务逻辑是具有共性的，应该被抽象出来。同时，随着公司业务线的扩展，Marketplace 这样的新产品也需要搭建一系列新的服务。如何高效的构建新服务，并复用现有的业务逻辑成为了团队急需解决的问题。因此，搭建业务中台，成为了我们解决开发效率方面的首要任务。

任何系统的构建过程都不是一蹴而就的，业务中台更是如此。前路漫漫，上下求索，通过不断的打磨、试错、重构，经过一年多的开发，适用于 Biz-UI 团队的业务中台概念愈加清晰，功能模块也逐渐完善和系统化。开发过程可以划分为 3 个阶段。

2017 年我们将业务系统从单体结构重建为微服务架构时，是通过自底向上的方式，基于业务能力进行服务的划分。这种方式最大的优势就是能够快速的完成构建和开发过程，尽早完成迁移。但其劣势也很明显：没有统一的规划和设计，整个系统缺乏通用的框架和服务治理能力。为解决这一问题，我们提出了 BSAP（Business Service Architecture and Practice）项目，旨在改进和优化现有的微服务架构，为各个业务线提供可复用的服务治理能力，同时提供一整套的公共库和中间件，以提高微服务的开发效率。业务中台就孵化于此。

和阿里这种先制定中台战略，再统一开发的方式不同，项目初期我们并没有想要刻意的构建一个业务中台。初衷很简单，就是想把相似的业务逻辑以组件或类库的方式抽象出来，以便达到复用的目的。随着具有业务共性的中间件和类库越来越多，我们意识到在本质上，我们所构建的这些组件的集合正是所谓的业务中台。

从投资结构的角度来讲，我们的中台团队是通过“众筹模式”组建起来的，参与项目的都是各个业务线的核心开发人员，他们描述自己业务的需求和痛点，并提出解决方案，在 BSAP 会议上通过分析、讨论，如果认为是有价值的议题就会正式进入开发阶段。而开发团队就是需求的提出者，当然他可以招募一些帮手，其他有共同诉求或者感兴趣的同学也可以自愿加入。他们同时扮演着用户和开发者的角色，对痛点有深刻的理解，因此这种自给自足的开发方式能够准确的命中需求，不必担心需求和实现不匹配。每个项目团队都是自愿组成，利用业余时间完成开发任务。相比“投资模式”来说，众筹模式不需要特别的抽调开发人员独立成组，在人力资源成本、管理成本和开发意愿等方面都有较大优势。