
公司服务器上有个官网,一个软件的后台服务,数据库都在这一台服务器上。
有什么好的方式去解决更新 api 的时候不会中断呢服务呢。
1 akira 2023 年 7 月 14 日 更新时间在 1 分钟之内,直接重启就是了。 大不了半夜重启咯。 |
2 BeforeTooLate 2023 年 7 月 14 日 单机不重要的都是选个没人的时间段更新一下 |
3 vacuitym 2023 年 7 月 14 日 用部署两个实例,平时开一个,更新的时候 ng 打到更新好的端口,然后把旧的停掉 |
4 mineralsalt 2023 年 7 月 14 日 运行两个实例不同端口, nginx 负载均衡, 随便停一个都不影响 api 请求, 轮流更新即可, 我就是这么做的 |
5 zzzzzzZ 2023 年 7 月 14 日 你期望的无感平滑更新 小公司「滚动发布」是最常见的,或者「灰度发布」 |
6 LeegoYih 2023 年 7 月 14 日 1.假设已有实例 A:8080 正在运行 2.运行实例 B:8081 3.Nginx 改配置端口 8080->8081 ,nginx -s reload 4.销毁实例 A:8080 |
7 0x663 2023 年 7 月 14 日 灰度发布 |
8 buffzty 2023 年 7 月 14 日 docker-compose 最优解 |
9 everyx 2023 年 7 月 14 日 我们用的 docker swarm 简单、轻量 |
10 brader 2023 年 7 月 14 日 不好意思,我们 PHP 没有这个烦恼,都是直接 git pull ,嘿嘿 |
11 zx900930 2023 年 7 月 14 日 双实例,负载均衡,可以用 nginx 或者 traefik ,haproxy 之类。 更新的时候 rolling update 就可以了,数据库也可以做成主从复制类型的,这样数据库 migration 的时候也不会中断服务。 |
12 tool2d 2023 年 7 月 14 日 一般都是热更新,但你也说了,“很小的公司”,说明访问量很低,那服务重启一分钟,也完全没问题的。 我个人觉得 API 在初期变动很大的情况下,没必要追求热更新的无缝切换。 |
13 qinconquer OP @tool2d 明白了 感谢 |
14 qinconquer OP @everyx 貌似这个也要最少两台服务器 |
15 SethShi 2023 年 7 月 14 日 说一下你的系统架构, 像 PHP 这种不会存在更新中断, 想 Go 这种有直接在代码中判断信号来升级的. 实现不想在代码下手的就用楼下说的 Nginx 两端口号轮流用更新 |
16 Vraw5 2023 年 7 月 14 日 old 用端口 8888 起服务,new 用 9999 起服务,改 nginx ,reload 一下改过去就是了 |
17 hytex 2023 年 7 月 14 日 关键字 nginx 、upstream 、backup ,完美实现你说的这种发布。只需要启动到一个端口,然后 kill 掉另一个端口的进程就好了 |
19 Erroad 2023 年 7 月 14 日 找段没流量的时间直接重启 |
20 rbe 2023 年 7 月 14 日 负载均衡有流量控制的作用,参考 6 楼说的,部署完新服务做完健康检查后,用 nginx 切一下流量就行。 这里提供更多一点参考: 可以用 confd 来做自动切换 nginx 配置重启,把 nginx 的配置做成模板让 confd 管理,将新、旧容器的端口记在 etcd 或者简单点记在文件里。 用脚本在发布服务后更新 etcd 的 key => 触发 confd 更新 nginx 模板并自动执行 nginx -t / nginx -s reload |
21 displayabc 2023 年 7 月 14 日 docker swarm 只需要一台机器就可以 |
22 everyx 2023 年 7 月 15 日 @qinconquer #14 单机也可以的,还方便以后扩展到多台服务器,比 K8S 适合小企业,K8S 需要的资源又高、概念又多又复杂 |
23 OP @everyx 有这方面的资料吗,我想学习下你说的单机模式去跑这个 |
24 everyx 2023 年 7 月 17 日 @qinconquer #23 很简单,直接 docker swarm init 就行了,可以直接看官方文档 https://docs.docker.com/engine/swarm/swarm-tutorial/ |
25 zu1y 2023 年 7 月 23 日 感觉上面说的都过于麻烦了。直接在一台服务器上部两个实例,然后 Nginx 上通过 nginx_upstream_check_module 模块配一个主动的健康检测就好了,后端使用滚动发布,发布过程中 Nginx 会通过心跳检测自动把不可用的那个实例摘除掉的 |