本文主要是介绍当XTS服务遇到切流...，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
事件回顾
介绍问题前，先介绍两个概念。灰度发布和切流。
灰度发布
灰度发布也叫金丝雀发布。起源是矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。
在灰度发布开始后，部分机器会部署新版本代码，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的 A/B 测试。
当确认新版本运行良好后，再逐步将新版本代码部署到更多机器上，将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力，直到将 100% 的流量都切换到新版本上，完成发布。
如果在灰度发布过程中（灰度过程）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。下面是灰度发布的流量图例。
切流
切流可以理解为流量切换。即通过流量标识，应用系统可以决策走特定的逻辑。
流量切流又分为外部切流（依赖消费方带流量标给到下游），内部切流（应用内部通过参数配置决策走特定逻辑，上游服务消费方不感知）。
图例：应该AP判断流量是否带有切流标识，有就走A逻辑，反之走B逻辑。
问题描述
需求介绍：应用内部通过判断切流标识决策走新链路还是老链路。
- 改动点1: 新增一个外部配置，用于存储需要切流的信息
- 改动点2: 开发切流之后的新链路
下面是问题代码：
问题描述：
由于技术评审和测试评审阶段评估不存在兼容性问题，所以测试完成后就让开发推进灰度发布了。
灰度阶段监控发现，有部分流量出现了NPE报错。
定位研究发现是灰度发布过程，一阶段走到了非灰度机器【老代码】，二阶段走到灰度机器【新代码】。
XTS介绍
XTS（eXtended 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【新代码】 新链路
问题解决
针对这种切流过程的特殊场景场景，需要做代码兼容性处理。
- 代码针对切流标识增加兼容处理：
-
- 针对老流量【无切流标识】，继续走老链路
- 针对新流量【有切流标识】，走新链路
这篇关于当XTS服务遇到切流...的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
