ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Nginx 负载均衡实战:让两台 Flask 轮流干活

Nginx 负载均衡实战:让两台 Flask 轮流干活 背景单个 Flask 实例在 2G 内存上有点吃力于是起了两台5001、5002想让 Nginx 把请求轮流分给它们。配置定义 upstreamupstream dashboard_cluster{server127.0.0.1:5001;server127.0.0.1:5002;}转发到 upstreamserver{listen8081;location /{proxy_pass http://dashboard_cluster;proxy_set_header Host$host;proxy_set_header X-Real-IP$remote_addr;}}默认是轮询——第一个请求给 5001第二个给 5002循环。怎么验证真的在轮询开两个终端分别盯两个实例的日志# 终端 1dockerlogs-fdashboard_a# 终端 2dockerlogs-fdashboard_b浏览器反复刷新两边日志会交替刷出请求——轮询生效。更直观给 Flask 加一个响应头标出是哪个实例app.after_request def add_instance_header(response): response.headers[X-Instance]os.environ.get(HOSTNAME,unknown)returnresponse然后 curl 几次看变化foriin{1..6};docurl-sIhttp://YOUR_SERVER_IP:8081|grep-iX-Instancedone输出会交替出现不同的容器名。顺便零停机滚动更新有了负载均衡更新时可以逐个来用户无感# 先更新 AB 继续扛流量dockercompose up-d--no-deps--builddashboard_a# 等 A 健康后再更新 Bdockercompose up-d--no-deps--builddashboard_b–no-deps 是关键——不加会连 depends_on 的服务一起重建那就不是滚动更新了。三个坑坑 1upstream 块必须写在 http 上下文里不能写在 server 里面。坑 2两台实例的代码必须一致。如果只更新了一台用户会看到时好时坏的页面。坑 3upstream 里默认没有健康检查。如果 5001 挂了Nginx 还会继续把请求发过去——用户遇到 502。需要配 max_fails 和 fail_timeout 让 Nginx 自动剔除故障节点upstream dashboard_cluster{server127.0.0.1:5001max_fails3fail_timeout30s;server127.0.0.1:5002max_fails3fail_timeout30s;}含义30 秒内失败 3 次就把这台暂时剔除30 秒后再试。
返回列表