小弟新去了一家互联网公司,每两周上线一次,每次都要凌晨发新的包,每次都要陪着通宵,总这样感觉身体要跨,想研究下怎么能白天发包然后热部署呢,公司现在已经是初步的分布式+集群 几十台服务器 几十个服务相互调用
1
kanchi240 2016-09-20 16:20:49 +08:00
灰度
|
2
renshuxian OP @kanchi240 大哥能在详细说说么
|
3
LMkillme 2016-09-20 16:25:05 +08:00
其实蛮享受以前凌晨更新的时候,两三个人半夜在办公室吃烧烤,啤酒,音乐,看看足球,吹求打屁
|
4
renshuxian OP @LMkillme 那是建立在没出问题的情况下呀,可以看看电影,要是出问题了,后半夜写代码的感觉可不好
|
5
clarkyi 2016-09-20 16:30:06 +08:00
我们以前也是这种状态,不过现在切换了方式,用 jenkins 先把程序打好包,再用 rundeck 来发布到线上。虽然没有命令的方式方便,但是最起码不用半夜上线了
|
6
LMkillme 2016-09-20 16:30:16 +08:00
@renshuxian 测试做好来。
|
7
renshuxian OP @clarkyi 我们也是 jenkins 但是如果如您说的用 rundeck 他会不影响生产的用户的使用么 比如我们的订单有 8 台集群,他能保证发布的时候不出问题么
|
8
renshuxian OP @LMkillme 测试肯定是要的 但是很多环境只有生产有,只能最后才能测,很尴尬
|
9
clarkyi 2016-09-20 16:39:41 +08:00
@renshuxian 你手动发布的时候能保证发布不出问题么?
这个跟你手动发布是一个道理,只是把命令什么的都统一起来了而已,再者发布的时候可以先发布一台机器暂且叫预发布机,环境跟线上完全一致,只是不对外开放访问。当你确认这一台机器跑起来是正常的再一次发布到外网。 当然像你说的订单系统对数据一致性要求高的,肯定是要找一个访问量低的时间段来更新的。或者有对应的机制来处理正则处理的订单这都是外话了。 |
10
renshuxian OP @clarkyi 感谢,那我懂了 还是要晚上上
|
11
darkfireworld 2016-09-20 18:49:46 +08:00 via Android
核心业务无法中断的,那就只能晚上了。
|
12
renshuxian OP @darkfireworld 主要是想理解下那些大公司到底用了什么黑科技实现的热部署
|
13
dgsrz 2016-09-20 20:10:15 +08:00
预发布+分批次发布线上,也没啥黑科技的……除了核心应用或数据库变更需要放在业务低峰期
|
14
owt5008137 2016-09-20 20:13:06 +08:00 via Android
把生产环境的数据定期导到开发环境测啊。
生产环境部署可以试试采用 AB 组,更新前是 A 组,更新后是 B 组,切换环境就是路由切过去就行了。然后正式切换前先灰度一部分用户做预发布,如果预发布没问题了全部切 B 。就完了 |
15
ri0day 2016-09-20 20:56:06 +08:00
楼上是对的。 2 组 ,先拿下来一组。发代码上去,测试。测试完了 放上去给外面使用。再弄第二组。第二组发完了,测试好了,就也放上去。
|
16
renshuxian OP @dgsrz 嗯我们现在也是这样 开发环境 测试环境 预发布 生产 就是纠结 生产一定要晚上上
|
17
renshuxian OP @owt5008137 但是切 B 的过程中 客户的使用会造成影响吧
|
18
renshuxian OP @ri0day 还是刚才的问题 比如 8 台的负载 如果分两批上线,前端只有 4 台工作压力可能会很大
|
19
xiaogui 2016-09-20 22:10:08 +08:00
晚上受影响的用户相对会比较少,出问题有更多的时间解决。但是另一方面晚上易疲惫,所以有的时候反而容易范二。
|
20
ywgx 2016-09-20 22:23:05 +08:00
信不信 来 xabcloud.com 给你完美解决方案
|
22
renshuxian OP @xiaogui 就是呀,很困的 12 点才切生产出点问题一宿就没法睡觉了,都有点想离职了,两周同一次宵
|
23
renshuxian OP @ywgx 要花多少钱
|
24
Jakesoft 2016-09-20 22:44:29 +08:00
@ywgx 请问 community.xabcloud.com 这个社区站点使用的什么后台 /前端技术?感觉挺神奇的,所有的页面竟然都是请求的接口,然后这个社区看着简单,我注册了一下,内部还是比较复杂的。
|
25
boywang004 2016-09-20 22:51:04 +08:00
本厂刚从一天两次改为一天一次……飘过。
|
26
renshuxian OP @boywang004 围观架构师,看来大神已经习惯上线的感觉了
|
27
xiaogui 2016-09-20 23:26:22 +08:00
@renshuxian 听起来好像不是很经常,哈哈
|
28
axb 2016-09-21 00:04:43 +08:00
每天上线十几次,每次上线就是点个按钮,从来不在晚上上线……
编译型程序: 1. 滚动上线,按一定步长批量执行 2. 固定运行时环境+热部署,例子可以参考阿里放出的资料 解释型程序: git pull 或者类似的姿势 |
29
dgsrz 2016-09-21 01:36:25 +08:00
@renshuxian 独立一个接入层出来,应用上下线的时候只要增删接入层路由规则就好了,避免客户端直连后端应用。另外控制好每批次的机器数量,发布流程及回滚方案,基本不会有问题的
|
30
huntzhan 2016-09-21 01:47:03 +08:00
搞持续交付,测试用例过了自动上线。不过做这一套对基础设施的要求比较高,包括整一套的 DevOps + 监控,数据指标除了问题要能自动回滚,还有就是你们的架构可能也要重新考虑。
|
31
neoblackcap 2016-09-21 02:21:23 +08:00
互联网公司居然 2 周才更新一次!!!做好热升级的设计,不是大的改表不用深夜上啊。
当然要狠的话,那么先用缓存层挡住数据,然后更新持久化层, |
32
ywgx 2016-09-21 07:26:29 +08:00 via iPhone
@renshuxian 阿里云市场已经上架 一个月 1000 左右
|
34
owt5008137 2016-09-21 08:20:43 +08:00 via Android
本来灰度就是先对一部分造成影响来看是否有问题啊
|
35
chocotan 2016-09-21 08:46:10 +08:00
唉。。我们公司没有单元测试,没有灰度,一天能发布 n 次
|
36
matrix67 2016-09-21 08:47:34 +08:00 via Android
不是 ha 后面挂个两个,先搞一个,跑借口测试,再搞一个额
|
37
renshuxian OP @axb 好的去研究下
|
38
renshuxian OP @dgsrz 好像很复杂先谢过
|
39
renshuxian OP @huntzhan 这个感觉要把项目删了重写才行的样子
|
40
renshuxian OP @neoblackcap 我们做 B2B 每天都有好多订单,就晚上用的人少
|
41
renshuxian OP @ywgx 阿里云真的比自己买服务器雇运维强么
|
42
renshuxian OP @owt5008137 好的 研究下
|
43
renshuxian OP @chocotan 那不是要搞死人
|
44
renshuxian OP @matrix67 有 ha 负载但是还是要晚上上 - -
|
45
sujin190 2016-09-21 09:08:48 +08:00 1
互联网公司连简单的灰度发布都没有么。。多搞一台机器,先发到那台机器,然后指定某些用户访问那台机器测试, ok 的话全量更新,这种不应该有问题啊,否则就是你们测试过程太随便了
|
46
ywgx 2016-09-21 09:16:53 +08:00
@renshuxian 这个没法对比,总之云上 就是 花钱省时间省事,快; 而 云的稳定性 不要过度依赖, 什么时候 支付宝,天猫,淘宝 90%的业务都在 阿里云了, 那个时候就差不多了
|
48
ywgx 2016-09-21 09:17:52 +08:00
@renshuxian 要不 微信联系 rubycoding ,用不用 无所谓,或许可以解决你的问题呢
|
49
ma125125t 2016-09-21 09:36:12 +08:00
这就受不了?我们平均一天发布一点五次。。
|
50
kideny 2016-09-21 09:37:48 +08:00
study
|
51
sujin190 2016-09-21 09:37:53 +08:00
@xi_lin 一般来说绝大部分上线都是不用修改数据结构的,在需要修改数据接口的上线中,又有很大部分是新加功能,这种情况来说不用等到凌晨啊,再者分开业务上线,控制影响范围才是啊
|
54
diggzhang 2016-09-21 13:35:37 +08:00
原来有相同工作场景啊!深夜上线麻烦多 == 新系统 /架构上线麻烦多。每次看到后端同事熬夜 debug ,简直英雄惜英雄。
目前了解到的优解办法是构建预发布系统: 主流的有 gor ,去录制流量,回放流量。 还有网易的 tcpcopy ,流量请求生成环境同时,复制一份到测试环境。然后相同思路,稍微好用一些的还有 duplicator 。 用真实流量去测试将要发布的系统,让问题尽早暴露。 |
55
renshuxian OP @ywgx 这个要和领导请示下 毕竟已经买了很多很贵的服务器了
|
56
renshuxian OP @sujin190 我们预发布的环境就是最新的 war 包然后是生产的数据库,测通过了才会切生产,但是切过去还是会有莫名其妙的问题 - -
|
57
renshuxian OP @ma125125t 五次都是在白天 不可怕,都是晚上那不是要搞死
|
58
renshuxian OP @diggzhang 预发布有的,就是测通过了还是要晚上上,这个是最根本的问题,晚上困那,改 bug 很费力
|
59
wangzhangwei 2016-09-21 14:08:46 +08:00
招人吧,轮班。
|
60
ywgx 2016-09-21 18:39:09 +08:00
@renshuxian 是的,这个非常理解, 不过讲真,这个成本很低,只会让你们更省钱,可以按量试用一周,好不好很快就明白
|
61
winglight2016 2016-09-22 09:46:10 +08:00
我们也有同样问题,理论上灰度发布是可以解决问题的,实际上无法解决业务流程变更太大,完全不兼容以前以前的 API ,这种时候必须前后端一起切换——只能放在晚上发布了
|
62
darkfireworld 2017-02-06 00:44:55 +08:00 via iPhone
@renshuxian 这样说吧,灰度发布,假设线上有一个 vm1 跑 v1 版本,要上线 v2 版本,首先,部署 v2 到 vm2 上,然后,前端 nginx 按照一定规则(比如说, ip 段)将一部分流量引入 v2 中,然后,满满增大比例即可。
楼上,也提到了数据库变更的问题,这个问题比较棘手,需要保证 v1 版本服务的 sql 和 v2 不冲突 |