如何避免把中台变成外包团队

大家都知道中台是为了能力复用，但是前台的需求的变化多端的，很容易就把自己变成了外包团队，那如何避免呢？接下来我将分享一些个人对于组件化的认知，希望能帮助到你。

一、什么是组件

组件，它是基于可复用、可插拔为目标的功能单元，同时具有清晰的职责和上下文边界。当然组件颗粒度把控也是一门学问，太大和太小都会直接影响到重用性和复杂性，所以组件一般为某个业务域下具体的、能独立提供服务的产品或者模块。

比如，我们日常使用的统一规范、代码自动生成器、分库分表组件、连接池组件、SQL 拦截组件、多级缓存代理组件等等都是组件。由于它们都不具备业务逻辑，不能算为业务组件，只能定义为技术组件。

二、什么是组件化

根据以往开发的痛点，抽取几个修改频繁，个性化需求较多的功能进行总结抽象，将主流程和个性化剥离开来，以便于沉淀核心流程，将个性化能力开放给第三方团队实现，减少个性化需求的耦合。这个过程就是业务组件化改造。

比如，内容创作基础能力提供通用服务，然后定义出一系列扩展点，包括语言包(中文、英文、泰文等)、创作页面配置(图片、富文本、话题、商品、视频等)、表单字段基本校验(字数限制、格式限制)、内容校验规则配置(黑名单、图片文本、商品好评率等)等，然后第三方团队就可以通过实现扩展点进行编排，从而达到自助式开发的快速试错。

显然组件化的方式更具备扩展性，更能适应各种场景和快速响应新的业务需求。

三、组件化的目的

沉淀业务资产，以面的方式协同复用，从而达到支持快速、低成本的组合式开发，快速应对业务的不稳定性、不确定性、复杂性、模糊性。

再者，从宏观角度来看，组件化改造是从”一体化组织”到”积木型组织”的变革之路。

四、组件化的步骤

组件化的步骤是，重新梳理业务、重新组织数据，明确业务边界，提取可复用的能力进行角色、场景枚举，然后进行统一语义接口设计。前面是主流程设计，再者是扩展点设计。扩展点是主流程和个性化逻辑解耦的唯一核心概念，扩展点由第三方独立实现，独立打包，主流程则借助框架加载执行扩展点。当然框架还提供了链式处理快速失败逻辑，当某个扩展点语义失败时中止执行其他扩展点。

需要注意的是，过程中我们需要从业务研发思绪转变成中台研发思维，避免外包思维。组件化的时候把自己当成中台业务架构，已有架构适配过程把自己当成前台业务实施团队。另外组件化的时候，要重点关注业务活动，还要考虑扩展点定义是否真正满足第三方团队的需求。

我们看到组件化的过程，其实是以 SPI 扩展点方式代替 API 接口开发，与传统 SPI 方式相比多了业务身份概念

五、组件化的方法

1、基于流程引擎的实现

创建多个结点，然后将这个结点形成一条链。业务数据沿着这个链依次进行处理，只有当前结点执行成功后才能执行下一个结点，如果结点执行异常就进行重试，直到成功或者达到最大重试次数限制。

2、基于规则配置的实现

将业务规则的配置单独提取出来，使之与业务系统保持低耦合。

3、基于设计模式的实现

增加一层抽象来隔离变化。比如模板方法。

4、基于运行时加载的实现

比如 Spring Boot 框架的自动装配特性，它会在 ClassPath 中搜索符合预期的 JAR 包并加载其 Bean 对象。

5、基于开放脚本的实现

脚本可以是代码片段、也可以是表达式，还可以是指标计算公式，其可以被动态编辑管理。

六、总结

本文讲解了组件和组件化的概念，还有具体落地方案，希望能给你带来一些思考。多说一句，组件化的初衷是美好的，但是开发、维护、冶理的成本不容小视，比如如何利用 DevOps 工具保证第三方业务包的集成测试。