芜湖seo,企业网站seo哪里好,马云谈2025的房价3500,深圳app定制开发红孩儿场景描述
很多企业会遇到数据库升级、或数据库迁移的情况#xff0c;尤其是在自建数据库服务向云数据库服务、自建机房向云机房、旧数据库向新数据库迁移等场景。 然而#xff0c;我们需要在整个移植过程中保证其稳定性、避免数据遗失、服务宕机等情况#xff0c;最常见的移…场景描述
很多企业会遇到数据库升级、或数据库迁移的情况尤其是在自建数据库服务向云数据库服务、自建机房向云机房、旧数据库向新数据库迁移等场景。 然而我们需要在整个移植过程中保证其稳定性、避免数据遗失、服务宕机等情况最常见的移植方法之一就是数据库双写移植操作。
解决方案
如下图所示这个双写移植的过程为
原始阶段程序只对一个旧数据库进行读写。在现有的读写旧数据库的代码程序基础上需要添加读写新数据库的代码。例如在某个表中插入一条数据时我们需要把这条数据同时插入到新旧两个数据库中。通常情况下我们会并行执行这两个插入操作以尽可能保持服务的原有调用处理时间。当一个写数据库请求进来我们将其写入旧数据库的同时将一个很少的百分比流量写入新的数据库。将写入新数据库的流量比缓慢提高直到 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 TaskListSport GetSportsByCityAsync(int cityId, int pageIndex, int pageSize)
{var tasks new ListTaskListSport();// 当读取 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我们可以快速查看其对应的调用链路火焰图。如下图所示根据火焰图的解释
如下图 ①位置的 Span 所提示在这个地方出现了数据库移植的 Timeout 错误即新数据库的读取时间超出了我们可以接受的请求响应时间阈值。如下图 ②位置中指出错误发生在 Feature flag read-sport-newdb 为 true 的情况下面。也就是说我们可以快速定位可能需要回滚或关掉的 Feature Flags从而避免移植风险。而根据 ③位置 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 服务 实现自动化的放量与回滚方案。
