有若服务,每个服务都有集群,直接相互配合才能提供对外服务。假设若干服务要一起升级新版本,要咋起部署才能平滑升级,不影响线上?
面试时遇到的问题,没答出来。。。
1
zhangdashuan 2020-07-31 11:01:27 +08:00
蹲一个正确答案,我感觉是使用版本号,升级新版本保留老版本.
|
2
Rekkles 2020-07-31 11:01:36 +08:00
停机升级。
|
3
Ariver 2020-07-31 11:07:50 +08:00
比如有 a->b->c 这样的依赖关系,每个服务四个实例。
先 new c 2 个,然后 new b 两个,然后 new a 两个。然后把流量切到新的这边一部分。 没问题全切。然后干掉老的。 |
4
IMCA1024 2020-07-31 11:08:25 +08:00
只要手速够快 切换得够快
|
5
Tokiomi 2020-07-31 11:12:24 +08:00
半夜人少的时候发布,被依赖的先发,接口向前兼容,灰度发布,最好还有 AB 环境
|
6
wangxiaoaer 2020-07-31 11:19:30 +08:00 21
|
7
listenerri 2020-07-31 11:21:18 +08:00
部署策略对比:蓝绿部署、金丝雀发布及其他
https://www.infoq.cn/article/LEI4vSFPiw5A6eN-ASo4 |
8
wangritian 2020-07-31 11:22:52 +08:00
灰度发布,上新服务时保留老服务,并且设置一个特殊标记决定流量往哪走,比如 http header,要求测试用客户端带上标记,同时服务内互相调用时传递,所以这个客户端走的都是新版本服务,而线上版本仍然是老服务
|
9
sunziren 2020-07-31 11:25:07 +08:00
@wangxiaoaer hahahahaha
|
10
x97bgt OP @Ariver @wangritian 控制流量往哪个机器上走,这个功能是负载均衡组件提供的么?
|
11
594duck 2020-07-31 11:33:03 +08:00
@x97bgt 负载均衡只提供非常粗的,要上 API GW 或者 ESB 才行。非常复杂 。
另外前端都好说,只要动数据库,那就搞了。 比如 100 万行的表,你加个字段试试。哈哈哈哈哈哈,特别酸爽。 我听人家说过 1 亿行的数据库,每周加字段改字段告诉我没事,都这么玩。秒级修改的。 你信么,我是不信的。 |
12
huobazi 2020-07-31 11:48:43 +08:00 1
|
14
594duck 2020-07-31 12:00:59 +08:00
@iluhcm 并不一定这问题就来了。万一锁了呢,这库正好又是高负载库,那酸爽,那雪崩,那崩溃。所有经验都是被扣 KPI 得出来的教训。
|
16
sadfQED2 2020-07-31 12:24:02 +08:00 via Android
|
17
loophole12 2020-07-31 12:27:20 +08:00 via Android
每个服务划分 set,分 set 逐步发布
|
18
ChanKc 2020-07-31 12:59:45 +08:00 via Android
等用户都睡觉了起来搞
|
19
natsji 2020-07-31 14:24:37 +08:00 via Android
发红包就行了
|
20
Dabaicong 2020-07-31 14:32:36 +08:00
mysql 5.6 以后就支持 online ddl 了。我们正式线上,单表将近 1 亿数据,正常加字段。
|
21
luckyrayyy 2020-07-31 14:34:37 +08:00
先把新服务的整个链条依次起来,然一点一点的切流量过去。
|
22
jaylee4869 2020-07-31 15:01:12 +08:00
K8s 滚动升级。
|
23
594duck 2020-07-31 15:01:17 +08:00
@sadfQED2 你这叫滚动升级,前期准备表稍大一点就是按天算了。特色 facebook 曾经 不是按月算了么。总工时都不省,另外要考虑的问题会更多。
|
24
594duck 2020-07-31 15:01:35 +08:00
@jaylee4869 K8s 能够滚数据库么
|
27
wangritian 2020-07-31 15:14:26 +08:00
@x97bgt 大概算是更复杂的负载均衡吧,istio 的虚拟服务可以控制流量
|
28
privil 2020-07-31 15:25:35 +08:00
|
29
Garland 2020-07-31 15:29:22 +08:00
拓扑排序
|
30
winglight2016 2020-07-31 15:56:11 +08:00 4
面试不仅仅是回答问题还要精通问问题:
1.要问,是否可以增加服务器 /容器数量?可以的话,那就简单了,当作重新部署,完事儿了,nginx 切过去 2.要问,是否需要同时支持旧版本? 3.要问,什么叫平滑,什么叫不影响线上?是说,无人值守,一键切换,还是说,如果有 bug,自动回滚?不影响是说,半夜无访问量时可以停机一小时,还是年故障时间不超过一小时? 4.服务依赖关系是否手动管理?还是自动拉起部署? 恰当的问题,有时候会直接带出答案。答不出来的时候反问回去,问到他觉得你其实啥都不懂,或者你找到答案。 |
31
bonfy 2020-07-31 16:01:40 +08:00
估计是想说 灰度发布 先切百分之几 然后慢慢切
但是 实际操作么,估计还是半夜一把梭 |
32
594duck 2020-07-31 16:01:50 +08:00 via iPhone
|
33
bagheer 2020-07-31 16:02:29 +08:00
MySQL 的话,版本 8,新增了一个 instant add column
|
34
nwsmhz 2020-07-31 16:03:47 +08:00
@winglight2016 大佬
|
35
otakustay 2020-07-31 16:17:13 +08:00
线下先布一整套完整的,然后入口切?
|
36
opengps 2020-07-31 16:19:29 +08:00
如果是云服务器集群,那么步骤是:
从伸缩组(集群)移除一部分机器, 升级这部分机器, 然后移回这部分机器, 然后移除其他机器 然后移回这些机器 (建议进行多轮,而不是举例中的 2 轮) |
37
opengps 2020-07-31 16:20:42 +08:00
如果是不兼容升级,则不得不停机了,一半会都要求兼容开发新接口,保留老接口可用,毕竟 app 之类的不想浏览器那么好控制(开闭原则)
|
38
opengps 2020-07-31 16:21:44 +08:00
一套大型系统,需要考虑的问题很多,本帖下的所有回复仅仅是参考,切勿硬套
|
39
godwinma 2020-07-31 16:39:49 +08:00
@wangxiaoaer 掘金牛逼
|
40
Actrace 2020-07-31 16:40:27 +08:00
需要平滑过渡的,一般都做增量更新。
比如 /api/v1/ /v2 这样更新,也不是所有接口都需要更新。 |
42
securityCoding 2020-07-31 16:43:50 +08:00
网关带+版本号灰度
nginx 也能做只是不能自动化 |
43
wangyzj 2020-07-31 16:48:46 +08:00
k8s 或者蓝绿
|
44
TtTtTtT 2020-07-31 17:02:18 +08:00
理论上,蓝绿发布就可以了。
实际上,保持代码向下兼容,然后加配置或者控制前端页面放量。 核心上,只要保证最外层的业务在最后开启就可以了。 |
45
slyang5 2020-07-31 17:32:44 +08:00
@wangxiaoaer 掘金的更新是我 见过最粗暴的, 好几次都停服
|
46
yangbonis 2020-07-31 19:42:58 +08:00 via iPhone
有向无环图,copy 入度大于 1 的节点转化成树,再从叶子到根分批次 1-n,先开第 n 批。通常反向代理等服务在第 1 批,数据库服务在第 n 批。我不太懂数据库,是用一些 sql 语句来升级的吗?性能问题只有并行和硬件两种方法,并行就是把锁的粒度变小。实际上把本来无关的代码强行安排次序也是锁。
|
47
zjie 2020-07-31 20:53:24 +08:00
,把所有需要升级的服务器都部署到单独的灰度组,然后根据用户的 id 之类的灰度,比如最开始是 1%,把这些流量打到新的灰度集群,其他就走原来的。
灰度没有问题,就扩容,扩大灰度范围。 最后没有问题,灰度全量, 一段时间后没有问题,老的机器下线回收。 |
48
cominghome 2020-07-31 21:46:59 +08:00
最有性价比的办法:找个人少的时间,直接滚动发布(能问这个问题我感觉你们系统应该不支持类似灰度路由这样的操作)
|
49
leeg810312 2020-07-31 22:59:03 +08:00 via Android
有没有大佬简要说一下案例流程啊,学习一下
|
50
chihiro2014 2020-08-01 01:24:01 +08:00
|