背景

自动激活/开通中心系统在电信 OSS 域中是一个关键性的业务系统，主要功能是实现业务订单的需求分解，自动转换出指令，并在网络设备执行从而实现用户的网络通信能力。在系统上，需要根据北向业务和南向网络配置大量的规则数据，并伴随着新业务的加载上线和网络的变革割接不断调整。

当前新业务加载是需要工程师在测试环境中配置和测试后，手动将该业务的配置数据重新配置到生产环境中，实现业务上线。业务配置升级操作多数在深夜 22：00—6：00 这 8 小时进行，需要准备数据迁移、上线测试以及预留一定的配置回退及回退测试时间。

新业务配置的上线过程：

①   在测试环境中，激活系统同步生产环境中的配置数据；

②   在测试环境中，工程人员根据新需求手工进行业务配置（包括：指令、参数、规则等），并对新配置进行测试；

③   工程人员将新业务配置手工迁移到生产环境中，在生产环境的系统中，重新再配置一次新业务的配置数据；

④   接入新业务的工单，根据新配置生成指令，并且路由到对应的网元进行配置执行；

⑤   配置生效或回退：如工单执行成功，新业务配置数据生效；假如工单执行异常，新业务配置数据需要手工回退，并进行回退后的测试。

业务配置加载的痛点分析

当前业务的配置数据迁移大量依赖个人能力，结果准确率波动大和处理时间长，严重影响业务上线的效率和运营成本。

增量配置数据梳理难度高

在每一个需求周期，客户都会提出多个业务配置的需求，每一个需求都包含多个配置操作，而且涉及多个层级（例如：网元à细类à虚指令集à虚指令à实指令à参数à规则等），并且新旧业务配置规则数据会大量交错。

工程人员需要在配置过程中记录，并在多个业务需求、多条配置数据、多个层级数据和多个配置版本中梳理最终的配置数据，这将消耗大量的人力成本和时间成本，并且在配置和测试过程中，存在多人协同的情况，还可能会造成多人梳理同一个业务配置或者遗漏某个业务配置的情况。

重复操作，配置效率低

在测试环境进行业务配置测试时，工程人员已经将配置数据配置了一遍，但在生产环境中进行业务配置加载时，需要将已经配置一遍的数据再配置一次，业务配置加载的效率低。

该操作只是一个重复性的配置，不会为业务配置加载带来提升，而且操作过程也需要时间，在一定程度上压缩了版本上线验证的时间。

依赖人工迁移，容易出错

升级基本上都是深夜，操作窗口时间短，工作量也大，人工迁移容易造成再配置过程中遗漏某些配置，出现异常比对也很困难。

配置策略缺乏灰度功能

对于新业务的发展或新网络能力建设，都是一个逐步试点推广的过程，一般需要针对某些地市或某些条件用户（如 4G 部分用户试点 vEPC 网元）进行试点，当前情况就需要隔离出两套环境，系统整体对业务灰度加载的支撑能力成本高，灵活度低。

业务配置回滚的风险高

工程人员多数在凌晨进行版本发布，假如在发布时间周期里出现了故障而又不能及时解决，那就需要对修改的业务配置进行回滚。当前回滚方式主要有手工删除回滚和数据库回滚，但两种方式都会存在一定的风险问题。

• 手工删除回滚：需要手动对每一个配置进行删除，但数据量较大且层级多，关联关系复杂，会存在数据清除不干净，不能完全回滚；

• 数据库回滚：对数据库进行操作，不但需要工程人员有较高的技术积累，而且也容易造成误操作，影响现网配置数据。

解决思路

对于上述种种问题，从产品层面是希望能够做出一套完整的方案，解决配置发布效率和灰度问题。当接到这个命题的时候，第一时间想到了业界通用的灰度发布方案。

蓝绿发布方案：直接部署一套新版本 V2，等新版本运行起来后，再将流量切换到新版本上，但在升级过程中两套应用同时运行，硬件需求就会翻倍。

