我们现在用的还是 在阿里云， 复制粘贴 tomcat （ war 包），nohu国外服务器p 启动 jar，用的是 spring cloud，多台服务器起多个同服务。 用户每天活跃也有一定量了。 遇到更新时，我们只能粗暴的选择人少的时候更新。一般是夜间。。很累。

论坛里也看了些帖子，https://www.v2ex.com/t/705776 像某宝、狗东这样的网站怎么发布（更新）项目的； https://www.v2ex.com/t/694561 线上服务要咋切换版本才不会影响用户？

（没有用过，感觉很高端..我们很多东西都没有） 想请教下大佬，我们这种 /类似的 该怎么做

架构好就可以。
比如：
前面负载分配器，后面新旧服务都起来，直接修改规则到新的，然后逐渐停机旧的

PS 不是让你们这么做，随便想想就有很多方法

本质上应该都是用负载均衡切流量，具体有很多做法
最简单粗暴的可能是脚本切换 nginx 配置切流量

做好版本兼容，就可以滚动部署，逐台下线，部署，再上线。
版本不兼容的，用 tcpcopy 之类的工具复制流量测试新版本，然后下线一台，部署完成上线的同时下线其他所有机器，然后逐台部署上线恢复

k8s

用阿里云的负载均衡，切流量 , 滚动更新

简单点, 就 nginx upstream 切流量

蓝绿发布，前面挂一个负载均衡器就行了，可以用 nginx，也可以直接购买阿里云的 LBS

我之前还没想到单机复制两个 tomcat 然后用 nginx 作负载均衡意义是啥，甚至吐槽 “单机负载均衡？！”
之后才意识到负载均衡可以拿来作不停机更新。

你没有不停机更新的需求呀，那就写个脚本，定时在夜里跑不就好了。。。
应用软件，哪儿有什么高端的东西，都是商业词忽悠人的～

上 docker stack 就自带不停机更新了 配上 CI 可以自动部署

简单：阿里云的负载均衡用起来，然后一台一台的更新

主流方案就是先切流量再部署的滚动部署方案，常见的就是 nginx 的 upstream 修改，以及 k8s 的 dns 服务发现。

infra 和整体架构的问题，不是单纯的运维问题。做好高可用后对集群划分，设计自动化灰度等系统

蓝绿发布。

我觉得你们需要招一些合格的运维了（

用的 k8s，CI/CD 自动化部署，代码合并后自动打包成镜像上传到阿里云的镜像库，然后告知生产环境拉取镜像，切换版本。

部署一套成熟的 DevOps，甚至能学到更多东西

+1024 专门人做专门的事

rancher 金丝雀发布

阿里云 有个 云效，里面有个流水线可以帮你解决人肉发布…
前面挂个阿里云的 负载均衡服务，经典型就行。
感觉应该够你用了，不需要对你应用进行容器化。

k8s

不修改 nginx upstream,直接重启服务会有什么坏的结果？

你的服务启动不要时间的吗, 如果这个时候有用户来, 你怎么处理

k8s

有些时候停机发布更好，比如上次中币交易所热部署出事了，客户都以为他们跑路了，过了好多天才恢复，数据都回滚了，损失惨重。

明白了，难怪我总感觉没用，因为我写的是小程序，一个进程启动不需要 1S 中，难怪总感觉不需要移除那个进程

nginx upstream 修改，ansible 有什么脚本没有？

小公司控制成本嘛！运维需求

上面所有方案的前提是新旧版本可以兼容，瞬间切。如果要改数据库字段，还是停机靠谱

用的什么系统？我一般用 linux 操作系统
最基础的就是 pssh+superviserd+shell=你的需求轻松实现
方案一、
采用发版方法是： shell 脚本+expect 交互式+superviserd 实现。
具体：shell 脚本+expect 批量上传同步
superviserd 控制 jar 或者 tomcat 后台管理程序
方案二、可以在上述基础上改进 saltstack 或者采用 jenkins 发版。
方案三、再高级一点就是 k8s + jenkins

数据库字段可以随便改? 一般搞了就不改的吧

我们有套小系统，对接了阿里云负载均衡 api，设置虚拟组；自动切换，点一点就行很是方便
简单点先虚拟组 A 对外（老版本），更新虚拟 B （新版本），虚拟 B 测试确定；虚拟 B 对外，更新 A，测试确定

简单点弄个负载均衡，应该别搞太复杂，太复杂了维护也烦
gitlab runner 也很方便。

hook build 替换 k8s 镜像源

不用 ansible+supervisord ？

加了需求总要加字段的吧

开始用 serverless 吧，只要代码提交到 github，云会自动帮你部署。部署完成后会自动切换到新代码。

《 Kubernetes 微服务实战》- 吉吉·赛凡，我简单看了下目录（确实没用到这些），感觉挺适合你这种情况的。
灰度发布，金丝雀发布什么的，都有说。

对小规模公司推 k8s ？我缓缓打出个…？
lz 看样子需求很小。业务规模不大，非常简单。阿里云负载均衡按道理肯定用了。本质上不停机都是围绕这个来的。要复杂可以复杂。要简单可以简单。
不是负载均衡本身能这样。要做一些工作的。我的 v0.1 版自动部署就非常简单。我的例子适用 lz 。我到这家公司的时候启动模式也是 nohup 。更新模式跟你一摸一样。
我做的第一件事是不要手动去 nohup 启动。先不考虑滚动更新。这是一件很简单的事，1-2 个工作日就改造玩完了。jenkins 一个 job 的事。
第二件事，开始考虑挂了拉起来。既然这样。我换个思路，系统启动要做到自动拉当前的 jar 包。启动。这也很简单，程序启动本来就有逻辑了。只要解决在系统启动得时候如何拉包的问题就解决了。
第三件事，滚动更新。我是 aws，研究一下负载均衡和弹性伸缩。
首先负载均衡会自动检查节点是否健康，如果不健康，摘除并且关闭节点，其次，弹性伸缩会保护一定要到一个数额。那这个问题就简单了。因为第一件和第二件事我已经做了，只要配置好了弹性伸缩和负载均衡。效果就出来了。那如何滚动更新讷？一台一台关掉就是了，关一台检查是否启动成功，再关下一台。其他都不用考虑。到此，负载均衡和弹性伸缩就都 work 了…接下来就是要解决日志的问题…
顺便说一下…我们有 80+微服务。这套逻辑跑了小半年，最后当然我可以踏踏实实的切刀 k8s 里。废话…200 多实例多浪费钱啊…

jenkins 一个 job 里面，先 build 好镜像推送到仓库，然后挨个通过 ssh 执行 docker run 。控制好时间间隔，保证在前一个服务可用后再去更新下一个就行了。还 k8s 、负载均衡，搞辣么复杂做咩？

Jenkins 自由风格啊

蓝绿部署或者滚动发布。
但是重点不在部署。部署完成后配套的可靠的自动化测试以及有效的心跳检测才是上面方案有效的关键。

问一下楼上说用阿里云负载均衡，不停机，滚动部署的，怎么做版本测试？会不会影响正常用户的使用？

运维也问怎么做，运维默认会这个吗

nginx 切流量

我们公司的 ansible 脚本是自己写的，没有开源

不开心

我以前还调研了另一种适合小公司的部署方案，如下图所示

我以前还调研了另一种适合小公司的部署方案，如下图所示
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 节点

各人习惯，我不太精通 ansible，所以未写。

阿里云云效有个主机分批发布的功能可能对你有帮助 https://thoughts.aliyun.com/sharespace/5e86a419546fd9001aee81f2/docs/5e86a416546fd9001aee81b8k8..