这是一个创建于 1752 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 realpg PRO  1 架构好就可以。 比如： 前面负载分配器，后面新旧服务都起来，直接修改规则到新的，然后逐渐停机旧的 |
| 2 realpg PRO PS 不是让你们这么做，随便想想就有很多方法 |
 | 3 chendy 2021-03-05 15:17:02 +08:00 1 本质上应该都是用负载均衡切流量，具体有很多做法 最简单粗暴的可能是脚本切换 nginx 配置切流量 |
 | 4 eason1874 2021-03-05 15:24:07 +08:00 1 做好版本兼容，就可以滚动部署，逐台下线，部署，再上线。 版本不兼容的，用 tcpcopy 之类的工具复制流量测试新版本，然后下线一台，部署完成上线的同时下线其他所有机器，然后逐台部署上线恢复 |
 | 5 pathbox 2021-03-05 15:32:16 +08:00 via iPhone 2 k8s |
 | 6 justseemre 2021-03-05 15:34:12 +08:00 1  用阿里云的负载均衡，切流量 , 滚动更新 |
 | 7 zhuweiyou 2021-03-05 15:34:15 +08:00 1 简单点, 就 nginx upstream 切流量 |
 | 8 keepeye 2021-03-05 15:34:50 +08:00 1 蓝绿发布，前面挂一个负载均衡器就行了，可以用 nginx，也可以直接购买阿里云的 LBS |
 | 9 no1xsyzy 2021-03-05 15:35:22 +08:00 1 我之前还没想到单机复制两个 tomcat 然后用 nginx 作负载均衡意义是啥，甚至吐槽 “单机负载均衡？！” 之后才意识到负载均衡可以拿来作不停机更新。 |
 | 10 wzb0909 2021-03-05 15:37:36 +08:00 1 你没有不停机更新的需求呀，那就写个脚本，定时在夜里跑不就好了。。。 应用软件，哪儿有什么高端的东西，都是商业词忽悠人的～ |
 | 11 106npo 2021-03-05 15:45:03 +08:00 via Android 2 上 docker stack 就自带不停机更新了 配上 CI 可以自动部署 |
 | 12 walker2laok 2021-03-05 16:07:23 +08:00 1 简单：阿里云的负载均衡用起来，然后一台一台的更新 |
 | 13 wakzz 2021-03-05 16:12:23 +08:00 1 主流方案就是先切流量再部署的滚动部署方案，常见的就是 nginx 的 upstream 修改，以及 k8s 的 dns 服务发现。 |
 | 14 DoctorCat 2021-03-05 16:14:09 +08:00 1 infra 和整体架构的问题，不是单纯的运维问题。做好高可用后对集群划分，设计自动化灰度等系统 |
 | 15 mensa23 2021-03-05 16:24:09 +08:00 1 蓝绿发布。 |
 | 16 xarthur 2021-03-05 16:26:21 +08:00 via iPhone 1 我觉得你们需要招一些合格的运维了（ |
 | 17 clf 2021-03-05 16:35:19 +08:00 1 用的 k8s，CI/CD 自动化部署，代码合并后自动打包成镜像上传到阿里云的镜像库，然后告知生产环境拉取镜像，切换版本。 |
 | 18 litel 2021-03-05 16:35:32 +08:00 部署一套成熟的 DevOps，甚至能学到更多东西 |
 | 20 py88pQ2hZ7PJw0v4 2021-03-05 16:41:14 +08:00 1 rancher 金丝雀发布 |
 | 21 519718366 2021-03-05 16:45:11 +08:00 via iPhone 1 阿里云 有个 云效，里面有个流水线可以帮你解决人肉发布… 前面挂个阿里云的 负载均衡服务，经典型就行。 感觉应该够你用了，不需要对你应用进行容器化。 |
 | 22 coderxy 2021-03-05 17:00:58 +08:00 k8s |
 | 23 simple2025 2021-03-05 17:02:51 +08:00 @zhuweiyou 不修改 nginx upstream,直接重启服务会有什么坏的结果？ |
 | 25 jxlwqq 2021-03-05 17:09:59 +08:00 k8s |
 | 26 redtea 2021-03-05 17:13:54 +08:00 有些时候停机发布更好，比如上次中币交易所热部署出事了，客户都以为他们跑路了，过了好多天才恢复，数据都回滚了，损失惨重。 |
