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