网站配色绿色,高端网站定制开发解决方案,wordpress信用卡支付宝,wordpress rocket事件回顾 介绍问题前#xff0c;先介绍两个概念。灰度发布和切流。
灰度发布
灰度发布也叫金丝雀发布。起源是矿井工人发现#xff0c;金丝雀对瓦斯气体很敏感#xff0c;矿工会在下井之前#xff0c;先放一只金丝雀到井中#xff0c;如果金丝雀不叫了#xff0c;就代表…事件回顾 介绍问题前先介绍两个概念。灰度发布和切流。
灰度发布
灰度发布也叫金丝雀发布。起源是矿井工人发现金丝雀对瓦斯气体很敏感矿工会在下井之前先放一只金丝雀到井中如果金丝雀不叫了就代表瓦斯浓度高。
在灰度发布开始后部分机器会部署新版本代码那么可以将少量的用户流量导入到新版本上然后再对新版本做运行状态观察收集各种运行时数据如果此时对新旧版本做各种数据对比就是所谓的 A/B 测试。
当确认新版本运行良好后再逐步将新版本代码部署到更多机器上将更多的流量导入到新版本上在此期间还可以不断地调整新旧两个版本的运行的服务器副本数量以使得新版本能够承受越来越大的流量压力直到将 100% 的流量都切换到新版本上完成发布。
如果在灰度发布过程中灰度过程发现了新版本有问题就应该立即将流量切回老版本上这样就会将负面影响控制在最小范围内。下面是灰度发布的流量图例。 切流
切流可以理解为流量切换。即通过流量标识应用系统可以决策走特定的逻辑。
流量切流又分为外部切流依赖消费方带流量标给到下游内部切流应用内部通过参数配置决策走特定逻辑上游服务消费方不感知。 图例应该AP判断流量是否带有切流标识有就走A逻辑反之走B逻辑。
问题描述
需求介绍应用内部通过判断切流标识决策走新链路还是老链路。
改动点1: 新增一个外部配置用于存储需要切流的信息改动点2: 开发切流之后的新链路
下面是问题代码 问题描述
由于技术评审和测试评审阶段评估不存在兼容性问题所以测试完成后就让开发推进灰度发布了。
灰度阶段监控发现有部分流量出现了NPE报错。
定位研究发现是灰度发布过程一阶段走到了非灰度机器【老代码】二阶段走到灰度机器【新代码】。
XTS介绍
XTSeXtended Transaction Service是一个分布式事务开发框架用来保障在大规模分布式环境下事务的最终一致性。 1.使用数据库持久化记录事务数据且使用独立的事务模版也就是单独事务
2.特别关注红线对应的 SQL这是一句 update 主事务表的 SQL而这句 SQL 是在发起方的本地事务中的这样一来就和发起方的事务绑定了如果发起方本地事务成功则这句 update 语句必然成功如果发起方本地事务失败则这句 update 语句必然失败这样我们就可以根据 activity 表的事务记录的状态来决定这笔分布式最终的状态是成功还是失败了
3.在调用参与者前启动单独事务插入代表这个参与者的分支事务记录以供后续恢复使用
4.二阶段是通过 spring 提供的事务同步器实现的如果发起方的本地事务失败则二阶段自动回滚所有参与者如果发起方的本地事务成功则二阶段自动提交所有参与者。二阶段结束后删除所有事务记录
5.服务器上的框架代码自动调用二阶段失败的话通过提前配置由兜底服务集群进行事务捞取阶段推进
6.二阶段可配置异步化应对大促等业务场景保证最终一致性即可
7.一二阶段通过数据库存储的上下文进行数据传递
XTS服务遇到切流场景分析
针对切流过程的场景需要覆盖下面四个case
1. 一阶段成功【老代码】二阶段commit【新代码】线上出现的场景
2. 一阶段失败【老代码】二阶段rollback【新代码】
3. 一阶段成功【新代码】二阶段commit 【老代码】
4. 一阶段失败【新代码】二阶段rollback 【老代码】
老链路
5. 一阶段 成功【老代码】二阶段 commit 【老代码】 老链路
6. 一阶段 失败【老代码】二阶段 rollback【老代码】 老链路
新链路
7. 一阶段 成功【新代码】二阶段 commit 【新代码】 新链路
8. 一阶段失败【新代码】二阶段 rollback【新代码】 新链路
问题解决
针对这种切流过程的特殊场景场景需要做代码兼容性处理。
代码针对切流标识增加兼容处理 针对老流量【无切流标识】继续走老链路针对新流量【有切流标识】走新链路
