一个微服务业务系统的中台构建之路

作者 马若飞

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

1 雾里看花：解开中台的面纱

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

中台与前后台

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

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

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

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

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

中台与平台

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

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

中台分类

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

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

定义中台

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

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

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

2 必由之路：构建中台的重要性

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

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

3 磨砺前行：Biz-UI业务中台构建之路

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

收集需求，构建团队

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

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

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

中台团队是一个共享服务团队，与前台（业务开发方）是服务与被服务的关系。一个庞大的中台规划因为其长期性和复杂性，很难在短期内满足前台的业务需求，中台团队也很可能因为要服务于多个前台业务而出现资源竞争的矛盾。而我们的中台是以类似拼图的方式逐渐积累而成，现做现用，能快速响应前台业务方需求。与阿里这种大厂打造的有成百上千人员规模的中台团队来说，我们这种小快灵的精英特种部队机动灵活，打一枪换一个地方（做完一个中台项目再做别的项目），具有先天的优势，且构建成本极低，是最适合中小型企业的构建方式。

分析业务，设计功能

明确需求之后，就可以进入当前议题的设计阶段。和任何软件开发流程一样，设计是不可或缺的阶段，作为需求和实现之间的桥梁，它将业务建模转变为技术方案，并保证实施的正确性。对于中台来说，设计阶段的内容又有其特殊的地方：就是通过对各个领域的业务进行分析，寻找出可以抽象的共性能力。因为中台要服务的是多个前台业务线，必须要对整体业务进行分析并找到通用的部分，才能满足复用这一核心价值。如果仅仅是从单一业务出发，只满足当前需求，就等于为当前的微服务实现了它独有的业务逻辑而已。

为避免出现这种问题，在议题分析阶段，我们会通过头脑风暴的方式进行思维碰撞，当某一个人在描述自己的需求时，具有相同或相似痛点的人也会产生共鸣，并提出自己的补充观点，最终整合出一个既满足通用需求，又满足特性需求的技术解决方案。举例来说，我们开发的Job中间件是一个基于Golang和Redis的轻量级定时任务系统，除了具备最基本的定时任务功能外，还根据客户的需求做了个性化扩展。比如“Dynamic Cron”功能支持客户在任务运行期间动态的修改执行周期；“Hook”功能可以让客户定制任务执行后的回调流程，比如调用三方接口，将执行结果发送邮件，或是上传到AWS S3等，对个性化的业务操作做到即插即用。目前Order、Forecast、Partner、Inventory等服务都接入了Job系统，满足了各业务线复用的需求。

需要指出的是，所谓的共性能力包括业务数据、业务功能以及通用的技术能力。比如Placement（广告位）就是一个几乎被各个业务都使用到的业务数据，同时它又具有一定的变体，在广告预测（Forecast）业务中它会具有额外的预测属性，在合作方（Partner）业务中它又会具有中间商相关属性。它们都共享Placement的基本数据同时又具有自己的特殊字段。对于这样的情况我们会把对核心数据模型的操作抽象出来作为模板方法，各业务在此基础上做个性化定制。

对通用技术能力的抽象也有很多例子。比如为了更方便的开发一个新的微服务，我们设计了一套轻量级的服务通信层框架，新服务只需要实现应用初始化接口（AppInitializer），并在配置文件中定义好对应的端口号，就可以实现一个同时支持HTTP和gRPC协议的Web服务器，并可以在ServerOption中添加中台里实现的各种拦截器，完成追踪、请求日志、API权限控制等一系列服务治理功能。而新服务的开发者只需要在标准的protobuf文件中定义自己的业务接口并实现即可。

总的来说，在设计阶段的主要工作就是首先对识别的痛点做根因分析，再基于多个业务线进行领域分析，讨论业务的重合度，并抽象出共性业务，引入中台架构并制定出相应的解决方案。

编码实现，接入前台

在实现阶段我们采用了精益创业中的MVP（Minimum Viable Product）原则。MVP即最小价值化产品策略，是指开发团队通过提供最小化可行性产品，获得用户反馈，并在其基础上持续的快速迭代，最终让产品达到一个稳定完善的形态。下图是一个经典的MVP示例，产品的愿景是开发一种交通工具，可以将用户从A点带到B点。使用MVP设计的产品一直遵循着产品的核心价值，即运输能力，从一辆简单的滑板车开始，逐步演进，最终完成了汽车的制造。在任何一个迭代阶段，产品都是可用的且能满足客户需求。而没有遵循MVP的实现方式就犯了眼高手低的错误，从一开始就设计了一辆汽车但只能提供轮子，其结果就是在大部分迭代阶段都不可用，也无法得到用户反馈，最终很可能会偏离设计目标，与用户的需求不符。

MVP原则对初创型团队非常有效，可以通过试错，快速验证团队的目标，从而定位出产品的核心价值属性。在中台的构建过程中，我们每一个众筹小分队就是一个典型的初创团队，先通过一个最简化的实现方案，解决现有痛点，再逐步完善、扩展，以满足不同业务线的需求。

