在企业的信创改造过程，我大致将其划分为四个阶段。

这一阶段完成信创技术栈的选型问题。当然这部分需要考虑的因素是比较多的，我在之前的文章中也提到过关于选型的诸多难点。

这一阶段完成业务系统针对信创技术栈的改造及测试。这其中涉及到较大的成本（人力、时间）的投入。

这一阶段完成业务系统改造后，需针对新平台的功能、稳定性、可用性等方面进行验证。一般为保证真实性，可通过业务并行方式进行。

这一阶段是在系统已经得到充分验证后，将业务系统从原技术栈完全迁移到新技术栈。此阶段需重点解决迁移及出现问题的保障维护方面。

信创技术栈分散，尚未形成选型标准，用户选型困难。在生态兼容性上，有兼容MySQL、PG、Oracle、自有标准等多种形式。架构上包括单机、集中式、分布式等多种，包括以NewSQL为代表的产品受到关注。在部署平台上，包括私有部署及云端部署（含私有云带底座、公有云）等多种形式。

解决上述问题的思路是用户在选型时，尽量采用“生态兼容”而非简单的选择产品，同时针对选择多产品问题，需形成标准统一的数据管理能力。针对前者，推荐的方式是形成企业内部数据库标准访问层；针对后者，则需形成数据标准管理层。

1）数据库访问标准层

首先需统一企业内部的数据库生态，明确采用如MySQL、PG等为代表的事实标准生态。针对同生态产品间（如MySQL生态的TDSQL、GoldenDB、TiDB等），提供标准能力兼容支持；针对异构生态产品间（如Oracle、DB2）到MySQL或PG生态，提供等价改写、异常处理（当然前提是收敛异构间数据库差异，规范标准写法）。

其次需统一企业内部的数据库协议，可通过标准的MySQL或PG协议，访问多种异构数据库。例如通过标准MySQL协议接入，底层可对接不同数据源（如Oracle、DB2）。当前执行的语法为目标数据源。这种统一接入管理方式，对企业内部数据库管理带来极大便利。

2）数据标准管理层

面对企业内部多数据库产品并存的情况，需从全局视角出发拟定数据管理策略。之前竖井式的管理方式，在现有碎片化现状下将更加困难。可考虑建立数据标准管理层，将常用的数据管理职能（如访问安全、数据加密）等统一处理。

如之前所谈，信创数据库产品能力层次不齐，不同产品间功能差异明显，包括内核层面、周边生态层面及管理维护层面等多方面。这对于用户来说，无法面对统一的服务界面会很困难。此外，在产品部署形态上，云数据库产品成为很多企业的选择。但在云产品选择上，用户的自主权较差，存在与原有方式的管理差异。

1）数据库增强能力

增强数据库及周边生态的能力，例如针对单机数据库短板，通过引入中间层解决分布式能力，在不改变底层技术栈的情况下，提升数据库的上限能力。

2）云适配能力

云，为用户带来资源供给方式的变化，这会带来收益；但同时也存在一些问题。一方面来自于基础底座变化带来的管理体验的变化，一方面来自于云厂商绑定的问题。用户希望可通过一层能力屏蔽底层变化和管理方式的差异。

在实际工作中，经常会面临一类问题就是旧有系统已无人了解或干脆是由第三方开发的。如在存量业务的改造中，缺乏有效的手段去收集、进而很难评估改造任务工作量。

提供对数据库的评估工具，实现抓取数据库的语句、负载，支持回放能力。针对数据库特有的方言、函数等个性化需改造内容，可生成报告方便工作量评估及改造工作。当然如果没有工具，通过调研表的方式也可以完善对之前情况的评估，公众号之前写过类似主题，可参考。

很多应用系统，对原有技术栈依赖严重，之前大多采用Oracle、DB2为代表大型商业数据库，应用端对商业数据库方言、库内计算（存储过程、触发器、函数等）、生态工具（SQL优化、数据集成、管控维护）等，都存在较重依赖。而新技术栈产品差异明显，通过应用研发改造也存在工作量极大的情况。大量基于商业数据库的开发逻辑，需改造迁移。一部分需改造适应新架构数据库，一部分需考虑在异构平台（如大数据平台、缓存平台）或应用层解决。部分改造内容，不等价实现，提高了改造难度。

1）辅助开发平台

为满足在新技术栈下的开发，需秉承在架构选型阶段谈到的数据库访问标准层的理念，简化对数据库的使用。但对于重度依赖的原有系统，需提供一种方式可完成将旧逻辑向新逻辑的转换，这点是比较难的，通常很难做到完全的等价转换。目前有些工具已经能够实现将复杂的库内计算（如存储过程、触发器等）转化为业务语言实现（如Java），这一方式可大大加速这一过程。当然，更为重要的还是将两者的差异充分暴露给开发者，让大家有的放矢地去改造，明确知道潜在的工作量。更进一步的，可提供一些诸如数据集成、数据管理、SQL诊断优化等工具，方便在改造过程中提高开发效率。

2）提升兼容性的平台

