MVP 原则对初创型团队非常有效，可以通过试错，快速验证团队的目标，从而定位出产品的核心价值属性。在中台的构建过程中，我们每一个众筹小分队就是一个典型的初创团队，先通过一个最简化的实现方案，解决现有痛点，再逐步完善、扩展，以满足不同业务线的需求。
在开发流程上，我们遵循公司成熟的 SAFe 体系，每个任务都有 ticket 追踪。每周的 BSAP 例会上各个团队会对开发任务做进度更新，在设计、开发、提交代码等阶段进行专项的 Review 会议，尽最大可能保证整个实现流程的可靠和可控性。
我们的中台用户是各个业务线的微服务开发人员，而这些开发人员对中台能力的需求，来源于客户对产品的需求。因此，业务需求驱动了中台用户（开发者）需求，而用户需求又驱动了中台的能力需求。在这一需求链中，业务线的开发者同时扮演了甲方和乙方，他们作为种子用户，将自己的开发成果接入到各自负责的业务微服务中。而该服务就自然而然的成为了中台功能的试点（Pilot），用于试错和验证产品的正确性。在该组件的可靠性和稳定性得到肯定后，就会推广到其他业务线进行接入工作。
一般会有两种中台接入方式：自助式和一站全包式。
- 自助式接入： 顾名思义，接入方自己完成与中台组件的整合工作。当然，中台开发者会全程提供文档、示例、培训等一系列技术支持。
- 一站全包式： 由中台开发者帮助接入方完成整合工作，包括且不限于提供编码、配置等服务。这种方式一般用于组件升级的时候，代码的变更很小，且风险可控，接入方的代码持有者只需要 review 修改就可以了。
除此之外，为了在公司内更大范围地共享成果，我们还专门构建了一个 BSAP 的项目网站，提供了业务中台各个组件的设计文档和用户手册，以便其他兄弟团队也能以自助的方式接入中台，从而在公司范围内达到降本提效、技术共享的目的。经过了一年多的努力，我们的中台项目也日趋完整，覆盖了如下图所示的应用场景：
在业务中台初具规模后，我们开始思考后续的发展。众筹开发模式让中台拼图逐渐完整，但仍然缺少一种黏合剂，可以让它更加的牢固可靠，成为一个真正完善的系统级产品。这需要我们站在企业级架构的层面上去思考问题，以自顶向下的方式去梳理我们的业务和产品线，并结合现有中台做进一步的优化。为此，我们提出了中台未来规划的三个方面：
- 产品化： 如果把中台想象成一个产品，那么和任何技术产品一样，中台所具有的能力不仅仅是业务复用，还应该具有一定的非功能性，即各种能力（例如 scalability），这也是 BSAP 项目一开始的初衷。因此，我们的构建目标也不仅仅局限于业务复用本身，还通过一系列的中间件和工具库，让服务具有可靠、可扩展、可复用等各种分布式原语能力。另外，作为一个产品，用户手册是其重要的组成部分。我们的使用文档还需要进一步的打磨，通过标准化和简洁规范的方式给使用者提供便利。
- 规范化： 因为中台每个组件都是由某个众筹小分队独立开发的，在设计和实现方案上难免不同。因此，接入方式也有所区别。比如有的组件需要添加一个拦截器，有的需要引入一个类库，有的需要添加配置文件。这种多样的使用方式并不友好，在一定程度上增加了接入难度。未来我们考虑通过一套统一的中台服务接口（Unified mid-platform API），为用户提供统一的接入方式和开发体验。
- 服务化： 目前我们大部分中台组件都是以公共库的方式呈现，优势是进程内调用，效率高，性能好。但其劣势就是无法完全对应用透明，需要引入类库，也存在语言绑定的问题，无法适用于异构应用。对于相对独立或者异步调用的组件，可以考虑封装成服务，屏蔽实现细节，降低接入成本。
业务中台作为一个具有战略意义的产品，其构建过程不是一蹴而就的。现阶段的重点依然是尽可能的打磨和优化，让各个组件在易用性、可靠性、稳定性等各方面达到一个较高的水准，从而让用户在使用上更加放心。未来值得期许，但也需要脚踏实地的一步一步前行。
每个人对中台的理解各有不同，但其意义是显而易见的：通过中台战略，将业务能力下沉并复用，使企业拥有快速响应需求、快速试错和创新的能力，从而能够引领市场，获得可持续发展。FreeWheel 是以客户为中心的公司，中台之所以重要，就是因为它赋予了我们这类公司最核心的能力：用户响应力。中台的出现，改变了业务的开发方式和交付形态，加速了产品的迭代和进化周期。我们有理由相信，中台并不会是昙花一现的产物，它会和微服务、云原生技术一样，成为软件开发领域的弄潮儿，让我们拭目以待。
希望此文会对你有所帮助！
作者介绍马若飞，FreeWheel Biz-UI 团队首席工程师，《Istio 实战指南》作者，人民邮电出版社 IT 专业图书专家顾问，ServiceMesher 社区管理委员会成员。目前就职于 FreeWheel，热衷于技术探索与分享。
关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书！