| 27 simple2025 2021-03-05 17:24:01 +08:00 @zhuweiyou 明白了，难怪我总感觉没用，因为我写的是小程序，一个进程启动不需要 1S 中，难怪总感觉不需要移除那个进程 |
| 28 simple2025 2021-03-05 17:36:11 +08:00 @wakzz nginx upstream 修改，ansible 有什么脚本没有？ |
 | 29 Lemeng 2021-03-05 17:39:50 +08:00 小公司控制成本嘛！运维需求 |
 | 30 chairuosen 2021-03-05 17:41:01 +08:00 上面所有方案的前提是新旧版本可以兼容，瞬间切。如果要改数据库字段，还是停机靠谱 |
 | 31 ward56 2021-03-05 17:54:30 +08:00 1 用的什么系统？我一般用 linux 操作系统 最基础的就是 pssh+superviserd+shell=你的需求轻松实现 方案一、 采用发版方法是： shell 脚本+expect 交互式+superviserd 实现。 具体：shell 脚本+expect 批量上传同步 superviserd 控制 jar 或者 tomcat 后台管理程序 方案二、可以在上述基础上改进 saltstack 或者采用 jenkins 发版。 方案三、再高级一点就是 k8s + jenkins |
 | 32 dailiha01sy 2021-03-05 17:55:56 +08:00 @chairuosen 数据库字段可以随便改? 一般搞了就不改的吧 |
 | 33 C603H6r18Q1mSP9N 2021-03-05 18:08:20 +08:00 1 我们有套小系统，对接了阿里云负载均衡 api，设置虚拟组；自动切换，点一点就行很是方便 简单点先虚拟组 A 对外（老版本），更新虚拟 B （新版本），虚拟 B 测试确定；虚拟 B 对外，更新 A，测试确定 |
 | 34 balckjoker 2021-03-05 19:10:17 +08:00 1 简单点弄个负载均衡，应该别搞太复杂，太复杂了维护也烦 gitlab runner 也很方便。 |
 | 35 SjwNo1 2021-03-05 21:54:16 +08:00 hook build 替换 k8s 镜像源 |
