Feature Flags 与可观测工具实现数据库灰度迁移 - 开源动态

场景描述

很多企业会遇到数据库升级，或数据库迁移的情况，尤其是在自建数据库服务向云数据库服务，自建机房向云机房，旧数据库向新数据库迁移等场景。

而我们需要在整个移植的过程中保证其稳定性、避免数据遗失、服务宕机等情况，最常见的移植方法之一就是《数据库双写移植操作》。

解决方案

如下图所示，这个双写移植的过程为：

原始阶段，程序只对一个旧数据库进行读写。
在现有的读写旧数据库的代码程序基础上，需要添加读写新数据库的代码。例如，在某个表中插入一条数据时，我们需要把这条数据同时插入到新旧两个数据库中。通常情况下，我们会并行执行这两个插入操作，以尽可能保持服务的原有调用处理时间。
当一个写数据库请求进来，我们将其写入旧数据库的同时，将一个很少的百分比流量写入新的数据库。
将写入新数据库的流量比缓慢提高，直到 100% 为止。在这个过程中如果出现问题，可以及时回滚，并在不影响生产环境服务的情况下进行修复。
写移植完成后，开始逐步放量从新的数据库中读取数据返回给服务，如先允许 10% 的流量在新数据库做读操作。在这个过程中测量性能的同时对比结果。如果在读操作中遇到问题，可以马上回滚新数据库的读流量，并在不影响生产环境服务的情况下进行修复。
直到在新数据库实现 100% 的读写操作一段时间没有问题后，就可以停止与旧数据库相关的代码服务了。

在实际操作过程中，不止新旧数据库的操作流量要逐渐开放，实际上新的数据库的读写代码也需要逐步的更新到生产环境服务中，以确保可迭代的稳定平滑移植。

实践方法与工具

整个过程中，除了自身系统架构的设计外，有两个特别的工具在其中起到重要环节：

负责可灵活、实时、稳定放量、回滚的 Feature Flags 服务。本文中场景所使用的实践工具是 FeatBit。
在整个过程中全方位（支持无侵入和针对性埋点模式）的监测服务异常与及时报警的可观测服务。本文中场景所使用的实践工具是《观测云》。

使用 FeatBit 实现实时的数据库移植请求流量控制

如下代码所示，为某一个服务的数据库读取操作分流的示例伪代码：

第 6 行代码，调用 _fbService.BoolVariation("read-sport-olddb") 方法获得流量控制返回值，如果为 true, 则将读取旧数据库的 Query 函数添加到并行任务执行队列中。
第 9 行代码，调用 _fbService.BoolVariation("read-sport-newdb") 方法获得流量控制返回值，如果为 true, 则将读取新数据库的 Query 函数添加到并行任务执行队列中。
第 19 行代码，为使用 FeatBit Feature Flags SDK 同时运行两个数据库读取操作，并将结果进行对比验证，根据执行情况返回正确值，并向观测云发送相关异常数据。

public async Task<List<Sport>> GetSportsByCityAsync(int cityId, int pageIndex, int pageSize)
{
    var tasks = new List<Task<List<Sport>>>();
    // 当读取 Sport 相关业务的旧数据库开关返回 true 时，则添加读取任务到执行任务队列
    if (_fbService.BoolVariation("read-sport-olddb"))
    {
        tasks.Add(GetSportsByCityQueryAsync(_oldDbContext, cityId, pageIndex, pageSize));
    }
    // 当读取 Sport 相关业务的新数据库开关返回 true 时，则添加读取任务到执行任务队列
    if ( _fbService.BoolVariation( "read-sport-newdb" ) )
    {
        tasks.Add(GetSportsByCityQueryAsync(_newDbContext, cityId, pageIndex, pageSize));
    }
    // 同时执行两个读操作（为了避免新增数据读取增加请求时间），并将结果进行对比并返回
    // 如果结果不一致，则返回旧数据库读取结果，并进行记录
    return await _fbService.RunAndCompareDbTasksAsync(
                    tasks,
                    timeoutDelayForNewDB: 3000, // 设定新数据库的最长等待时间，避免不良体感
                    (timeoutInfo) => { }, // 当新数据库调用超时，发信息至观测云
                    (unMatchInfo) => { }, // 当返回结果不一致时，发信息至观测云
                    (exception) => { } // 当出现异常时，发信息至观测云
                );
}

