很多企业会遇到数据库升级、或数据库迁移的情况,尤其是在自建数据库服务向云数据库服务、自建机房向云机房、旧数据库向新数据库迁移等场景。
然而,我们需要在整个移植过程中保证其稳定性、避免数据遗失、服务宕机等情况,最常见的移植方法之一就是数据库双写移植操作。
如下图所示,这个双写移植的过程为:
在实际操作过程中,不止新旧数据库的操作流量要逐渐开放,实际上新的数据库的读写代码也需要逐步的更新到生产环境服务中,以确保可迭代的稳定平滑移植。
整个过程中,除了自身系统架构的设计外,有两个特别的工具在其中起到重要环节:
如下代码所示,为某一个服务的数据库读取操作分流的示例伪代码:
public async Task> GetSportsByCityAsync(int cityId, int pageIndex, int pageSize)
{
var tasks = new List>>();
// 当读取 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% (如下图)。
在整个的数据迁移过程中,自动化的、及时发现错误问题并回滚,是极为重要的。他可以最有效的帮我们避免诸多问题,如:
实现这些,我们只需要:
通过「链路」页面,我们发现在移植过程中,出现了一些红色项(即 Error),通过资源列可以轻松的看到我们在对新数据库的读取操作中出现了错误异常,如下所示:
点击对应的 Error,我们可以快速查看其对应的调用链路火焰图。如下图所示,根据火焰图的解释:
根据上面的「链路」查找方式,我们快速定位到了出现异常的数据库读操作。那么,我们只需要回到 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 通过双写双读的操作方式实现了降低数据库移植风险的基础方法。
在实际运行中,我们可能有大量的业务需要处理,人为的介入和操作会因为各种原因造成反应不及时的问题。在后续的文章中,我们将介绍更多的内容,如: