我们现在用的还是 在阿里云， 复制粘贴 tomcat （ war 包），nohup 启动 jar，用的是 spring cloud，多台服务器起多个同服务。 用户每天活跃也有一定量了。 遇到更新时，我们只能粗暴的选择人少的时候更新。一般是夜间。。很累。
论坛里也看了些帖子，https://www.v2ex.com/t/705776 像某宝、狗东这样的网站怎么发布（更新）项目的； https://www.v2ex.com/t/694561 线上服务要咋切换版本才不会影响用户？
（没有用过，感觉很高端..我们很多东西都没有） 想请教下大佬，我们这种 /类似的 该怎么做
版本不兼容的，用 tcpcopy 之类的工具复制流量测试新版本，然后下线一台，部署完成上线的同时下线其他所有机器，然后逐台部署上线恢复
用阿里云的负载均衡，切流量 , 滚动更新 应用软件，哪儿有什么高端的东西，都是商业词忽悠人的～
前面挂个阿里云的 负载均衡服务，经典型就行。
感觉应该够你用了，不需要对你应用进行容器化。
方案一、
采用发版方法是： shell 脚本+expect 交互式+superviserd 实现。
具体：shell 脚本+expect 批量上传同步
superviserd 控制 jar 或者 tomcat 后台管理程序
方案二、可以在上述基础上改进 saltstack 或者采用 jenkins 发版。
方案三、再高级一点就是 k8s + jenkins
不是负载均衡本身能这样。要做一些工作的。我的 v0.1 版自动部署就非常简单。我的例子适用 lz 。我到这家公司的时候启动模式也是 nohup 。更新模式跟你一摸一样。
我做的第一件事是不要手动去 nohup 启动。先不考虑滚动更新。这是一件很简单的事，1-2 个工作日就改造玩完了。jenkins 一个 job 的事。
第二件事，开始考虑挂了拉起来。既然这样。我换个思路，系统启动要做到自动拉当前的 jar 包。启动。这也很简单，程序启动本来就有逻辑了。只要解决在系统启动得时候如何拉包的问题就解决了。
第三件事，滚动更新。我是 aws，研究一下负载均衡和弹性伸缩。
首先负载均衡会自动检查节点是否健康，如果不健康，摘除并且关闭节点，其次，弹性伸缩会保护一定要到一个数额。那这个问题就简单了。因为第一件和第二件事我已经做了，只要配置好了弹性伸缩和负载均衡。效果就出来了。那如何滚动更新讷？一台一台关掉就是了，关一台检查是否启动成功，再关下一台。其他都不用考虑。到此，负载均衡和弹性伸缩就都 work 了…接下来就是要解决日志的问题…
顺便说一下…我们有 80+微服务。这套逻辑跑了小半年，最后当然我可以踏踏实实的切刀 k8s 里。废话…200 多实例多浪费钱啊…
但是重点不在部署。部署完成后配套的可靠的自动化测试以及有效的心跳检测才是上面方案有效的关键。
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 节点