对于一个分布式 HTTP 服务的场景下， 如何才能实现无感知地升级？ 看到这样个问题， 有大佬能回答下吗 =-=

具体场景是啥，一个对外提供 http 接口的服务要做不停机发布？
最简单的就是趁晚上业务流量小的时候做蓝绿发布呗。

分布式 http 服务,让我笑一会

如果是面试题, 那先确认场景. 分布式 http 服务不太懂是什么.

我理解是这样, 一个网站, 后端服务其实是很多机器组起来的集群, 访问网站的时候流量是用某种方式打到了某台机器上

如果是这样

那么这个决定流量打到哪个机器的组件就可以实现无感升级, 正常来讲, 这个流量分发器是需要知道可以把流量转发到哪些机器上的, 那么在这个机器升级前, 需要通知分发器把自己先从可分发列表中摘除, 摘除成功后, 这台机器就不再会接收请求(可以稍微等一会, 等现有流量完全跑完), 机器就可以重启升级了, 升级成功后再把自己放回去.

这里如果继续问, 一般就会问到这个通知机制要用什么实现, 然后如果答 zk, 一般除了再问一些 zk 的问题, 还会问 zk 有什么缺点, 有没有什么别的方案等等.

这里还可以问这个分发器的容灾, 可用性保障, 性能, 不同版本兼容等等东西是怎么做的. 比如问你 tb 流量这么大, 分发器岂不是要承载特别大的流量, 怎么考虑和设计等等, 总之这里面是有一整套解决方案的, 每个点都可以问好多东西


如果要深入了解, 可以全套学习一下分布式 RPC 服务后端一整套的东西 (极客时间有, 入门还可以, 不是广告

分布式 HTTP 是啥？？按我理解不应该是 cdn 、负载均衡这些吗

k8s 的更新策略

@Jooooooooo 感谢老哥的回复， 我也是看到这个面试题， 一脸蒙蔽，不是很明白分布式 http 服务， 可能就是问得是 zk 这种方向

这不是 nginx reload 一下就解决的场景吗

基本这种平滑升级的思路都是，开始升级后把流量全部打到新机器上，等老机器上的流量全部处理完后就可以杀掉升级完成了。