在把类似于上述的代码逐步的集成到我们的项目中之后，就可以通过 FeatBit 提供的 Feature Flags 控制中心来控制每一个对应的数据库移植的双写双读放量工作了。例如我们先将 feature flag read-sport-from-newdb 放量调整到 5%，若在一段时间未在观测云中观察到异常状况，增大放量百分比至 10% （如下图）。

使用观测云观测移植全过程，及时发现潜在问题

在整个的数据迁移过程中，自动化的、及时发现错误问题并回滚，是极为重要的。他可以最有效的帮我们避免诸多问题，如：

新数据库操作带来巨大的系统资源消耗时，我们需要第一时间知道并通过 Feature Flags 系统立刻回滚
当某个写操作或读操出现时间操作超时数量超过预估阈值时，我们可以快速定位问题，回滚的同时进行快速的修复。提高移植的速度。
当某个写操作或读操作出现信息错误时（如结果不一致、请求时间过长、程序异常等），我们可以根据观测系统具体定位错误信息，从而加速 debug 的速度。
等等

实现这一点，我们只需要：

根据观测云的《快速开始》文档，选择与自己业务相符的技术栈进行小白式的在 15 分钟内完成配置和安装。
运行你已有的服务程序。开始你的数据库系统移植。
打开观测云的《应用性能检测》页，定位到链路，你将看到所有你的服务运行情况。

通过《链路》与《错误追踪》快速定位移植错误

通过《链路》页，我们发现在移植过程中，出现了一些红色项（即 Error），通过资源列可以轻松的看到我们在对新数据库的读取操作中出现了错误异常，如下所示：

点击对应的 Error，我们可以快速查看其对应的调用链路火焰图。如下图所示，根据火焰图的解释：

如下图 (圈 1) 位置的 Span 所提示，在这个地方出现了数据库移植的 Timeout 错误，即新数据库的读取时间超出了我们可以接受的请求响应时间阈值。
如下图 (圈 2) 位置中，指出错误发生在 Feature flag read-sport-newdb 为 true 的情况下面。也就是说我们可以快速定位可能需要回滚或关掉的 Feature Flags，从而避免移植风险。
而根据 (圈 3) 位置 Span 可以快速定位出现超时现象的服务端 API 服务，并且根据捕捉到的 API 的参数与 Header，可以帮助我们后面去更好的调试解决问题。

通过 Feature Flags 实时将读操作回滚至无超时状态

根据上面的《链路》查找方式，我们快速的定位到了出现异常的数据库读操作，那么我么只需要回到 FeatBit 的后台界面，找到上面发现的开关 read-sport-newdb，并将其放量为 true 的百分比向后回滚即可。如下图所示，将 true 的百分比从 10% 回滚到之前未出现读数据异常的 5% 的流量分配。

回滚后，下面代码所示的 _fbService.BoolVariation("read-sport-newdb") 返回值，只会将有 5% 的比率为 true。

// 当读取Sport相关业务的新数据库开关返回 true 时，则添加读取任务到执行任务队列
if ( _fbService.BoolVariation( "read-sport-newdb" ) )
{
    tasks.Add(GetSportsByCityQueryAsync(_newDbContext, cityId, pageIndex, pageSize));
}

总结与后续

这篇文章介绍了使用《观测云》与《FeatBit》通过双写双读的操作方式实现了降低数据库移植风险的基础方法。

在实际运行中，我们可能有大量的业务需要处理，人为的介入和操作会因为各种原因造成反应不及时的问题。在后续的文章中，我们将介绍更多的内容，如：

使用《观测云》的指标服务与《FeatBit》的 Trigger 服务实现移植时自动化实时回滚避灾与报警方案。
使用《观测云的指标服务与《FeatBit》的 Scheduler 服务实现自动化的放量与回滚方案。
等等。