| 36 simple2025 2021-03-05 22:49:42 +08:00 @ward56 不用 ansible+supervisord ？ |
| 37 simple2025 2021-03-05 22:50:10 +08:00 @dailiha01sy 加了需求总要加字段的吧 |
 | 38 kaokao123 2021-03-06 00:15:25 +08:00 开始用 serverless 吧，只要代码提交到 github，云会自动帮你部署。部署完成后会自动切换到新代码。 |
 | 39 young1lin 2021-03-06 00:32:04 +08:00 1 《 Kubernetes 微服务实战》- 吉吉赛凡，我简单看了下目录（确实没用到这些），感觉挺适合你这种情况的。 灰度发布，金丝雀发布什么的，都有说。 |
 | 40 sampeng 2021-03-06 01:02:10 +08:00 via iPhone 1 对小规模公司推 k8s ？我缓缓打出个…？ lz 看样子需求很小。业务规模不大，非常简单。阿里云负载均衡按道理肯定用了。本质上不停机都是围绕这个来的。要复杂可以复杂。要简单可以简单。 不是负载均衡本身能这样。要做一些工作的。我的 v0.1 版自动部署就非常简单。我的例子适用 lz 。我到这家公司的时候启动模式也是 nohup 。更新模式跟你一摸一样。 我做的第一件事是不要手动去 nohup 启动。先不考虑滚动更新。这是一件很简单的事，1-2 个工作日就改造玩完了。jenkins 一个 job 的事。 第二件事，开始考虑挂了拉起来。既然这样。我换个思路，系统启动要做到自动拉当前的 jar 包。启动。这也很简单，程序启动本来就有逻辑了。只要解决在系统启动得时候如何拉包的问题就解决了。 第三件事，滚动更新。我是 aws，研究一下负载均衡和弹性伸缩。 首先负载均衡会自动检查节点是否健康，如果不健康，摘除并且关闭节点，其次，弹性伸缩会保护一定要到一个数额。那这个问题就简单了。因为第一件和第二件事我已经做了，只要配置好了弹性伸缩和负载均衡。效果就出来了。那如何滚动更新讷？一台一台关掉就是了，关一台检查是否启动成功，再关下一台。其他都不用考虑。到此，负载均衡和弹性伸缩就都 work 了…接下来就是要解决日志的问题… 顺便说一下…我们有 80+微服务。这套逻辑跑了小半年，最后当然我可以踏踏实实的切刀 k8s 里。废话…200 多实例多浪费钱啊… |
 | 41 xuanbg 2021-03-06 07:57:29 +08:00 1 jenkins 一个 job 里面，先 build 好镜像推送到仓库，然后挨个通过 ssh 执行 docker run 。控制好时间间隔，保证在前一个服务可用后再去更新下一个就行了。还 k8s 、负载均衡，搞辣么复杂做咩？ |
 | 42 rootmaster 2021-03-06 09:12:20 +08:00 Jenkins 自由风格啊 |
 | 43 calmzhu 2021-03-06 10:10:10 +08:00 1 蓝绿部署或者滚动发布。 但是重点不在部署。部署完成后配套的可靠的自动化测试以及有效的心跳检测才是上面方案有效的关键。 |
 | 44 bfme 2021-03-06 10:28:40 +08:00 问一下楼上说用阿里云负载均衡，不停机，滚动部署的，怎么做版本测试？会不会影响正常用户的使用？ |
 | 45 baoshuai33 2021-03-06 11:13:06 +08:00 via iPhone @xarthur 运维也问怎么做，运维默认会这个吗 |
 | 46 notejava 2021-03-06 13:50:28 +08:00 nginx 切流量 |
| 48 simple2025 2021-03-06 14:29:31 +08:00 @ 不开心 |
| 49 wakzz 2021-03-06 14:29:35 +08:00 我以前还调研了另一种适合小公司的部署方案，如下图所示 |
| 50 wakzz 2021-03-06 14:32:31 +08:00 1 我以前还调研了另一种适合小公司的部署方案，如下图所示 https://img.wakzz.cn/202102/pQ8yeTK2if.png 用开源框架 Kong 网关替代 Nginx(Kong 就是对 Nginx 做了一层封装)，然后自行代码开发实现一个节点监听服务，通过对接注册中心的 API 来实时监听各个服务节点的状态。当某服务节点上下线后，注册中心将节点上下线事件推送给监听服务，然后监听服务通过 Kong 的开放 API 修改 Kong 中的 upstream 。 通过上述方案从而实现一个注册中心同时管理微服务之间的服务发现和网关到服务的服务发现。此时应用发布流程例如对某服务的 a 、b 两节点发版时具体逻辑如下： 1. 请求注册中心下线该服务的 a 节点 2. 监听服务监听到 a 节点下线后自动将 Kong 中的 a 节点下线 3. 等待 a 节点无流量请求后发布重启 a 节点的新版本，等待策略简单方案就是等待 1 分钟，复杂点就是监控带宽 4. a 节点启动成功后自动将自己重新注册到注册中心 5. 监听服务监听到 a 节点上线后自动将 Kong 中的 a 节点上线 6. 接着同样的逻辑操作 b 节点 |
 | 52 tq0fqeu 2021-03-19 16:09:23 +08:00 1 阿里云云效有个主机分批发布的功能可能对你有帮助 https://thoughts.aliyun.com/sharespace/5e86a419546fd9001aee81f2/docs/5e86a416546fd9001aee81b8#5e847eca0aba01ecdbc57cd2 不过摘流量的逻辑肯定要在你应用启动脚本里定制的，除非你用 k8.. |
Select Language