在开发流程上，我们遵循公司成熟的SAFe体系，每个任务都有ticket追踪。每周的BSAP例会上各个团队会对开发任务做进度更新，在设计、开发、提交代码等阶段进行专项的Review会议，尽最大可能保证整个实现流程的可靠和可控性。

我们的中台用户是各个业务线的微服务开发人员，而这些开发人员对中台能力的需求，来源于客户对产品的需求。因此，业务需求驱动了中台用户（开发者）需求，而用户需求又驱动了中台的能力需求。在这一需求链中，业务线的开发者同时扮演了甲方和乙方，他们作为种子用户，将自己的开发成果接入到各自负责的业务微服务中。而该服务就自然而然的成为了中台功能的试点（Pilot），用于试错和验证产品的正确性。在该组件的可靠性和稳定性得到肯定后，就会推广到其他业务线进行接入工作。一般会有两种中台接入方式：自助式和一站全包式。

• 自助式接入：顾名思义，接入方自己完成与中台组件的整合工作。当然，中台开发者会全程提供文档、示例、培训等一系列技术支持。

• 一站全包式：由中台开发者帮助接入方完成整合工作，包括且不限于提供编码、配置等服务。这种方式一般用于组件升级的时候，代码的变更很小，且风险可控，接入方的代码持有者只需要review修改就可以了。

除此之外，为了在公司内更大范围地共享成果，我们还专门构建了一个BSAP的项目网站，提供了业务中台各个组件的设计文档和用户手册，以便其他兄弟团队也能以自助的方式接入中台，从而在公司范围内达到降本提效、技术共享的目的。经过了一年多的努力，我们的中台项目也日趋完整，覆盖了如下图所示的应用场景：

4 未来可期：中台展望

在业务中台初具规模后，我们开始思考后续的发展。众筹开发模式让中台拼图逐渐完整，但仍然缺少一种黏合剂，可以让它更加的牢固可靠，成为一个真正完善的系统级产品。这需要我们站在企业级架构的层面上去思考问题，以自顶向下的方式去梳理我们的业务和产品线，并结合现有中台做进一步的优化。为此，我们提出了中台未来规划的三个方面：

• 产品化：如果把中台想象成一个产品，那么和任何技术产品一样，中台所具有的能力不仅仅是业务复用，还应该具有一定的非功能性，即各种能力（例如scalability），这也是BSAP项目一开始的初衷。因此，我们的构建目标也不仅仅局限于业务复用本身，还通过一系列的中间件和工具库，让服务具有可靠、可扩展、可复用等各种分布式原语能力。另外，作为一个产品，用户手册是其重要的组成部分。我们的使用文档还需要进一步的打磨，通过标准化和简洁规范的方式给使用者提供便利。

• 规范化：因为中台每个组件都是由某个众筹小分队独立开发的，在设计和实现方案上难免不同。因此，接入方式也有所区别。比如有的组件需要添加一个拦截器，有的需要引入一个类库，有的需要添加配置文件。这种多样的使用方式并不友好，在一定程度上增加了接入难度。未来我们考虑通过一套统一的中台服务接口（Unified mid-platform API），为用户提供统一的接入方式和开发体验。

• 服务化：目前我们大部分中台组件都是以公共库的方式呈现，优势是进程内调用，效率高，性能好。但其劣势就是无法完全对应用透明，需要引入类库，也存在语言绑定的问题，无法适用于异构应用。对于相对独立或者异步调用的组件，可以考虑封装成服务，屏蔽实现细节，降低接入成本。

业务中台作为一个具有战略意义的产品，其构建过程不是一蹴而就的。现阶段的重点依然是尽可能的打磨和优化，让各个组件在易用性、可靠性、稳定性等各方面达到一个较高的水准，从而让用户在使用上更加放心。未来值得期许，但也需要脚踏实地的一步一步前行。

每个人对中台的理解各有不同，但其意义是显而易见的：通过中台战略，将业务能力下沉并复用，使企业拥有快速响应需求、快速试错和创新的能力，从而能够引领市场，获得可持续发展。FreeWheel是以客户为中心的公司，中台之所以重要，就是因为它赋予了我们这类公司最核心的能力：用户响应力。中台的出现，改变了业务的开发方式和交付形态，加速了产品的迭代和进化周期。我们有理由相信，中台并不会是昙花一现的产物，它会和微服务、云原生技术一样，成为软件开发领域的弄潮儿，让我们拭目以待。

希望此文会对你有所帮助！

作者介绍

马若飞，FreeWheel Biz-UI团队首席工程师，《Istio实战指南》作者，人民邮电出版社IT专业图书专家顾问，ServiceMesher社区管理委员会成员。目前就职于Free-Wheel，热衷于技术探索与分享。