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

• 資深大佬 : pc10201

  滚动升级啊

• 資深大佬 : crclz

  （瞎猜的） api 保留历史的一些版本；服务端一次升级一台，一台升级完了再升级下一台。（这样服务能力保留为原来的 N-1/N ）

• 資深大佬 : chaleaoch

  应该和王者荣耀的不停机更新一个道理 不过 不停机更新是如何实现的我不清楚(狗头.jpg)

• 資深大佬 : MinQ

  @chaleaoch 滚动发布，先将几台机器从集群中隔离，将流量打到其它机器上。然后升级隔离的机器，进行发布和验证，验证通过后将流量接回。然后循环这个过程，直到集群中所有机器都升级完毕

• 資深大佬 : huihui0615

  @chaleaoch 热更新嘛

• 資深大佬 : PopRain

  我只是好奇，为啥不是“狗宝” ？

• 主 資深大佬 : leeton

  @PopRain 因为京东的头像是狗头啊

• 資深大佬 : wellsc

  devops

• 資深大佬 : LifStge

  @leeton 我在想 他的意思是不是 把两个词直接合并呢 = = 哈哈

• 資深大佬 : Jooooooooo

  都是集群

  发布就是先把比如 10% 的机器摘掉, 然后上新版本, 发起来了再放回去, 然后这么发 10 次新版本就上线了

  这里一般要注意兼容性的问题, 因为是新旧版本同时在线上可以被访问到

• 資深大佬 : coldmonkeybit

  像这样？ https://aws.amazon.com/cn/blogs/china/performing-bluegreen-deployments-with-aws-codedeploy-and-auto-scaling-groups/

• 資深大佬 : syhily

  研发三板斧做好，想怎么发就怎么发。

• 資深大佬 : yolee599

  用两台以上服务器，升级这一台的时候流量全部转到另外的服务器，以此类推

• 資深大佬 : zealinux

  @syhily 哪三板斧？

• 資深大佬 : jmk92

  有负载均衡就能实现，一台机器也无妨，也用它的镜像生成一台临时的机器，加入负载均衡，把流量都切到新的上面，
  更新之前的机器，更新完了之后，流量再切回来，释放新实例

• 資深大佬 : liujan

  分批发布，先发布一批，没问题再发布另外一批

• 資深大佬 : adoula

  你们说的都是负载均衡之类的吧，如果数据库字段有删减，改怎么搞？

• 資深大佬 : MinQ

  @adoula 为了保证兼容性一般都是加，非得搞就得准备新的库和表，然后用不同版本的接口做划分

• 資深大佬 : oscer

  负载均衡啊，无感知更新

• 資深大佬 : oscer

  @adoula 有缓存啊，全部更完之后，清除掉缓存就行了

• 資深大佬 : 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

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

• 資深大佬 : pkoukk

  @zhilincom 个人理解应该是靠中间件，应用服务不直连数据库

• 資深大佬 : killergun

  版本控制
  不是所有服务器一下更新，而是逐步更新