这是一个创建于 1820 天前的主题，其中的信息可能已经有所发展或是发生改变。
上次面试被问到，假设有一个微服务，订单服务有集群 A 和 B，因为版本发布导致 A 和 B 不一致了，但是不会报错，这时改怎么处理？
 | 1 rootmaster 2021 年 3 月 8 日 把问题丢给测试人员 |
 | 2 qjbcnrs 2021 年 3 月 8 日 请求带上版本号，版本号分流 |
 | 3 anonydmer 2021 年 3 月 8 日 你应该反问，为什么会有这样的发布流程和结果。 这种结果应该不是为了 AB 测试 |
 | 4 wakzz 2021 年 3 月 8 日 1. 开发时保证不同版本的同一个接口向前兼容 |
| 5 wakzz 2021 年 3 月 8 日 2. 请求通过版本号分流 |
 | 6 cheng6563 2021 年 3 月 8 日 开发时就应该兼容旧版 |
 | 7 airfling 2021 年 3 月 8 日 第一先解决这个不同版本的问题，优先回退高版本的。第二调查为啥会出现不同版本的出现，测试人员和开发人员有没有针对此情况充分测试，三是微服务要有主备服务，服务更新应逐渐更新，并且先请求分流测试是否出现问题，没有问题再更新剩余部分 |
 | 8 imjamespond2020 2021 年 3 月 8 日 via Android 改用 k8s istio 处理 |
 | 9 qwerthhusn 2021 年 3 月 8 日 把旧版本的停了 |
 | 10 xx6412223 2021 年 3 月 8 日 via Android 开放题目，可以撤很远 灰度发布 服务发现附加版本号 发布流程自动化 怎么办的话，干掉旧版本被 |
 | 11 NUT 2021 年 3 月 8 日 一般来说有这种需求场景，肯定是要通知到运维进行备案。让运维心中有数。 毕竟总不能因为 AB 版本导致全服停机吧。 一般在消息设计里面肯定要设计版本号， 否则这种问题必然发生。 如果真的发生这种情况，肯定要进行切流量，dubbo 控制台本身就有切流量的的操作。 如果是 http 服务，这个好办，ng 或者 k8s 的 ingress 或者 service 都可以搞。 不过话说回来，现在没上 k8s 的的确比较蛋疼，毕竟我们 devops +k8s 这一套已经从 18 年用到现在。即便是出问题，也能方便切流量。 所以 1.团队基建有问题 2.架构考虑扩展性有问题 3.测试&发布流程有问题 4.领导有问题。 |
 | 12 xuanbg 2021 年 3 月 8 日 不会报错你怎么知道的不一致？不一致就不一致吧，反正也不会导致业务出错，下次更新版本不就一致了嘛。 |
 | 14 jiangzhizhou 2021 年 3 月 9 日 @marine2c 我觉得面试的时候就应该正面指出对方的问题，技术能力强才能在市场上利于不败之地。很多问题确实解决的方案有多种，就应该选择最适合目前公司业务的。 |
Select Language