这是一个创建于 1576 天前的主题，其中的信息可能已经有所发展或是发生改变。
有若服务，每个服务都有集群，直接相互配合才能提供对外服务。假设若干服务要一起升级新版本，要咋起部署才能平滑升级，不影响线上？
面试时遇到的问题，没答出来。。。
 |
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
|
Select Language