关于作者

韩峰，社区联合创始人，CCIA（中国计算机协会）常务理事，ACE，曾在多家公司担任首席DBA、数据库架构师等职务。 拥有丰富的一线数据库架构、设计、开发经验，精通多种关系数据库，包括MySQL、MySQL等，对NoSQL和大数据相关技术也有实践经验。 着有《SQL优化最佳实践》、《数据库高效优化》等书籍。

近年来，随着内外部形势的剧变和企业的发展需求，国内企业越来越重视基础软件的自主控制。 特别是对于一些涉及国计民生的重点行业，监管层面也提出了非常明确的指导意见，要求在规定时间内完成技术改造。 数据库作为核心技术软件之一，无疑起着重要的作用，而且非常复杂。 一方面，作为基础软件之一，数据库本身的复杂度较高； 另一方面，数据库技术近年来发展迅速，以分布式、多模式、HTAP为代表的新的数据库架构不断涌现。 这些都会带来更高的复杂度。 同时我们也看到国内数据库发展积极，厂商产品能力参差不齐，用户在选型、研发、迁移、使用等方面面临诸多痛点。 尤其是在整体改造的最后阶段，涉及到将系统从原来的技术栈迁移到新的技术栈，这涉及到大量的工作和风险。

本文尝试从信息创新转型的角度出发，重点关注转型中往往最后转型的数据库部分，即所谓信息创新转型“最后一公里”面临的痛点以及可能的解决方案。

1、信创转型阶段划分

在企业创新创新的过程中，我大致分为四个阶段。

1.架构选择阶段

至此，芯创技术栈的选型就完成了。 当然，这部分需要考虑的因素有很多。 我在之前的文章中也提到了很多选择的难点。

2.研发测试阶段

至此，信创技术栈业务系统的改造和测试就完成了。 这涉及大量的成本（人力、时间）投入。

3.系统验证阶段

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

4.系统上线阶段

此阶段是在系统经过充分验证后，将业务系统从原有的技术栈完全迁移到新的技术栈。 此阶段需要重点解决迁移以及出现的支持和维护问题。

2.阶段：架构选择

1、信创技术栈分散

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

解决上述问题的思路是，用户在选择产品时应尽量做到“生态兼容”，而不是单纯地选择产品。 同时，针对多种产品的选择问题，需要形成标准化、统一的数据管理能力。 对于前者，推荐的方法是为企业内部数据库形成一个标准的访问层； 对于后者，需要形成数据标准管理层。

1）数据库访问标准层

首先，需要统一企业内部的数据库生态，明确采用以MySQL、PG等为代表的事实上的标准生态，提供同一生态内产品之间的标准能力兼容支持（如MySQL生态中的TDSQL、TiDB ， ETC。）; 为MySQL或PG生态提供异构生态产品（如DB2）之间的等效重写和异常处理（当然前提是收敛异构数据库之间的差异，规范编写方式）。

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

2）数据标准管理

面对企业内部多种数据库产品并存，需要从全局的角度制定数据管理策略。 以往的孤立管理方式在目前碎片化的现状下将变得更加困难。 考虑建立数据标准管理层来统一常用的数据管理功能（例如访问安全和数据加密）。

2、产品能力水平参差不齐

如前所述，信创数据库产品能力参差不齐，不同产品之间存在明显的功能差异，包括核心层面、周边生态层面、管理维护层面。 这对于无法面对统一服务接口的用户来说将是非常困难的。 此外，从产品部署形态来看，云数据库产品也成为不少企业的选择。 但用户选择云产品的自主权较差，与原来的方式存在管理差异。

1）数据库增强能力

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

2）云适应性

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

3.阶段：研发及测试

1、原系统迁移评估困难

在实际工作中，我们经常会遇到旧系统无人理解或者只是第三方开发的问题。 例如，在现有业务的改造中，缺乏有效的采集手段，导致改造任务的工作量难以评估。

提供数据库评估工具来捕获数据库语句和负载，并支持回放功能。 对于数据库特定的方言、函数等需要改造的个性化内容，可以生成报告，方便工作量评估和改造工作。 当然，如果你没有工具，也可以通过调查表来完善对之前情况的评估。 之前公众号写过类似的话题，大家可以参考一下。

2. 迁移过程成本高昂

很多应用系统严重依赖原有的技术栈。 过去大多使用DB2来代表大型商业数据库。 应用端支持商业数据库方言、库内计算（存储过程、触发器、函数等）、生态工具（SQL优化、数据集成、控制和维护）等，都有重度依赖。 新的技术栈产品明显不同，通过应用研发改造也有巨大的工作量。 大量基于商业数据库的开发逻辑需要改造和迁移。 有的需要改造以适应新架构数据库，有的需要在异构平台（如大数据平台、缓存平台）或应用层解决。 部分改造内容未对等落实，增加了改造难度。

1）辅助开发平台

为了满足新技术栈下的开发需求，需要坚持架构选型阶段提到的数据库访问标准层的理念，简化数据库的使用。 然而，对于依赖度较高的原有系统，需要提供一种方法来完成旧逻辑到新逻辑的转换。 这比较困难，通常很难实现完全等价的转换。 目前，一些工具能够将复杂的库内计算（如存储过程、触发器等）转换为业务语言实现（如Java），可以大大加快流程。 当然，更重要的是把两者的差异充分暴露给开发者，让大家能够进行有针对性的修改，清楚地了解潜在的工作量。 此外，还可以提供数据集成、数据管理、SQL诊断优化等工具，提高改造过程中的开发效率。

