像某宝、狗东这样的网站怎么发布(更新)项目的,平时也没见过他们提示系统升级中 稍后访问之类的
1
pc10201 2020-09-10 13:23:05 +08:00
滚动升级啊
|
2
crclz 2020-09-10 13:57:01 +08:00
(瞎猜的) api 保留历史的一些版本;服务端一次升级一台,一台升级完了再升级下一台。(这样服务能力保留为原来的 N-1/N )
|
3
chaleaoch 2020-09-10 14:01:32 +08:00
应该和王者荣耀的不停机更新一个道理 不过 不停机更新是如何实现的我不清楚(狗头.jpg)
|
4
MinQ 2020-09-10 14:07:14 +08:00 5
@chaleaoch 滚动发布,先将几台机器从集群中隔离,将流量打到其它机器上。然后升级隔离的机器,进行发布和验证,验证通过后将流量接回。然后循环这个过程,直到集群中所有机器都升级完毕
|
5
huihui0615 2020-09-10 14:08:00 +08:00
@chaleaoch 热更新嘛
|
6
PopRain 2020-09-10 14:29:20 +08:00 1
我只是好奇,为啥不是“狗宝” ?
|
8
wellsc 2020-09-10 14:37:33 +08:00
devops
|
10
Jooooooooo 2020-09-10 14:45:22 +08:00
都是集群
发布就是先把比如 10% 的机器摘掉, 然后上新版本, 发起来了再放回去, 然后这么发 10 次新版本就上线了 这里一般要注意兼容性的问题, 因为是新旧版本同时在线上可以被访问到 |
11
coldmonkeybit 2020-09-10 14:45:26 +08:00
|
12
ewBuyVmLZMZE 2020-09-10 15:00:18 +08:00
研发三板斧做好,想怎么发就怎么发。
|
13
yolee599 2020-09-10 15:09:44 +08:00
用两台以上服务器,升级这一台的时候流量全部转到另外的服务器,以此类推
|
15
jmk92 2020-09-10 15:50:07 +08:00
有负载均衡就能实现,一台机器也无妨,也用它的镜像生成一台临时的机器,加入负载均衡,把流量都切到新的上面,
更新之前的机器,更新完了之后,流量再切回来,释放新实例 |
16
liujan 2020-09-10 15:50:40 +08:00 via iPhone
分批发布,先发布一批,没问题再发布另外一批
|
17
adoula 2020-09-10 15:53:06 +08:00
你们说的都是负载均衡之类的吧,如果数据库字段有删减,改怎么搞?
|
19
oscer 2020-09-10 16:41:53 +08:00
负载均衡啊,无感知更新
|
21
firefox12 2020-09-10 16:54:08 +08:00
负载均衡就是 nginx + upstream 吗?。 有更好一点的方案吗?
|
22
cominghome 2020-09-10 16:59:20 +08:00
@firefox12 核心思路和 nginx + upstream 差不多,但是各家多多少少都会有自己二次开发的产品
|
23
lynan 2020-09-10 17:14:37 +08:00
有在半夜 12 点的时候遇见狗东过几次接口超时,报错
当时在想哈哈哈被我逮到了把,偷偷更新 |
24
null2018 2020-09-10 17:15:32 +08:00
很简单啊,先从域名下摘一台机器,然后发布到机器上,测试在这台机器回归,没问题的话,摘机器,发布,挂机器,再摘再挂,或者晚上到凌晨再上线,最主要的话是发布其实没你想象那么慢
|
25
knightdf 2020-09-10 17:18:55 +08:00
类似灰度发布?
|
26
opengps 2020-09-10 17:21:30 +08:00
可以去了解下阿里云的弹性伸缩 ESS 服务: https://help.aliyun.com/product/25855.html?source=5176.11533457&userCode=ta5rjs45&type=copy
|
27
zc1249274251 2020-09-10 17:27:41 +08:00
多轮测试,备份、灰度发布 当然后边还有一些数据同步
|
28
owenliang 2020-09-10 17:49:04 +08:00
灰度部署几台不就好了嘛
|
30
maichael 2020-09-10 19:16:04 +08:00
滚动、灰度、蓝绿,只要设计良好,不停服更新不会很难。
|
31
LudwigWS 2020-09-10 20:32:35 +08:00
太复杂了
|
32
dizun 2020-09-10 20:53:13 +08:00 via Android
摘下一部分更新好再挂上呗。这种商城类的支付应该是单独的接口,所以灰度只要保证接口兼容性就没问题了。
|
33
tingfang 2020-09-10 22:07:04 +08:00
滚动发布,新旧版本共存。发布不难,难的是开发要考虑新旧版本兼容,数据迁移,数据兼容等。老版本只修 bug,不改功能,所有新功能都要提供新版本接口。
|
34
zhgg0 2020-09-10 22:54:09 +08:00
@lynan 大厂一般不会在半夜发布的,半夜发布出问题了,如果解决问题有可能很多人不在比较麻烦,所以都选择在白天发布,你说的半夜遇到超时问题,可能是压测导致的,压测一般下半夜开始。
大厂机器都很多,负载均衡机器加上探测应用机器是不是活的这种功能,就能解决发布时不影响功能的问题了。 |
35
alexsunxl 2020-09-10 23:03:51 +08:00
核心思路基本都是注册中心+upstream 。
比如说 100 台机器(实例)串行 10%更新, 对 1-10 做更新,同时把这 10%摘出来,不打流量进去。 更新完成后打流量,看监控一下,看下拨测,看下告警和日志,没问题就到下一组 11-20 。有问题就回滚,取消整个发布,解决了重新再来。 整个发布过程要做到可观测,可监控,可回滚。 |
36
Auster 2020-09-10 23:34:51 +08:00 via iPhone
分批部署
|
39
monkeyWie 2020-09-11 07:35:26 +08:00 via Android
k8s 滚动升级就完事
|
40
zhilincom 2020-09-11 08:13:47 +08:00 via Android
应用部署能理解,我想知道他们数据库是如何更新的?就是修改表结构的操作。
|
42
killergun 2020-09-11 10:47:12 +08:00
版本控制
不是所有服务器一下更新,而是逐步更新 |
43
dbpe 2021-03-01 14:31:00 +08:00
我很好奇..数据是如何做到滚动发布的....
|
44
dbpe 2021-03-01 14:32:05 +08:00
先 Copy 一个表,然后新的表结构改掉,然后数据库中间件进行新老表双写?没问题了..就切换到过去..有问题就回滚?
|