灰度滚动发布方案：先启动一个新版本应用，测试人员对新版本进行线上测试，测试通过后将少量的业务流量导入到新版本上，然后再对新版本的生产真实运行结果进行验证（A/B 测试），最后将旧环境应用逐个升级版本，承接全部的业务流量。

虽然灰度滚动发布方案减少了硬件需求，但新版本的流量切换过程伴随着版本的逐步切换，整个灰度升级的过程工作量还是较大。并且对我们来说，生产系统升级更多时候是配置数据的升级而非软件版本升级。

对于我们所面对的绝大多数业务升级情况，需要在测试环境上先进行新策略的配置，测试通过后能自动同步到生产。

生产应用只需一套版本（入上图所示业务流全部进入 V1 集群），但对于部分业务请求使用新配置策略处理，因此需要应用自动识别少部分灰度业务请求，使用 CONF.V2 配置策略进行处理。

整体实现方案

方案实现

当前新业务上线操作繁琐和效率不高，主要是由于在配置迁移、业务上线测试、回退等操作都是人工操作， 因此，需要增加业务配置的灰度发布功能。

• 在测试环境下增加一个录屏插件，自动拦截业务配置的操作，并生成对应的数据库操作语句，支持导入导出；

• 在生产环境中增加一个灰度测试模块，接收分流的工单并执行。

功能介绍

基于目前业务配置加载中的特点和痛点，我们为运营支撑系统提供业务配置加载的灰度发布机制，实现数据同步、配置录制、配置迁移、灰度测试以及业务上线的端到端功能。主要功能模块如下：

1、数据同步

在生产环境外增加一个测试环境，用于业务配置和测试。测试前各个库同生产环境进行同步，测试环境上数据库通过 SCHEMA 分成两个逻辑库，一个存实例，一个同步生产环境的配置数据。测试环境应用一套，CACHE 加载 SB’配置进行业务配置。

2、配置录屏

在测试环境的界面中，提供配置录屏功能，并生成配置操作对应的数据包。录屏功能集成到公司 portal 门户中，点击界面上的录屏按钮即可对配置操作进行录制。支持新建录制、选择录制内容、暂停/停止录制、查看/修改/导出/导入录制的版本包等。

在测试环境上进行业务的配置，配置过程中 WEB 管理应用能针对每一步的配置生成 REDO 日志以及对应的 UNDO 日志。配置包的详细数据如下：

3、配置迁移

在测试环境中，将新业务配置操作生成一条一条的数据库操作语句，然后将这些语句按相应的表结构生成一个业务配置包。生产环境系统支持灰度发布模块，能够导入配置包，实现配置数据快速迁移。

4、灰度测试

在生产环境导入业务配置数据后，点击界面上方的“转灰度”按钮就能将测试环境下配置的数据自动加载到生产环境的灰度库中。然后生产系统支持调整分流测试，能够根据百分比或者参数信息等条件为工单任务打上灰度版本标签，应用中的线程在获取任务后查看到有灰度标签，则从新加载的灰度库中读取配置数据进行配置执行。

5、业务上线及回退

在生产环境的灰度测试验证完成后，点击界面上方的“灰度版本转正”按钮就能将灰度库的配置数据同步到正式配置库中，然后再将分流策略修改为不分流，新业务的配置就正式上线。

假如运行一段时间后，发现系统执行异常，工程人员点击界面上方的“生产库回退”按钮就能执行配置包的 undo 语句，快速的将生产库回退到上一个正常版本。

设计关键点

一、配置数据自动同步

配置数据同步功能，是目前生产升级中最耗时最容易出错的地方，也是我们这次改造提升重点，主要步骤就两个：第一步是在测试拦截并截取到配置数据，第二步是在生产环境自动同步数据。

操作拦截摆在面前的有两种：数据库层面拦截（如触发器）和程序面拦截（如 SPRING AOP）。数据库层面拦截首先不能解决是否拦截的问题，因为在测试环境并不是每次的 CUD 操作都需要拦截的；其次跟数据库的耦合性太强，不适合迁移；最后考虑到以后可能存在的多版本需求并行开发，单靠数据库并不能识别本次配置数据更新是关联到哪个版本上。因此最后选了基于程序面的拦截，在 DAO 层对所有的增删改操作做了拦截，并提取出纯 SQL，参考实现如下。

