场景: 我理解灰度发布都是按百分比不断的升级!当升级到百分之 90 后,客服收到大量用户说新功能存在问题,第一时间应该是回滚!
Q1:那么就存在一个数据回滚问题,从数据库,再到 redis 缓存,再到消息中间件 Mq,再扯到大数据 Kafka,这一些列的回滚后的脏数据怎么解决?
想到解决思路:所有的中间件和存储都存 2 遍,首先复制所有的表和 redis 缓存和 Mq 队列,存一个 next_version 后缀 存一个现在的表数据,当发布到 100%后把原来的数据所有都改成 pre_version 后缀,所有的中间和数据 next_version 后缀删除,这样就能顺利的解决回滚问题。
这样就衍生出一个新问题:业务同学一定不能在业务层写这样兼容的代码,那只能是技术支持团队解决,那么怎么保证业务同学写 2 遍数据,能顺利写入?
比如: 用户表新增了一个字段,新增了一个用户联系人表和联系人和用户的关联表
Q1-1 那么在新功能上线时,业务代码如何做到一次数据插入能兼容上一次版本和新版本?
我想到解决方法,自研中间件拦截层,并在业务代码少许的版本代码,比如在新增值字段要表注解 @newField,新增的表要注解 @newTable
从上面来看灰度发布自研的成本相对来说非常高。
望大佬能说一下自己的解决方法把!谢谢了
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.