2）平台提高兼容性

可以采用两种方法进一步减少改造工作量。 一方面是提高目标平台与源平台的兼容性。 另一方面，可以通过中间层实现必要的重写，自动完成不兼容的转换。 对于第二个方面，可以通过第三方平台来实现，兼容新旧平台的语法，同时完成等价转换。 对无法转换的部分提供异常提示。 配合之前的改造、重写工具，完成内容的修改，不断收敛两者的差异。

3. 迁移结果评估困难

人们对许多新架构产品提供的兼容性能力存有疑问。 仅通过语法层面的兼容或少量的修改很难保证语义的一致性，会给未来的上线带来风险。 缺乏有效的评估方法来评估应用迁移前后的语义等价性（数据一致性）和性能。

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

4.阶段：系统验证

系统验证阶段是很多重要系统正式上线前必须经过的阶段。 这样可以显着降低可能出现的技术风险，提高系统上线的成功率。

1、迁移风险高且无法回滚

为了在验证阶段验证系统是否正常工作，一般需要开发大量的验证代码。 这部分工作主要是为了满足系统对新旧技术栈的支持以及必要的比较的需要，但这部分往往工作量巨大。 例如，很多应用中常见的数据双发逻辑就是通过数据的双写来同步验证双方的执行结果。 为了实现这个目标，我们必须在原有业务逻辑的基础上，开发出两套适应不同技术栈的代码。

提供基于中间层的轻量级实现，无需应用端修改任何或少量代码即可完成双发送数据写入，实现数据同步写入异构平台。 为了保证数据的一致性，必须提供必要的事务保证，以保证异构数据库之间的数据一致性。 但当一个平台出现异常时，应该能够自动降级，而不影响另一平台的正常使用。 前端业务可以自动感知到这个变化，自动适应这个流程，而业务却毫无察觉。 但系统修复后，可以手动恢复到双传状态（必须提供异常期间的数据补偿能力）。 这个想法的难点在于如何支持写入异构库，同时保持应用代码逻辑不变。 一个常见的想法是通过数据库的交互语言——SQL从一种方言翻译成另一种方言，当然前提是语义对等。 这时可以在架构选型阶段参考之前提到的数据库访问标准层，汇聚企业内部对数据库的访问，尽量简化和规范数据库的使用。 这也是双发行验证阶段可执行比较的前提。

2.迁移验证，无从下手

验证阶段的另一个难点是如何验证。 最好的验证方法是用真实流量验证，但同时需要考虑风险问题。 如果对业务访问进行精准控制，按要求进行业务验证，并提供必要的降级能力以保证安全。 比如常用的基于读写的分配、基于流量的分配（甚至是基于业务特性的分配能力）。

提供流量分配平台，在多平台上线时根据策略分配业务访问。 可以精确控制流向，比如痛点中提到的读写流量，比例流量，或者具有业务特征的流量。 它可以感知底层物理拓扑的变化（甚至异构平台之间的变化），并可以相应地重新分配流量，而不影响正常的业务运营。 这将为上层带来很大的灵活性，可以根据需要随时调整验证策略，降低验证期间的风险。

5.阶段：系统上线

1、迁移窗口短，迁移难度大

系统上线阶段，一个突出的问题是迁移窗口期，一般上线窗口期都很短。 这就要求数据库之间（通常是异构的）数据的迁移能够在短时间内完成，并且还需要提供迁移数据的质量对比，以保证迁移数据的正确性。

为了解决这个问题，通常会使用离线和在线迁移工具，它可以提供异构数据源之间数据离线和在线迁移的能力。 可以充分利用物理资源，利用并行处理技术，提高迁移效率，满足时间窗口。 对于海量数据迁移，通常采用离线和在线相结合的方式，即静态数据离线迁移，动态（主动）数据在线迁移。 通过这种方法，尽可能地压缩迁移窗口。 另外还需要提供数据对比能力，可以根据用户需求进行对比。 这里有两个困难。 一是如何提高比对效率，满足海量数据的比对； 另一个是如何实现动态变化的数据比较。 对于前者，通常的解决方案是让用户选择比较方法（算法），从简单计数、部分抽样、统计报告或复杂算法。 对于后者，可以采用流式窗口比较方法来连续拟合接近实时的结果。

2.新系统不稳定

系统上线后的稳定性也是用户最关心的。 作为一个新产品、新架构，很难保证上线后不会出现任何问题。 虽然可以通过充分的测试、并行验证等手段将这一问题的风险降到最低，但显然不可能完全避免。 更好的办法是提供能力，使用一些手段来最小化问题的范围，并根据可能出现的运营问题来恢复业务。

1）交通管理平台

提供对数据库流量的统一访问并实施治理能力。 通过多种手段（基于标签、SQL文本、用户名、源IP等）实现对SQL流量的精准控制。 比如可以对低效的SQL实现断路器、限流； 可以为特定的SQL提供黑白名单； 可以提供完整的SQL审计能力，满足问题排查，并可以进行事后跟踪等。

2）系统逃生平台（平面图）

为了防范系统性风险或全局性逻辑错误，需要提供异构的“逃生”解决方案。 所谓异构一定是与现有技术栈不同的平台或解决方案。 两个平台之间的数据需要控制和同步，您可以根据需要选择实时同步、延迟同步或手动同步。 同时，在数据之上，还需要提供切换的能力，以便在异常情况下能够在短时间内进行切换。

作者丨韩峰