负载均衡是构建高并发系统的核心技术之一，但很多人只停留在概念层面，并没有真正动手验证过它的效果。要理解负载均衡，最直接的方式就是自己搭一套环境演示一遍：用Nginx作为流量入口，后面挂两三台模拟的应用服务器，然后观察请求是怎么被分发出去的。整个过程不需要多台真实物理机，一台普通电脑就能完成。本文将完整走一遍这个演示流程，并分析其中的关键配置和常见问题。
一、演示前的环境准备
负载均衡演示的核心思路是：一个Nginx实例作为前端代理，后面挂多个后端服务实例。为了模拟多台服务器的效果，我们可以在同一台机器上启动多个监听不同端口的服务进程，比如8081、8082、8083三个端口分别对应三个后端节点。这种方式在本地演示中最为常见，成本低且效果直观。
后端服务可以用任何语言实现，这里用一个简单的方案：启动多个Python内置的HTTP服务，或者写一个最简单的Node.js服务，让每个节点返回自己的标识，方便后续观察请求到底落在了哪个节点上。以Node.js为例，代码如下：
// server.js，通过环境变量 PORT 指定监听端口，NODE_ID 标识节点
const http = require('http');
const port = process.env.PORT || 8081;
const nodeId = process.env.NODE_ID || 'node-1';
http.createServer((req, res) => {
res.writeHead(200, {'Content-Type': 'text/plain; charset=utf-8'});
res.end('响应来自: ' + nodeId + '\n');
}).listen(port, () => {
console.log(nodeId + ' 监听在端口 ' + port);
});
启动三个节点的命令分别是PORT=8081 NODE_ID=node-1 node server.js、PORT=8082 NODE_ID=node-2 node server.js和PORT=8083 NODE_ID=node-3 node server.js（Windows下可借助cross-env或在代码里写死端口）。启动后分别访问这三个端口，能各自看到对应的节点标识，说明后端服务就绪。接下来安装Nginx，Windows下解压即可用，Linux下用包管理器安装，这一步没有什么难度，重点在配置文件。
二、Nginx负载均衡核心配置与轮询演示
Nginx实现负载均衡依赖两个配置块：upstream定义后端服务器组，proxy_pass把请求转发给这个组。最基础的配置如下：
http {
# 定义后端服务器组，默认策略为轮询
upstream backend_group {
server 127.0.0.1:8081;
server 127.0.0.1:8082;
server 127.0.0.1:8083;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://backend_group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
配置完成后执行nginx -t检查语法，再执行nginx -s reload平滑加载。然后打开浏览器访问http://localhost，不断刷新页面，你会看到页面内容在node-1、node-2、node-3之间轮流出现，这就是最直观的负载均衡演示效果。轮询是默认策略，Nginx会按顺序把请求依次分给每台后端服务器，适合后端机器性能相近的场景。
如果希望演示时看得更清楚，可以用命令行循环请求代替手动刷新，例如在Linux或Mac下执行for i in $(seq 1 9); do curl http://localhost; done，终端会连续输出九次响应，节点标识依次轮换，一目了然。这种输出方式也方便截图用于技术分享或课堂讲解，比反复刷新浏览器更有说服力。
除了轮询，还有两种常见策略值得在演示中对比展示。第一种是权重分配，在server指令后加weight参数，例如server 127.0.0.1:8081 weight=5;，这样该节点获得请求的比例会明显提高，适合后端机器配置不均的情况。第二种是IP哈希，在upstream块中加上ip_hash;指令，Nginx会根据客户端IP计算哈希值，同一个客户端的请求始终落到同一台后端，这可以顺带演示会话保持的效果。
三、进阶演示：故障转移与请求分发观察
只演示请求分发还不够完整，负载均衡另一个重要价值是高可用。可以做一个故障模拟实验：手动停掉其中一台后端服务，比如kill掉8082端口的进程，然后继续访问Nginx。你会发现请求依然能正常响应，只是内容只在剩余两个节点之间轮换。这说明Nginx探测到后端不可用后，自动把请求转移给了健康的节点。
不过要注意，Nginx开源版的被动健康检查有一定滞后性：它只有在转发请求失败后才会标记节点不可用，并在一段时间后重试。如果想演示更精细的健康检查，可以配合max_fails和fail_timeout参数，例如server 127.0.0.1:8082 max_fails=2 fail_timeout=10s;，表示10秒内失败2次就标记为不可用。演示时可以把请求失败的现象展示给观众，再讲解参数的含义，效果会更好。
观察请求分发的另一个手段是查看日志。在http块中配置log_format，把$upstream_addr变量加入访问日志，就能记录每条请求实际被转发到了哪个后端地址。演示结束后查看日志文件，请求的分布情况一目了然，也能顺便验证权重策略是否生效，是排查问题和验证配置的利器。
log_format upstream_log '$remote_addr - [$time_local] "$request" '
'upstream: $upstream_addr '
'status: $status 耗时: $request_time';
access_log logs/access.log upstream_log;
四、常见问题与注意事项
演示过程中最容易遇到的问题是端口冲突。如果机器上80端口已经被占用（比如装了IIS或其他Web服务），Nginx会启动失败，此时可以把listen改成8080等其他端口。另外防火墙也可能拦截端口访问，Linux下需要用firewall-cmd或iptables放行对应端口，Windows下则要检查防火墙入站规则。
第二个常见坑是Session共享问题。轮询策略下，用户的两次请求可能落在不同节点，如果Session存在单机内存里，就会出现登录状态丢失的现象。这一点非常适合作为演示的反面案例：先用轮询展示登录丢失，再切换到ip_hash或讲解用Redis集中存储Session的方案，整个演示的深度立刻就上来了。
最后还有几点需要注意：一是修改配置后务必先执行nginx -t再reload，避免语法错误导致服务中断；二是演示转发真实应用时，记得配置proxy_set_header Host $host;，否则某些依赖Host头的后端框架会出现路由异常；三是如果后端是HTTPS服务，proxy_pass要写完整的https地址，并处理证书相关配置。掌握这些细节，一次完整的负载均衡演示就基本不会翻车了。