可通过两种手段进一步减少改造工作量，一方面是提升目标平台对源平台的兼容性能力，一方面是通过中间层实现必要的改写，自动完成不兼容改造。针对第二方面的诉求，可以通过第三方平台实现，它可兼容新旧平台的语法，同时完成等价转化。针对不能转化的部分，给出异常提示。配合前面的改造改写工具，完成内容的修改，不断收敛两者的差异。

对很多新架构产品提供的兼容性能力存疑，仅通过语法层面的兼容或少量改造，很难保证语义上的一致性，这会造成未来上线的风险。缺乏有效的评测手段，针对应用迁移前后的语义等价（数据一致性）及性能等能做到评估。

针对迁移后的运行状态，可提供一种机制能验证运行结果，包括但不限于对执行结果一致性的检查、运行效率的检查等等。通过这一能力，可有效降低系统上线后的风险。

系统验证阶段，是很多重要系统正式上线前必须经历的阶段。通过这一方式，可以大幅降低可能的技术风险，提高系统上线成功率。

为了在验证阶段，验证系统是否工作正常，一般需要开发大量验证类的代码。这部分工作主要是为了满足系统支持新旧技术栈及必要的对比等工作，但这部分往往工作量巨大。如很多应用常见的数据双发逻辑，就是通过数据双写，同步验证两边执行结果。为达到这一诉求，不得不在原有业务逻辑上开发两套适应不同技术栈的代码。

提供基于中间层的轻量级实现，在应用侧无需改动或少量改动代码，即可完成数据的双发写入，满足数据同步写入到异构平台中。为保证数据的一致性，还需提供必要的事务性保证，保证异构数据库间数据的一致性。但当一方平台出现异常时，应可自动退化，不影响另一套平台正常使用。从前端业务可自动感知这一变化，可自动适应这一过程，业务无感。但系统修复后，又可以手工添加回双发状态（需提供异常期间的数据补偿能力）。这一思路的难点在于如何实现应用代码逻辑不变的情况下，支持写入异构库。常见的思路是通过将于数据库的交互语言-SQL，从一种方言翻译到另一种方言，当然前提是语义等价。此时，就可以参考之前在架构选型阶段谈到的-数据库访问标准层，收敛企业内数据库的访问，尽量简化、标准化对数据库的使用，这也是对双发验证阶段可执行对比的前提。

在验证阶段还有一个比较难的地方在于如何验证，最好的验证方式是带着真实流量的验证，但同时还需考虑风险问题。如果对业务访问做好精准的控制，按需求进行业务验证，且还需提供必要的退化能力保证安全。如常用的基于读写的分配、基于流量的分发（甚至基于业务特征的分发能力）。

提供流量分发平台，满足在多平台在线情况下，根据策略分配业务访问。可精准地控制其流向，如痛点中提到的读写流量、比例流量亦或是带有业务特征的流量。可感知下方物理拓扑变化（甚至是异构平台间的变化），可对应做流量重分发，不影响业务正常运行。这样对上层来说，会带来很大的灵活度，可根据需要随时调整验证策略，降低验证期间的风险。

在系统上线阶段，一个突出问题是迁移窗口期的问题，其普遍的上线窗口期很短。这就需要在较短的时间内能够完成数据库间（一般是异构）的数据的迁移工作，同时还需针对迁移后的数据提供质量对比，能够保证迁移数据是正确的。

解决这一问题通常采用离在线迁移工具，可提供异构数据源间的数据离在线的迁移能力。可充分利用物理资源，采用并行处理技术提升迁移效率，满足时间窗口。对于海量数据迁移，通常是离线与在线相结合，即将静态数据通过离线方式迁移，针对动态（活跃）数据采取在线迁移方式，通过这一方法尽量压缩迁移窗口。此外，还需提供数据对比能力，可根据用户需要进行比对。这里面临两个难点，一是如何提升对比效率满足海量数据对比；二是如何实现动态变化的数据对比。针对前者，通常的解决思路是可以让用户选择对比方法（算法），从简单计数、部分采样、统计报表或复杂算法。针对后者，可通过流式窗口比较的方法，不断拟合趋近于实时结果。

系统上线后的稳定性问题，也是用户最为关心的。作为新产品、新架构，很难保证上线后一定不出问题。虽然可通过充分的测试、并行验证等多种手段尽量减少这个出现问题的风险，但显然无法完全避免。比较好的方式是提供一种能力，根据可能出现的运行问题，通过一些手段可以尽量减少问题影响范围，恢复业务。

1）流量治理平台

提供数据库流量的统一接入，并实现治理能力。通过多种手段（基于标签、SQL文本、用户名、来源IP等）实现对SQL流量的精准控制。例如针对低效SQL，可实现熔断、限流；针对特定SQL，提供黑白名单；为满足问题排查提供全量SQL的审计能力，可做到事后追踪等。

2）系统逃生平台（方案）

为防止出现系统性风险或全局逻辑性错误，需提供一种异构“逃生”方案。所谓异构，一定是一种有别于现有技术栈的平台或方案。两套平台间的数据是需要做到可控同步的，即可根据需要选择实时同步、延迟同步和人工同步。同时在数据之上，还需提供切换的能力，可满足在异常情况下短时可切换。