有若服务，每个服务都有集群，直接相互配合才能提供对外服务。假设若干服务要一起升级新版本，要咋起部署才能平滑升级，不影响线上？
面试时遇到的问题，没答出来。。。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2289 days ago, the information mentioned may be changed or developed.
 |
zhangdashuanJul 31, 2020
1
蹲一个正确答案,我感觉是使用版本号,升级新版本保留老版本.
|
 |
RekklesJul 31, 2020
2
停机升级。
|
 |
AriverJul 31, 2020
3
比如有 a->b->c 这样的依赖关系，每个服务四个实例。
先 new c 2 个，然后 new b 两个，然后 new a 两个。然后把流量切到新的这边一部分。 没问题全切。然后干掉老的。 |
 |
IMCA1024Jul 31, 2020
4
只要手速够快 切换得够快
|
 |
TokiomiJul 31, 2020
5
半夜人少的时候发布，被依赖的先发，接口向前兼容，灰度发布，最好还有 AB 环境
|
 |
6
|
21 |
listenerriJul 31, 2020
7
部署策略对比：蓝绿部署、金丝雀发布及其他
https://www.infoq.cn/article/LEI4vSFPiw5A6eN-ASo4 |
 |
WaldenHorizonJul 31, 2020
8
灰度发布，上新服务时保留老服务，并且设置一个特殊标记决定流量往哪走，比如 http header，要求测试用客户端带上标记，同时服务内互相调用时传递，所以这个客户端走的都是新版本服务，而线上版本仍然是老服务
|
 |
sunzirenJul 31, 2020
9
@wangxiaoaer hahahahaha
|
 |
10
@Ariver @wangritian 控制流量往哪个机器上走，这个功能是负载均衡组件提供的么？
|
 |
594duckJul 31, 2020
11
@x97bgt 负载均衡只提供非常粗的，要上 API GW 或者 ESB 才行。非常复杂 。
另外前端都好说，只要动数据库，那就搞了。 比如 100 万行的表，你加个字段试试。哈哈哈哈哈哈，特别酸爽。 我听人家说过 1 亿行的数据库，每周加字段改字段告诉我没事，都这么玩。秒级修改的。 你信么，我是不信的。 |
 |
12
|
 |
sadfQED2Jul 31, 2020 via Android
16
|
 |
loophole12Jul 31, 2020 via Android
17
每个服务划分 set，分 set 逐步发布
|
 |
ChanKcJul 31, 2020 via Android
18
等用户都睡觉了起来搞
|
 |
natsjiJul 31, 2020 via Android
19
发红包就行了
|
 |
DabaicongJul 31, 2020
20
mysql 5.6 以后就支持 online ddl 了。我们正式线上，单表将近 1 亿数据，正常加字段。
|
 |
luckyrayyyJul 31, 2020
21
先把新服务的整个链条依次起来，然一点一点的切流量过去。
|
 |
lavvrenceJul 31, 2020
22
K8s 滚动升级。
|
|
594duckJul 31, 2020
24
@jaylee4869 K8s 能够滚数据库么
|
|
WaldenHorizonJul 31, 2020
27
@x97bgt 大概算是更复杂的负载均衡吧，istio 的虚拟服务可以控制流量
|
 |
GarlandJul 31, 2020
29
拓扑排序
|
 |
30
面试不仅仅是回答问题还要精通问问题：
1.要问，是否可以增加服务器 /容器数量？可以的话，那就简单了，当作重新部署，完事儿了，nginx 切过去 2.要问，是否需要同时支持旧版本？ 3.要问，什么叫平滑，什么叫不影响线上？是说，无人值守，一键切换，还是说，如果有 bug，自动回滚？不影响是说，半夜无访问量时可以停机一小时，还是年故障时间不超过一小时？ 4.服务依赖关系是否手动管理？还是自动拉起部署？ 恰当的问题，有时候会直接带出答案。答不出来的时候反问回去，问到他觉得你其实啥都不懂，或者你找到答案。 |
 |
bonfyJul 31, 2020
31
估计是想说 灰度发布 先切百分之几 然后慢慢切
但是 实际操作么，估计还是半夜一把梭 |
 |
bagheerJul 31, 2020
33
MySQL 的话，版本 8，新增了一个 instant add column
|
 |
nwsmhzJul 31, 2020
34
@winglight2016 大佬
|
 |
otakustayJul 31, 2020
35
线下先布一整套完整的，然后入口切？
|
 |
opengpsJul 31, 2020
36
如果是云服务器集群，那么步骤是：
从伸缩组（集群）移除一部分机器， 升级这部分机器， 然后移回这部分机器， 然后移除其他机器 然后移回这些机器 （建议进行多轮，而不是举例中的 2 轮） |
|
opengpsJul 31, 2020
37
如果是不兼容升级，则不得不停机了，一半会都要求兼容开发新接口，保留老接口可用，毕竟 app 之类的不想浏览器那么好控制（开闭原则）
|
|
opengpsJul 31, 2020
38
一套大型系统，需要考虑的问题很多，本帖下的所有回复仅仅是参考，切勿硬套
|
 |
windsoundJul 31, 2020
39
@wangxiaoaer 掘金牛逼
|
 |
ActraceJul 31, 2020
40
需要平滑过渡的，一般都做增量更新。
比如 /api/v1/ /v2 这样更新，也不是所有接口都需要更新。 |
 |
securityCodingJul 31, 2020
42
网关带+版本号灰度
nginx 也能做只是不能自动化 |
 |
wangyzjJul 31, 2020
43
k8s 或者蓝绿
|
 |
TtTtTtTJul 31, 2020
44
理论上，蓝绿发布就可以了。
实际上，保持代码向下兼容，然后加配置或者控制前端页面放量。 核心上，只要保证最外层的业务在最后开启就可以了。 |
 |
slyang5Jul 31, 2020
45
@wangxiaoaer 掘金的更新是我 见过最粗暴的， 好几次都停服
|
 |
yangbonisJul 31, 2020 via iPhone
46
有向无环图，copy 入度大于 1 的节点转化成树，再从叶子到根分批次 1-n，先开第 n 批。通常反向代理等服务在第 1 批，数据库服务在第 n 批。我不太懂数据库，是用一些 sql 语句来升级的吗？性能问题只有并行和硬件两种方法，并行就是把锁的粒度变小。实际上把本来无关的代码强行安排次序也是锁。
|
 |
zjieJul 31, 2020
47
，把所有需要升级的服务器都部署到单独的灰度组，然后根据用户的 id 之类的灰度，比如最开始是 1%，把这些流量打到新的灰度集群，其他就走原来的。
灰度没有问题，就扩容，扩大灰度范围。 最后没有问题，灰度全量， 一段时间后没有问题，老的机器下线回收。 |
 |
cominghomeJul 31, 2020
48
最有性价比的办法：找个人少的时间，直接滚动发布（能问这个问题我感觉你们系统应该不支持类似灰度路由这样的操作）
|
 |
leeg810312Jul 31, 2020 via Android
49
有没有大佬简要说一下案例流程啊，学习一下
|
 |
chihiro2014Aug 1, 2020
50
|
Select Language