iris 框架本身不内置负载均衡能力，必须依赖外部反向代理（如 nginx、haproxy）实现；其单实例设计（app.run() 启动独立进程）缺乏跨进程调度、健康检查与服务发现功能，无法在代码中有效实现负载均衡，否则将引入单点瓶颈和状态同步风险。
Iris 框架本身不内置负载均衡能力，必须靠外部反向代理（如 Nginx、HAProxy、IIS ARR）来实现；你只需确保多个 Iris 实例监听不同端口、行为一致，剩下的交给代理层。
为什么不能在 Iris 代码里配负载均衡
Iris 是一个单实例 HTTP 服务框架，app.Run() 启动的是一个独立进程，不具备跨进程调度、健康检查或服务发现能力。所谓“Iris 负载均衡”实际是部署层面的多实例 + 外部代理组合方案。常见误区是试图在 main.go 里写逻辑分发请求——这不仅无效，还会引入单点瓶颈和状态同步难题。
Nginx upstream 配置轮询模式最常用
这是生产环境最稳妥的起点，适合无状态 Iris 服务（比如你 demo 中的 /version 接口）：
-
upstream块定义后端池，每台服务器用server 127.0.0.1:1213这类地址表示，不加weight就是默认轮询 - 必须启用
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for，否则 Iris 日志里$remote_addr全是127.0.0.1 - 若某实例崩溃，Nginx 默认 10 秒内探测失败并自动剔除；可加
max_fails=3 fail_timeout=30s微调 - 不要漏掉
proxy_redirect off，否则 302 重定向会暴露内部端口
示例片段：
upstream web_servers {
server 127.0.0.1:1213;
server 127.0.0.1:1511;
}
server {
listen 8000;
location / {
proxy_pass http://web_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
}
}
需要会话保持时选 ip_hash，但得谨慎
如果你的 Iris 应用用了内存 session（非 Redis 等外置存储），且没做 session 同步，就必须让同一 IP 始终打到同一实例：
- 在
upstream块第一行加ip_hash;，Nginx 会根据客户端 IP 哈希固定路由 - 注意：NAT 环境下（比如公司出口统一公网 IP）会导致所有用户被压到一台后端，直接雪崩
- IPv6 地址哈希可能不稳定，建议搭配
hash $binary_remote_addr consistent;更可靠 - 该模式下无法手动摘除节点（除非停机），扩容缩容需灰度切流
启动多个 Iris 实例的关键细节
本地测试时容易忽略这些，导致负载不生效或报错：
- 每个实例必须用不同端口，且启动前确认端口未被占用：
lsof -i :1213或netstat -tuln | grep 1213 - 编译时加
CGO_ENABLED=0，避免因目标服务器缺失 libc 动态库而启动失败 - 不要用
go run main.go启动生产实例——它不释放文件句柄，日志混乱，且无法 systemd 管理 - 推荐用
systemd分别管理每个实例，例如iris-app@1213.service和iris-app@1511.service，通过%i占位符注入端口参数
真正复杂的地方不在 Nginx 配置，而在于多实例间共享状态（如缓存、session、定时任务）。如果业务有这类需求，就得跳出纯反向代理思路，引入 Redis、etcd 或消息队列——Iris 只负责把 HTTP 层跑稳。