对于生产环境自动同步数据，主要难点是 ID 序列一致性问题，虽然在开发环境上开始配置新业务前做了一次全局比对，也通过管理上对生产环境的配置做了限制和规范，但总避免不了一些意外情况。如果期间生产环境配置数据发生改变，是会影响到配置数据包 REDO 的结果。

对此我们参考了 TCP 校验和的做法，在开发环境上开始配置时，对干系表的配置数据做了一次指纹快照。在生产环境 REDO 的时候对生产环境也做次同样的校验和计算，如果一致说明环境具备 REDO，避免某次运气不佳导致要清理垃圾数据的情况。同时用校验和的方式还减少了配置包的大小，毕要整套表做个快照的代价是很大的。

二、数据架构方案

数据库中的多套配置数据如何存储规划，要综合考虑实施难度、运维难度和扩展性等多方面因素。

首先考虑了多表方案，用表名后缀-V1,-V2 这样的方案扩展下去，好处就是全部在一个 Schema 中，数据读写简单,但后续扩展性差（比如为保障后缀名一致，无修改表是否也要复制一套副本；配置数据冗余增加维护难度；已归档数据关联查询等问题）。

其次是使用单表多版本记录的方式，在配置表后面增加一个版本号，但其实也会碰到可读性和冗余度的矛盾，而且入侵性也不会弱（所有配置表都得改表结构 DAO 层重新修改，已有关联配置查询都可能修改等）。

最终盘算下来采用了多 Schema 方式，灰度配置数据存储到 Schema2，正式配置数据和实例数据都存储到 Schema1。在灰度转正的时候整体更新 Schema1 的配置数据即可，需回退的时候 Schema2 整体删除，操作隔离性强，并且不存在实例数据分布在多库的问题。

三、配置路由方案

配置路由涉及两种情况，一种是实时处理的业务其使用配置的版本选择，另一种是已归档数据的配置关联查询时候的版本选择。

对于第一个种情况，在业务入口我们统一设置了一套拦截器，根据业务的多维度属性对其进行判断满足情况的业务统一打上灰度标签，当后续统一从缓存中读取配置数据的时候就可以准确判断出是否要读取灰度配置数据。这样统一处理，避免了对业务层代码的入侵修改。同时我们选择了正式和灰度业务同应用容器处理的方式，这样当后续灰度比例的调整只需从业务层面考虑，无需考虑处理灰度业务的应用容器比例是否合适，简化整体操作。

对于第二个种情况，在实例表中一般会用到大量冗余的日志数据，一般情况下的运维查询也不会与配置表关联查询，就算有关联查询一般也会有重要影响，这点可用当前的生产情况进行佐证。目前的生产配置其实也是多版本迭代演进的，库中只保留了最新的版本，有大量的实例数据虽然是通过前版本配置生成的，但多年来并未有这方面的溯源诉求。当然，我们在实例表中增加了版本标签，必要时可通过配置版本备份进行溯源分析问题。

应用效果和价值分析

配置灰度管理方案在电信某省激活系统实现落地，在实际应用中取得了良好的应用效果。业务效果在以下几个方面得到充分体现：

• 运维效率提升：通过配置包自动 REDO，将原来生产环境升级的配置和回滚操作由人工方式改成自动方式，每次操作升级至少可以节省出 1 小时；同时配置脚本工具迁移零丢失，保障了配置迁移的准确性，减少了更多的核对和修复时间。

• 提升业务敏捷度：运行时动态分流策略，使得业务配置 A/B 版本切换可以在任意时间进行，业务切换的灵活性大大提升，不再仅限于晚上的操作窗口。同时业务配置升级时间缩短，升级人力和时间成本降低，新业务会以更快的速度进行迭代，从按月按周迭代提升到按日进行迭代。

• 提升版本管理质量：相比以前的配置升级方式，配置灰度实现了配置的多版本回溯和审计功能，在业务实例归档数据里都会记录其引用的配置版本，当后续出现计算结果差异的时候能实现全回溯。