这是一个创建于 3012 天前的主题，其中的信息可能已经有所发展或是发生改变。
小弟新去了一家互联网公司，每两周上线一次，每次都要凌晨发新的包，每次都要陪着通宵，总这样感觉身体要跨，想研究下怎么能白天发包然后热部署呢，公司现在已经是初步的分布式+集群 几十台服务器 几十个服务相互调用
 |
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  1
@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 不冲突 |
Select Language