2.4　快速移植原有应用

有些企业在建设中台之前，内部可能已经IT系统林立，复杂交错。那么在搭建中台时，原有业务系统是否可以继续使用？答案是肯定的。比如企业原有的商城App，在切换为中台基座后，对于C端用户来说，App的操作交互与使用体验没有发生任何变化，而对于企业内部用户而言，也没有新系统的学习教育成本。

事实上，企业建设中台基座，可以在保证应用业务延续性的同时，减少客户的使用感知。因为中台能够提供业务应用高效化移植、业务数据无流失迁移、业务系统无抖动切换的机制，以实现用户“无感知迁移”。

2.4.1　业务应用高效化移植

不同业务应用可能会需要根据各自不同的业务场景，自定义对应的中台能力的执行逻辑，以满足本身业务的需求。那么企业在搭建中台的通用共享能力之后，如何让应用高效地移植接入，是企业中台建设过程中一个很值得思考和实践的问题。为此，软件定义的中台除了提供中台执行态的能力，也提供了中台控制态的能力，用于各应用的自定义。

通过MPC，业务应用开发方可以一览目前中台各领域的场景化能力。MPC提供领域、场景、能力三个层次的可视化能力地图。通过能力地图可以快速查找中台提供的业务场景及对应的API。可能有开发者在此会有疑问：假如某个业务下单时有自己的特殊规则，如何评估场景API是否满足呢？

其实，这个问题是不用担心的。因为MPC的业务配置视图不仅把业务场景及能力以结构化的方式体现出来了，并且在具体的业务场景中，业务能力会关联合适的可配置项。中台用户通过设定和搭配这些配置，可构建出适合当前业务特点的业务规则。当然，如果发现当前已有的可配置的能力但却无法满足需要，业务应用开发方也可以通过编写扩展功能来实现，甚至对中台能力提供方提出具体的改进建议，迭代中台能力。如此一来，业务应用开发方就可以更加快速地了解已有的中台能力，并通过快速配置业务规则和实现扩展功能，满足自身业务应用的开发移植。

2.4.2　业务数据无流失迁移

对于企业而言，数据是企业最宝贵的资产。企业在建设中台时，不仅要让应用接入后的业务数据根据统一标准进行沉淀，也需要继承原有的历史业务数据。也就是说，企业历经多年信息化所积累的业务数据，需要汇集、转换、沉淀到中台。所以，企业在上线中台时，往往都有一个数据迁移的前置环节。但如何保证业务数据的快速、无流失迁移呢？

业务数据迁移主要有两种场景。

在业务整合过程中，各个业务应用可能都需要自身特性的领域对象和属性。这些个性化的属性是在中台抽象合并各业务应用的共性后，遗留下的各应用个性化的部分。那么，中台如何在共性共享的基础上满足业务应用个性扩展及隔离，就是一个重要的课题了。我们在中台迭代过程中，也探索了几种对象属性扩展的模式，例如预留字段、JSON大字段、行转列属性表等。预留字段的问题是可读性太差，并且可能存在预留字段不足的情况；JSON大字段无法满足高性能的精确条件查询；而行转列属性表虽然在字段可读性、查询灵活方面有优势，但很容易出现属性表暴增的情况，从而导致系统性能问题。因此，我们设计了一个更加灵活的数据扩展机制，允许业务应用开发方在开发过程中仅需关注新增的个性化字段，而中台相应的服务API及底层数据库查询语句会自动发现新增的字段，从而大大缩减由于个性化字段新增所需要修改的代码范围，且无须中台能力提供方介入，以此来快速满足各应用对领域对象属性新增的场景，保证业务核心数据的高效、无流失迁移。

上述场景是在中台领域设计、开发扩展的数据兼容迁移。但还有一个关键的场景是，如何在上线时，将大量历史数据迁移到当前的中台系统。因此，中台体系化建设中有一项工作就是，提供配套的数据迁移工具DataOps。DataOps可以配置具体的数据迁移、映射、转换规则，以配置化的方式提高数据迁移的效率，同时提供数据核对及增量迁移能力，保证数据迁移的无流失。

2.4.3　业务系统无抖动切换

当中台已经搭建完毕、准备上线时，面临的问题是如何尽快进行系统切换与验证。一般而言，企业都希望在切换中台底座时，业务不中断或者中断时间很短。而且如果切换过程中发现有重大影响，还可快速回滚，切换回原有系统。所以系统切换如何做到无抖动，也是系统上线时必须考虑的问题。

我们在服务企业数智化转型的过程中，也做了不少探索和改进，比如基于网关模式的切换。在中台之上增加一个业务网关，此网关不仅可将流量转发到中台，还会作为统一服务入口，支持路由将请求转发到原有的业务应用系统。当然，这样做的前提是，此网关支持原有业务系统的多种服务通信协议。在上线中台的时候，在网关上配置一套中台服务的路由规则，通过开关切换，使应用服务调用中台的能力。如此，既能保证业务切换的快捷性和稳定性，还可根据需要直接切换回原有的应用系统，再通过网关重放机制，让业务数据可以正常回到原有业务系统进行操作，提升切换的稳定性。