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