一、前言
1.1 读者对象
本文适合后端资深工程师、架构师，或从事中台、平台类研发的普通工程师阅读。中台技术不是一门具体的软件技术，没有一定之规，需要从业者根据自身业务特点选择适合的设计。本文根据笔者亲身中台项目经历写成。笔者负责的是中型互联网公司的核心业务系统的中台化改造工作，考虑到自身业务规模和研发资源，我们的改造工作从细节做起，逐步探索适合我们自己的中台之路。所以本文强调要循序渐进地将业务系统改造为业务中台。其中的内容不算高大上，而是脚踏实地。此外，笔者负责的系统的业务模型侧重流程化，所以在介绍一些具体做法时难免会存在局限性，无法顾及更广泛的场景，请读者见谅。
1.2 中台思想的产生
中台强调的是复用，而复用这个思想在软件领域早已有之。在 Martin Fowler 的《重构》一书指出了代码重复，即代码没有被复用是首当其冲的坏味道。而业务系统的能力无法被复用，同样也是业务系统架构的坏味道。但就如同重复的代码不易被发现一样，重复的业务能力更加难以发现。这些业务能力重复的坏味道隐藏在了代码实现、系统架构，甚至组织架构中。因此，需要架构师、业务负责人独具慧眼，发现并解决这些问题，从而提高业务研发效率和质量，加快业务发展速度，降低业务试错成本，提升系统技术升级效率，打破程序员996的死结。而这一切最终就形成了我们现在所说的中台。
二、循序渐进的中台研发
强调中台研发要循序渐进，原因是中台研发难度高，并且目前可参考的案例不多（介绍较详细的主要是阿里的 TMF）。因此不能对中台盲目跟风、急功近利、仓促上“码”。否则，不仅无法起到中台应有的作用，反而还会打击团队士气、浪费研发资源。
如何循序渐进地落地中台呢？前文说过，中台要解决的是业务能力重复这个坏味道，而这个坏味道隐藏在三个层面：代码实现、系统架构、组织架构。这三个层面的问题彼此影响，但总体而言，代码实现的问题最为底层，也往往是大部分问题的根源。而问题越往后，层次越高，难度越大。所以，落地中台，我们最好也要先从最简单的代码实现层面入手。
看到这里，可能有人要笑了，难道中台就等同于代码重构吗？当然不是，笔者只是建议先从代码问题入手。当然，如果研发资源充足，又有对中台研发经验丰富的架构师带领，那自然可以有更高的起点。但这样的条件不是所有企业都具备的。当然，中台的目标是业务可配置化，将业务研发变为低代码，甚至无代码的配置过程，但支撑起低代码、无代码的系统，实际还是需要用代码来实现。
说这么一大段，笔者的意思无非是说，中台固然美，但代码始终是基础。代码写不好，中台不要想。
话题回到如何循序渐进地落地中台。对这个问题，笔者同样认为也需大致三个阶段。这三个阶段和坏味道的三个层面不是一一对应，但反映了相同的由简到难的思想。
中台实施的三个阶段：
- 重点突破：通过解决重点业务场景中的业务研发效率低，业务能力复用难的问题，探索适合本业务本系统的中台方向，积累经验。
- 由点及面：在突破了重点方面的复用难题之后，将现有的中台改造经验推广至更多业务场景，同时探索针对新问题的解决之道。
- 打破边界：在解决现有业务系统的问题之后，要将开拓思路，将业务中台的能力拓展至完整业务链路，打破系统和组织的边界，而非仅局限于现有系统范围。
2.1 重点突破
俗话说万事开头难，这一步很关键，往往也很难走。笔者在17年下半年开始对所负责的重点业务系统进行改造时（后续简称项目 A），实打实的花了半年时间。这其中自然有笔者之前对中台研发毫无经验的原因，但也部分说明了此项工作的不易。
以笔者经验为例，此阶段的工作又可分为三个部分：
- 组件拆分
- 组件装配
- 业务 DSL
2.1.1 组件拆分
中台的核心思想是复用，但如果业务系统是一块铁板或一团乱麻，那就谈不上复用，这时就需要拆分。我们要将系统拆分不同的业务组件。通过分析现有需求、设计文档、系统代码，以及和具体研发工程师、产品经理，包括测试人员分析讨论，找出此重点业务场景下历史和后续可能需求之间的变与不变。接下来，将不变的部分梳理规范，使之成为可以复用的核心业务流程。而变化的部分，在核心业务流程之上，通过定义并实现扩展点的方式给予支持，形成扩展组件。
整个系统，就是由核心流程和扩展组件组成。
但俗话说，软件开发唯一不变的就是一直在变。所以，现在的核心组件，可能会成为以后的扩展组件。所以核心业务流程也需要按照面向接口编程的原则进行抽象定义，使之易于扩展替换。
2.1.2 组件装配
有分便有合。业务系统拆分为组件之后，还需装配在一起，形成整体后方可使用。那业务组件如何装配？使用 Spring，这往往是程序员首先想到的组件装配方式。但我们需要的功能要远超出 Spring 所能提供的范围，主要包括：
- 组件路由：为不同的业务场景或业务请求选择合适的业务组件。通常使用职责链模式实现。
- 组件编排：将组件编排为一个整体，实现完整功能。组件的组合有多种方式，简单的串联、状态机、职责链等都是组件编排的实现方式。
- 组件配置：组件是一个静态，在运行时为同一个组件指定不同的配置，从而适应不同的场景，使之易于复用。
因为篇幅限制，本文不深入介绍组件装配的实现方式，留在后续文章中详解。
2.1.3 业务 DSL
业务 DSL 的核心思想是使用领域专属语言，或者配置语法，实现简洁高效且易于理解的业务配置化能力。
上一小节提到的组件装配，因为所需功能超出了 Spring 这样的框架的功能范围，所以需要自行设计实现。在为自己业务中台设计组件装配功能时，首先要思考如何使用，然后再思考如何实现。如何使用是方向，只有方向对了，实现才有意义。
在笔者负责的中台类项目中，首先要解决的痛点是接口适配问题，即如何让不同业务场景下的不同接口和不同参数组合对于上层系统来说变成一个统一的接口。因此，笔者项目中的业务 DSL 的主要内容是由配置路由信息、请求参数映射配置、响应数据解析配置等三部分组成。而实际的组件路由等能力则隐藏在了 DSL 实现细节中。
2.1.4 小结
笔者在对项目A落地后实施的几个业务需求研发工作进行评估后发现，通过中台对业务研发效率的提升，节约了至少3个人月的开发时间。虽然项目A本身花费了同样3个人月的研发时间，但通过前期技术架构升级，加快了后续业务需求的研发速度，相当于用当下的时间为未来发展铺平了道路。节约的这3个月中，有对支付成功率显著提升的业务改进，也有业务重点发展方向，保守估计也会有千万元级的收入提升，收益显著。更重要的是为后续系统研发工作指明了方向，使得业务研发和技术改进可以兼顾，并相互促进，不断提升，形成良好的正向循环。
2.2 由点及面
接下来我们要将中台能力从一个场景推广到多个业务场景，这时需要针对不同场景配置不同业务流程。在具体实现时会涉及如业务身份识别、扩展点定义、组件编排、组件路由等具体问题。
2.2.1 业务身份识别
因为中台要支持多个业务方，很多业务场景，因此这里涉及到业务身份的识别问题。通过识别业务身份，定位不同的业务配置、数据模型等内容，避免不同业务的执行过程相互干扰。
我们的业务并不需要使用阿里的“人货场”这样三级复杂的业务身份抽象规则，而是简单的分为了业务方 + 业务场景两个维度。通过网关服务，将业务身份固化在对遗留接口的定义中。对于新接入的业务方，采用显式传递业务身份标识 + 密钥的方式实现。
2.2.2 定义扩展点
为了使中台具有适合不同业务场景的能力，我们将中台之上的各种业务组件都定义为扩展点。我们的扩展点分为两级：Step 和 Action。Step 是一级扩展点，Step 可以通过组件编排成为不同的流程 Flow。Step 背后基于 StepTemplate 实现。StepTemplate 对应的就是具体的编程实现的业务组件。StepTemplate 需要依赖 Action 完成具体的业务逻辑。Action 的物理形式是接口，扩展包的配置文件中需要指定哪些接口被定义为了 Action。如果一个接口被定义为 Action，那 Step 通过配置声明，就可以静态或动态地选择适合的 Action 完成整个业务处理。
2.2.3 流程（组件）编排
Step 可编排组合为流程。为简化设计和使用，我们的流程为极简流程，仅为单向流程，不包含条件判断和循环，后续会增加并发流程，但仅此而已。这么做是考虑到现有需求不需要复杂的流程编排，同时可以简化设计实现，并方便使用者定义流程，方便调试跟踪。
为了实现对流程编排的静态检测功能，我们在 Step 中实现了对输入输出参数的配置功能，通过检查流程上下步骤之间出入参的匹配情况，静态检查流程配置的正确性。
2.2.4 组件路由
上一小节的组件编排只能定义一个粗粒度的业务流程，在这个粗粒度的业务流程中，一定存在各种分支流程。那这些分支流程需要对应不同的业务策略。这里的一个问题就是如何将特定请求路由至特定策略中。这便是组件路由的意义。
组件路由有两种实现：表驱动和职责链。表驱动虽然高效，但只能解决简单业务。因此，职责链是应用更普遍的实现方式。在我们的中台项目中，Step 对 Action 的动态路由就采用了职责链的设计。具体职责链能力有平台提供，业务组件只需声明配置即可拥有职责链的能力。
在阿里 TMF 1.0 中，过长的职责链会导致节点之间相互影响。如果某节点的过滤规则不完备，就可能导致错误的选择。要解决这一问题，需要引入配置隔离，例如我们的中台项目中每个 Step 对其 Action 职责链中的候选者可进行配置，控制范围。
2.2.5 小结
在更多的业务场景中落地中台，必然会遇到各种技术和业务问题。因篇幅原因无法一一介绍，而我们的中台系统能力也是在不断建设完善过程中。
2.3 打破边界
上一个阶段是在一个团队所负责的业务系统上实施中台改造，在逐步将上述关键技术点完成后，就可以考虑进入第三阶段。第三阶段的目标是打破团队组织架构的边界，将完整业务链路上原本分散在各系统上的业务能力下沉到业务中台之上。这里的技术工作同第二阶段没有本质区别，就是继续完善中台的设计，使业务能力可以快速正确的被复用。
这一阶段的难点不仅在于技术，更在于人。如何让各层面的领导层认同中台化的工作，并推动相应组织架构的调整，这既需要现有中台系统货真价实的技术能力以及成功案例支持。同时也需要领导层对中台这一方向的认可。这需要中台工作负责人从技术、业务，以及公司长远发展角度去推进中台项目在更大范围落地。
因为这一部分的工作已经超出了技术范畴，所以这里就不再具体介绍。
三、总结
笔者早期的职业生涯中，更多的是关注如何通过编程技术，如代码重构、设计模式、单元测试等手段，提高代码的复用能力。但经历过多家不同类型的软件公司之后，笔者发现写坏代码的速度永远快于好代码，代码重构的速度永远赶不上代码退化的速度。因此，随着中台的风潮，我的观点也发生了变化：代码的问题，不能单纯靠代码的方法解决，而是需要通过以架构手段为主的综合治理；架构师写代码的目的在于让普通开发人员少写代码。即便普通开发人员要写代码，那一定要个架构师的代码隔离开来。
笔者的这些思想其实是和中台思想不谋而合。在18年笔者所负责的系统落地了第一阶段的中台化改造之后，业务研发速度成倍提高，系统质量持续稳定，手下的小伙伴也终于不用担心项目搞不完要加班了。第一阶段的成功让我们信心倍增，所以我们从19年开始就在构思如何在更大范围内落地中台。当然，这不是一个简单的事情，没有参考，研发资源短缺，都限制影响了中台的研发速度，但我们相信只要业务持续发展，那中台研发就是有意义，有回报的工作。