随着近年来内外形势的急剧变化和企业自身的发展诉求，国内企业越来越重视基础软件的自主可控。特别是对于一些关系国计民生的重点行业，监管层也提出了非常明确的指导意见，要在规定时间内完成技术改造。数据库作为核心技术软件之一，无疑在其中扮演着重要的角色，并且具有非常高的复杂度。一方面，作为基础软件之一，数据库本身的复杂度比较高；另一方面，近年来，数据库技术发展迅速，以分布式、多模、HTAP为代表的新型数据库架构不断涌现。所有这些都会带来很高的复杂性。同时，我们也看到，国内数据库在积极发展，厂商产品能力参差不齐，用户面临选型、研发、迁移、使用等诸多痛点。尤其是在整体改造的最后阶段，涉及到系统从原来的技术栈迁移到新的技术栈，工作量大，风险大。本文试图从新创转型的角度出发，着眼于转型中往往是最后转型的数据库部分，也就是所谓的新创转型“最后一公里”所面临的痛点和可能的解决方案。1、创新转型的阶段在企业的转型过程中，分为四个阶段。架构选择阶段该阶段完成信创技术栈的选择。当然，这部分需要考虑的因素很多。我在之前的文章中也提到了选型上的很多难点。研发测试阶段本阶段完成对信创技术栈业务系统的改造和测试。这涉及到很大的成本（人力、时间）投入。系统验证阶段该阶段业务系统改造完成后，需要对新平台的功能、稳定性、易用性进行验证。一般为保证真实性，可以并行业务进行。系统上线阶段该阶段是在系统经过充分验证后，将业务系统从原有的技术栈完全迁移到新的技术栈。现阶段需要着重解决迁移的安全和维护方面的问题。2、阶段：架构选择鑫创技术栈分散鑫创技术栈分散，选型标准尚未形成，用户选型困难。在生态兼容方面，有兼容MySQL、PG、Oracle、自有标准等多种形式。架构包括单机、集中式、分布式等，其中也包括以NewSQL为代表的产品备受关注。在部署平台上，包括私有部署和云部署（包括带基的私有云、公有云）等多种形式。解决方案解决上述问题的思路是，用户在选型时尽量采用“生态兼容”，而不是简单地选择产品。同时，针对多产品选型问题，需要形成规范统一的数据管理能力。对于前者，推荐的方式是为企业内部数据库形成一个标准的访问层；对于后者，需要形成数据标准管理层。数据库访问标准层首先需要统一企业内部的数据库生态，明确采用以MySQL、PG为代表的事实标准生态。针对同生态产品（如MySQL生态TDSQL、GoldenDB、TiDB等），提供标准能力兼容支持；针对异构生态产品（如Oracle、DB2）到MySQL或PG生态，提供对等的改写和异常处理（当然前提是要收敛异构数据库的差异，规范标准的写法）。其次，需要统一企业内部的数据库协议，通过标准的MySQL或PG协议访问各种异构数据库。比如通过标准的MySQL协议接入，底层可以连接不同的数据源（如Oracle、DB2）。当前执行的语法是目标数据源。这种统一的访问管理方式给企业内部的数据库管理带来了极大的方便。面对企业内部多种数据库产品并存的情况，数据标准管理团队需要站在全局的角度制定数据管理策略。以前筒仓式的管理方式在目前碎片化的现状下会更加困难。考虑建立数据标准管理层，统一常用的数据管理功能（如访问安全和数据加密）。产品能力水平参差不齐。如前所述，信创数据库产品能力层次参差不齐，不同产品的功能差异明显，包括核心层次、周边生态层次、管理维护层次。这对于无法面对统一服务接口的用户来说是非常困难的。此外，在产品部署方面，云数据库产品成为众多企业的选择。但在云产品选择上，用户自主性较差，与原有方式存在管理差异。解决思路数据库增强能力增强数据库和周边生态系统的能力。比如针对单机数据库的不足，通过引入中间层解决分布式能力，在不改变底层技术栈的情况下提升数据库的上限能力。云适应性云给用户带来资源供给方式的变化，带来收益；但与此同时，也存在一些问题。一方面来自基础基础变化带来的管理体验变化，另一方面来自与云厂商的绑定问题。用户希望有一层能力可以屏蔽底层的变化和管理方式的差异。3.阶段：研发测试原有系统迁移评估难度大。在实际工作中，经常会遇到一类问题，就是老系统没人知道或者干脆是第三方开发的。比如在存量业务的改造中，缺乏有效的采集手段，难以对改造任务的工作量进行评估。方案源系统评估工具提供数据库的评估工具，实现对数据库的语句和负载的抓取，并支持回放功能。针对数据库特有的方言、函数等需要修改的个性化内容，可以生成报表，方便工作量评估和修改。当然，如果没有工具，也可以通过调查表来完善对之前情况的评估。公众号之前写过类似的话题，大家可以参考一下。迁移过程的成本很高。很多应用系统严重依赖原有的技术栈。之前大多用Oracle和DB2来代表大型商业数据库。工具（SQL优化、数据集成、控制和维护）等，都具有很强的依赖性。但新技术栈的产品存在明显差异，通过应用研发也存在巨大的工作量。大量基于商业数据库的开发逻辑需要改造和迁移。有些需要改造以适应新架构的数据库，有些需要在异构平台（如大数据平台、缓存平台）或应用层解决。部分改造内容不等价，增加了改造难度。为了满足新技术栈下的开发需求，解决方案辅助开发平台需要坚持架构选择阶段提到的数据库访问标准层的概念，以简化数据库的使用。但是，对于严重依赖它的原有系统，需要提供一种方法来完成从旧逻辑到新逻辑的转换。这个比较难，通常很难做到完全等价转换。目前，一些工具能够将复杂的库内计算（如存储过程、触发器等）转换为业务语言实现（如Java），可以大大加快这个过程。当然，更重要的是将两者的不同之处充分暴露给开发者，让大家有针对性地进行修改，清楚地知道潜在的工作量。此外，还可以提供数据集成、数据管理、SQL诊断优化等工具，助力转型过程中开发效率的提升。提高兼容性的平台可以通过两种方式进一步减少改造工作量。一是提高目标平台对源平台的兼容性，二是通过中间层实现必要的重写，自动完成不兼容的转换。对于第二个方面，可以通过第三方平台实现，兼容新旧平台的语法，同时完成等价转换。对于不能转换的部分，给出异常提示。配合之前的改造改写工具，完成对内容的修改，不断收敛两者的差异。很难评估迁移结果。许多新架构产品提供的兼容性能力存疑。仅通过语法层面的兼容或少量的修改，很难保证语义的一致性，会给后续上线带来风险。缺乏有效的评估方法可用于评估应用程序迁移前后的语义等价性（数据一致性）和性能。SolutionIdea迁移结果评估工具可以针对迁移后的运行状态提供运行结果验证机制，包括但不限于执行结果一致性检查、运行效率检查等。通过该能力，可以有效降低系统上线后的风险。4、阶段：系统验证系统验证阶段是很多重要的系统在正式上线之前必须经过的一个阶段。这样可以大大降低可能存在的技术风险，提高系统上线的成功率。迁移风险大，无法回滚。为了在验证阶段验证系统是否正常工作，一般需要开发大量的验证码。这部分工作主要是为了满足系统对新旧技术栈的支持以及必要的对比等需求，但这部分工作量往往是巨大的。比如很多应用中常见的数据双发逻辑就是通过数据双写同时验证双方的执行结果。为了实现这个需求，不得不在原有业务逻辑的基础上开发两套适配不同技术栈的代码。解决方案数据双写平台提供了基于中间层的轻量级实现。在应用端，无需或少量修改代码即可完成数据的双发写入，实现数据同步写入异构平台。为了保证数据的一致性，还需要提供必要的事务保证，以保证异构数据库之间的数据一致性。但是，当一个平台出现异常时，应该在不影响另一个平台正常使用的情况下自动降级。前端业务可以自动感知这种变化，可以在没有业务感知的情况下自动适应这个过程。但系统修复后，可以手动加回双态（需要有异常时期数据补偿能力）。这个想法的难点在于如何在保持应用程序代码逻辑不变的情况下支持写入异构库。常见的思路是通过数据库-SQL的交互语言，将一种方言翻译成另一种方言，当然前提是语义等价。此时，可以参考架构选择阶段提到的数据库访问标准层，汇聚企业内的数据库访问，尽可能简化和规范数据库的使用。迁移验证，无从下手。验证阶段的另一个难点是如何验证。最好的验证方式是用真实流量进行验证，但同时也需要考虑风险问题。如果对业务访问进行精准控制，根据需求进行业务验证，必须提供必要的降级能力来保证安全。比如常用的基于读写的分配，基于流量的分配（甚至是基于业务特性的分配能力）。解决方案流量分发平台提供流量分发平台，满足多平台在线时按策略分配业务访问的需求。可以精确控制它的流向，比如读写流量，比例流量，或者痛点中提到的具有业务特征的流量。它可以感知底层物理拓扑的变化（甚至是异构平台之间的变化），并可以在不影响业务正常运行的情况下相应地重新分配流量。这会给上层带来很大的灵活性，可以根据需要随时调整验证策略，降低验证过程中的风险。5、阶段性：系统上线迁移窗口期短，迁移难度大。在系统上线阶段，一个突出的问题是迁移窗口期，一般的上线窗口期都很短。这就要求数据库之间（一般是异构的）数据的迁移能够在短时间内完成，同时需要对迁移后的数据进行质量比对，保证迁移后的数据是正确的。解决思路离线迁移工具通常使用离线迁移工具来解决这个问题，可以提供异构数据源之间的离线数据迁移能力。可以充分利用物理资源，采用并行处理技术提高迁移效率，满足时间窗口。对于海量数据迁移，通常是离线和在线相结合，即离线迁移静态数据，在线迁移动态（活动）数据。此方法尽可能地压缩迁移窗口。另外，还需要提供数据比对能力，可以根据用户需求进行比对。这里有两个难点，一个是如何提高比对效率以满足海量数据的比对；二是如何实现动态数据比较。对于前者，通常的解决方案是让用户选择一种比较方法（算法），从简单的计数、部分抽样、统计报告或复杂的算法中选择。对于后者，可以采用流窗口比较的方法，不断拟合逼近实时结果。系统上线后新系统的稳定性也是用户最关心的。作为一个新产品、新架构，很难保证上线后不出问题。虽然可以通过充分测试、并行验证等多种手段将出现该问题的风险降到最低，但要完全避免它显然是不可能的。更好的方式是提供一种能力，将问题的影响降到最低，并根据可能出现的运营问题，通过一些手段来恢复业务。解决方案流量管理平台提供对数据库流量的统一接入，实现治理能力。通过多种手段（基于标签、SQL文本、用户名、源IP等）实现对SQL流量的精准控制。比如对于低效的SQL，可以实现熔断和限流；针对具体的SQL，可以提供黑白名单；可以提供完整的SQL审计能力进行故障排除，可以进行事后跟踪等。系统逃生平台（方案）需要提供异构的“逃生”方案，以防范系统性风险或全局逻辑错误。所谓异构，一定是有别于现有技术栈的平台或解决方案。两个平台之间的数据需要同步可控，您可以根据需要选择实时同步、延迟同步和手动同步。同时，在数据之上，还需要提供切换的能力，满足异常情况下的短时可切换性。
