像某宝、狗东这样的网站怎么发布（更新）项目的

[leeton]

像某宝、狗东这样的网站怎么发布（更新）项目的，平时也没见过他们提示系统升级中 稍后访问之类的

[firefox12]

负载均衡就是 nginx + upstream 吗？。 有更好一点的方案吗？

[cominghome]

@firefox12 核心思路和 nginx + upstream 差不多，但是各家多多少少都会有自己二次开发的产品

[lynan]

有在半夜 12 点的时候遇见狗东过几次接口超时，报错
当时在想哈哈哈被我逮到了把，偷偷更新

[null2018]

很简单啊，先从域名下摘一台机器，然后发布到机器上，测试在这台机器回归，没问题的话，摘机器，发布，挂机器，再摘再挂，或者晚上到凌晨再上线，最主要的话是发布其实没你想象那么慢

[knightdf]

类似灰度发布？

[opengps]

可以去了解下阿里云的弹性伸缩 ESS 服务： https://help.aliyun.com/product/25855.html?source=5176.11533457&userCode=ta5rjs45&type=copy

[zc1249274251]

多轮测试，备份、灰度发布 当然后边还有一些数据同步

[owenliang]

灰度部署几台不就好了嘛

[azh7138m]

@lynan 半夜可能不是更新，可能是线上压测，故障演练

[maichael]

滚动、灰度、蓝绿，只要设计良好，不停服更新不会很难。

[LudwigWS]

太复杂了

[dizun]

摘下一部分更新好再挂上呗。这种商城类的支付应该是单独的接口，所以灰度只要保证接口兼容性就没问题了。

[tingfang]

滚动发布，新旧版本共存。发布不难，难的是开发要考虑新旧版本兼容，数据迁移，数据兼容等。老版本只修 bug，不改功能，所有新功能都要提供新版本接口。

[zhgg0]

@lynan 大厂一般不会在半夜发布的，半夜发布出问题了，如果解决问题有可能很多人不在比较麻烦，所以都选择在白天发布，你说的半夜遇到超时问题，可能是压测导致的，压测一般下半夜开始。

大厂机器都很多，负载均衡机器加上探测应用机器是不是活的这种功能，就能解决发布时不影响功能的问题了。

[alexsunxl]

核心思路基本都是注册中心+upstream 。
比如说 100 台机器（实例）串行 10%更新， 对 1-10 做更新，同时把这 10%摘出来，不打流量进去。
更新完成后打流量，看监控一下，看下拨测，看下告警和日志，没问题就到下一组 11-20 。有问题就回滚，取消整个发布，解决了重新再来。

整个发布过程要做到可观测，可监控，可回滚。

[Auster]

分批部署

[MinQ]

@zhgg0 我司都是半夜发，第二天回家睡觉……

[leeton]

@lynan 优秀

[monkeyWie]

k8s 滚动升级就完事

[zhilincom]

应用部署能理解，我想知道他们数据库是如何更新的？就是修改表结构的操作。