中台是近两年软件开发领域的热门话题，相关文章也成为各大技术社区和媒体报道的热门内容.作为企业支撑业务发展的核心系统，中台的重要性不言而喻，不少企业也开始尝试中台的建设和实施。Biz-UI的业务中台孵化于BSAP（BusinessServiceArchitectureandPractice）项目。经过一年多的积累，终于开花结果。本文将从中台的基本概念入手，带你探寻Biz-UI团队的业务中台建设之旅。一、雾里看花：揭开中台的面纱2015年，阿里制定了“大、中、小前台”的战略方向，中台一词由此诞生。作为一个中国人创造的词汇，中台没有母语的英语词汇来表达它。我个人比较喜欢用“middle-end”或者“middle-platform”来表达。但可以肯定的是，中台是介于前台和后台之间的产物。那么在了解中台的概念之前，我们先来看看它和前后端的区别。中台和前后台我们先对前后台做一个宏观的定义。前景：企业交付给终端用户（客户）的系统，是企业与客户进行交互的平台。例如，用户直接访问的网站和应用程序可以算作前台。对于FreeWheelMRM核心业务系统来说，前台就是提供给客户的前端页面，以及为页面提供业务逻辑支持的微服务系统，也就是我们内部所说的Domainservices。背景：管理企业核心信息资源（数据）的后台系统、计算平台、基础设施。后台不直接与终端用户交互，不（也不应该）有业务属性。对于FreeWheelMRM的核心业务系统，搜索平台、数据访问层、基础设施都属于后台范畴。稳定可靠是后台追求的目标。前台因为与客户的互动，需要快速响应客户需求的频繁变化。因此，前台和后台在目标需求和响应速度上存在不可调和的矛盾。它们就像两个齿轮，一大一小，因为齿比密度的不同，很难协调顺畅。软件开发领域有一句话：“软件设计和开发过程中出现的任何问题，加一层就可以解决”。这里不讨论它的是非和适用范围，但可以肯定的是，中台的出现是为了解决前后台运行效率不同的矛盾。效率的差异，以达到系统的整体平衡。中台与平台很多人难免混淆中台与平台的概念。我们以Supercell为例。阿里的中台战略起源于对Supercell的一次访问。他们惊叹于这样一个小团队能够以多快的速度开发和复制成功的产品。其背后的功臣是Supercell拥有的具有业务复用性的系统，比如玩家系统、技能系统、装备系统、道具系统等，这些业务系统让他们能够快速复制新产品，而无需重复开发同类业务。Supercell的这些系统是真正的业务系统。那么，Supercell究竟有中台还是平台？先定义一下它们的区别：中台是一个可复用的系统，支持多种前端服务，具有业务属性；平台是一个支持多种前端服务但不具备业务属性的系统。业务相关性和业务无关性是衡量中台和平台的唯一标准。所以区分中台和平台，我们只需要从一点考虑，就是判断他们是否具有业务属性。中台的分类我们经常听到各种中台：业务中台、数据中台、技术中台等等。在中台的分类上，我非常认同网易副总裁王源的理念：“所有中台都是业务中台”。广义上，所谓中台是为业务服务的，使企业能够以更低的成本、更高的效率快速响应业务需求，推出新产品。比如所谓的数据中台，就是对业务数据进行二次加工，将输出结果再次服务于业务。从本质上讲，数据是业务的载体。所谓技术中台，其实就是对基础设施和中间件的能力进行整合和封装，提供统一可复用的接口。从这个角度看，它只是一个中间件平台。中台需要具备实现业务系统所必需的业务元素，封装问题域（业务域）的通用解决方案，这也是本文所提倡的业务中台的核心描述。中台的定义中台是业务抽象层的复用平台。它的核心是抽象公共服务并提供多路复用。复用定义了中泰的核心价值，唯有复用才能达到降本增效的目的，为企业带来收益。中台的建设不仅仅是一个技术问题，更应该跳出单一的业务线，从企业架构层面去考虑，站在企业的角度看整个业务。另一方面，我们也可以认为中泰是产品的平台产品。将通用业务下沉到产品中，形成可复用的平台；也可以反过来理解，即平台的产品化：将业务属性植入平台，使其具有某些产品的特性，为构建特定产品的必要业务要素提供服务。当然，每个人对中台的理解都不一样，我们不需要强加一个统一的定义。理解中台的本质，并以此降低开发成本，提高开发效率，为企业产品赋能，是打造中台的重点。2、必经之路：中台建设的重要性从定义上就可以看出，中台的存在将改变业务开发和交付的方式，以更高效的方式响应业务需求。中台建设背后的诉求，其实是支持多业务，快速响应前台的变化和创新，构建新的业务和产品线。中台是平台发展到一定阶段的产物。当我们的业务扩张和变化速度超过了平台的服务能力时，我们需要将一些通用的业务抽象出来，下沉到平台中，这样才能快速的支持新的业务。发展。因此，中台也可以理解为平台向业务演进的产物。作为MRM核心业务系统的开发团队，迁移到微服务架构后痛点逐渐显现。在梳理和重构服务链路的过程中，我们发现很多业务逻辑是共通的，应该进行抽象。同时，随着公司业务线的拓展，Marketplace等新产品也需要构建一系列新服务。如何高效地构建新服务，复用现有业务逻辑，成为团队亟待解决的问题。因此，搭建业务中台就成为我们解决开发效率的首要任务。3、展望未来：Biz-UI业务中台建设任何系统的建设过程都不是一蹴而就的，尤其是业务中台。任重而道远，上下求索，通过不断的打磨、试错、重构，经过一年多的发展，Biz-UI团队适用的业务中台概念更加清晰，并且功能模块逐步完善和系统化。开发过程可分为3个阶段。收集需求，组建团队2017年，我们将业务系统从单体架构重构为微服务架构时，我们按照业务能力自底向上划分服务。这种方式最大的优点是可以快速完成构建开发过程，尽快完成迁移。但其缺点也很明显：没有统一的规划设计，整个系统缺乏通用的框架和服务治理能力。为了解决这个问题，我们提出了BSAP（BusinessServiceArchitectureandPractice）项目，旨在改进和优化现有的微服务架构，为各个业务线提供可复用的服务治理能力，并提供一套公共库和中间件来改进微服务的开发效率。商业中心在这里孵化。与阿里先制定中台战略再统一开发的做法不同，我们在立项之初并没有刻意去打造业务中台。初衷很简单，就是将相似的业务逻辑以组件或者类库的形式抽象出来，从而达到复用的目的。随着具有业务通用性的中间件和类库越来越多，我们意识到，本质上，我们构建的这些组件的集合就是所谓的业务中台。从投资结构上看，我们的中台团队是通过“众筹模式”建立起来的。项目的参与者是各业务线的核心开发人员。他们描述他们的业务需求和痛点并提出解决方案，通过BSAP会议上的分析和讨论，如果被认为是有价值的话题，将正式进入开发阶段。开发团队是请求者。当然，他可以招募一些帮手，其他有共同需求或兴趣的同学也可以自愿加入。他们同时扮演着用户和开发者的角色，对痛点有着深刻的理解，所以这种自给自足的开发方式能够准确命中需求，而不用担心需求和实现不匹配。每个项目组都是自愿组建的，利用业余时间完成开发任务。与“投资模式”相比，众筹模式不需要专门部署开发者组成独立的群体，在人力资源成本、管理成本、开发意愿等方面具有很大优势。中台团队是共享服务团队，前台（业务开发端）是服务与被服务的关系。由于其长期性和复杂性，庞大的中台计划很难在短期内满足前台的业务需求，而且中台团队很可能因为要服务于资源竞争而产生冲突多个前端业务。而我们的中台是通过类似拼图的方式逐渐积累起来的。即用即用，可以快速响应前端业务方的需求。相对于阿里这种大厂数百人打造的中台团队，我们小而快的精锐特战队灵活机动，一枪换位（完成一个中台项目后其他项目），具有先天优势，建设成本极低，是最适合中小企业的建设方式。分析完业务，定义好设计功能的需求后，就可以进入本课题的设计阶段了。与任何软件开发过程一样，设计是必不可少的阶段。作为需求和实现之间的桥梁，将业务建模转化为技术方案，保证实现的正确性。对于中泰来说，设计阶段的内容有其特殊性：就是通过分析各个领域的业务，找出可以抽象出的共性能力。因为中台需要服务多个前端业务线，所以需要对整体业务进行分析，找到共通的部分，才能满足复用的核心价值。如果只从单一业务做起，只满足当前的需求，相当于对当前的微服务实现了它特有的业务逻辑。为了避免出现此类问题，在问题分析阶段，我们会采用头脑风暴的方式进行思维碰撞。当一个人在描述自己的需求时，有相同或相似痛点的人也会产生共鸣，提出自己的想法。补充意见，最终整合出既满足通用要求又满足特性要求的技术方案。比如我们开发的Job中间件，就是一个基于Golang和Redis的轻量级定时任务系统。除了最基本的定时任务功能外，还根据客户需求进行了定制。例如，“DynamicCron”功能允许客户在任务运行过程中动态修改执行周期；“Hook”功能允许客户自定义任务执行后的回调流程，如调用第三方接口、将执行结果发送至邮箱、或上传至AWSS3等，实现即插即用发挥个性化的商业运作。目前Order、Forecast、Partner、Inventory等服务都接入Job系统，满足各业务线的复用需求。需要指出的是，所谓通用能力包括业务数据、业务功能和通用技术能力。例如Placement（广告位）是几乎所有商家都会用到的业务数据。同时，它有一定的变体。在广告预测（Forecast）业务中，它会有额外的预测属性。在合作伙伴（Partner）业务中，它会有中间人相关的属性。它们都共享Placement的基础数据，但有自己的特殊领域。针对这样的情况，我们会把核心数据模型的操作抽象成一个模板方法，各个业务会在此基础上进行定制。也有很多通用技术能力抽象的例子。比如为了更方便的开发一个新的微服务，我们设计了一个轻量级的服务通信层框架。新服务只需要实现应用初始化接口（AppInitializer），并在配置文件中定义对应的端口号即可。可以实现一个同时支持HTTP和gRPC协议的web服务器，在ServerOption中添加中台实现的各种拦截器，完成跟踪、请求日志、API权限控制等一系列服务管理功能。新服务的开发者只需要在标准的protobuf文件中定义自己的业务接口并实现即可。一般来说，设计阶段的主要工作是先对识别出的痛点进行根因分析，然后基于多条业务线进行领域分析，讨论业务重叠，抽象出共同业务，引入中台架构，制定出相应的解决方案。编码实现，接入前台在实现阶段，我们采用了精益创业中的MVP（MinimumViableProduct）原则。MVP即最小价值产品策略，是指开发团队通过提供最小可行产品获取用户反馈，并在此基础上持续快速迭代，最终使产品达到稳定完善的形态。下图是MVP的一个经典示例，其产品愿景是开发一种可以将用户从A点带到B点的车辆。使用MVP设计的产品始终遵循产品的核心价值，即运输能力，从一辆简单的滑板车开始，逐渐进化，最终完成了一辆汽车的制造。在任何迭代中，产品都是可用的并满足客户需求。没有按照MVP的实现方式去做，反而犯了眼高手低的错误。我从一开始就设计了一辆汽车，但只提供了轮子。会偏离设计目标，不符合用户的需求。MVP原则对于初创团队非常有效。通过试错，可以快速验证团队的目标，从而定位产品的核心价值属性。在中台建设过程中，我们每个众筹团队都是典型的创业团队。首先，通过最简单的实施方案，解决现有的痛点，然后逐步完善和扩展，以满足不同业务线的需求。在开发过程中，我们沿用公司成熟的SAFe系统，每个任务都有工单跟踪。在每周的BSAP例会上，各团队会及时更新开发任务的进展情况，并在设计、开发、代码提交等阶段召开专项评审会，尽可能保证整个实施过程的可靠性和可控性。我们的中台用户是各个业务线的微服务开发者，这些开发者对中台能力的需求来源于客户对产品的需求。因此，业务需求驱动中台用户（开发者）的需求，用户需求驱动中台的能力需求。在这条需求链中，业务线的开发者同时充当甲方和乙方。作为种子用户，他们将自己的开发成果与自己负责的业务微服务对接。而这个服务自然而然的成为了中台功能的领航员（Pilot），用来试错和验证产品的正确性。在组件的可靠性和稳定性得到肯定后，将扩展到其他业务线进行接入工作。中台接入方式一般有自助和一站式全包两种。自助接入：顾名思义，接入方自行完成与中台组件的集成。当然，中台开发人员会全程提供文档、示例、培训等一系列技术支持。一站式全包：中台开发者帮助接入方完成集成工作，包括但不限于提供编码、配置等服务。这种方式一般用于组件升级。代码改动小，风险可控。接入方持码人只需审核修改即可。此外，为了在公司内部更大规模地共享成果，我们还专门搭建了一个BSAP项目网站，提供了业务中心平台各个组件的设计文档和用户手册，方便其他兄弟团队也可以使用自助通过一种方式接入中台，从而达到公司内部降本增效、技术共享的目的。经过一年多的努力，我们的中台项目已经越来越完善，涵盖了如下图所示的应用场景：4.未来可期：中台展望业务中心-台湾开始后初具规模，我们开始思考后续的发展。众筹开发模式逐步完成了中期拼图，但还缺乏一种胶水，可以使其更加牢固可靠，成为真正完整的系统级产品。这就需要我们从企业级架构的层面去思考，自上而下梳理我们的业务和产品线，结合现有的中台进一步优化。为此，我们提出中台未来规划的三个方面：产品化：如果把中台看成一个产品，那么和任何技术产品一样，中台的能力不仅仅是业务复用，还有一个某些非功能性，即各种能力（比如可扩展性），这也是BSAP项目的初衷。因此，我们的建设目标不局限于业务复用本身，而是通过一系列的中间件和工具库，让服务具备可靠性、扩展性、复用性等各种分布式原语能力。另外，作为一款产品，用户手册是其中很重要的一部分。我们的使用文档还需要进一步细化，通过标准化和简洁的规范来为用户提供便利。标准化：由于中台各组件均由众筹团队独立开发，在设计和实现上难免存在差异。因此，访问方法也不同。比如有的组件需要添加拦截器，有的需要引入类库，有的需要添加配置文件。这种多样的使用方式并不友好，一定程度上增加了访问难度。未来我们会考虑通过一套统一的中台服务接口（Unifiedmid-platformAPI），为用户提供统一的接入方式和开发体验。Servicing：目前我们大部分的中端组件都是以公共库的形式呈现的。优点是进程内调用，效率高，性能好。但它的缺点是不能对应用程序完全透明，需要引入类库，还存在语言绑定问题，不能应用于异构应用程序。对于相对独立或异步调用的组件，可以考虑将其封装成服务，屏蔽实现细节，降低访问成本。业务中台作为具有战略意义的产品，不可能一蹴而就。这个阶段的重点还是尽可能打磨和优化，让每个组件在易用性、可靠性、稳定性等方面都达到更高的水平，让用户用起来更安心。未来值得期待，但也需要脚踏实地，一步一个脚印地往前走。每个人对中台都有不同的理解，但其意义是显而易见的：通过中台战略，业务能力下沉和重用，使企业具备快速响应需求、快速试错、创新的能力，才能引领市场持续发展。FreeWheel是一家以客户为中心的公司，中台之所以重要，是因为它赋予了我们这样一家公司的核心能力：用户响应能力。中台的出现改变了业务发展方式和交付形式，加速了产品迭代和演进周期。我们有理由相信，中泰不会是昙花一现的产品。它将和微服务、云原生技术一样，成为软件开发领域的一种趋势。让我们拭目以待。希望本文对您有所帮助！5.作者简介马若飞，FreeWheelBiz-UI团队总工程师，《Istio 实战指南》作者，人民邮电出版社IT专业图书专家顾问，ServiceMesher社区管理委员会委员。目前就职于FreeWheel，热衷于技术探索与分享。
