微服务网关的负载均衡是动态智能选实例并联动服务发现，发生在路由后、转发前；通过lb://协议、注册中心集成及健康感知实现，区别于Nginx静态配置。
微服务网关作为负载均衡入口，核心不是“额外加一层负载均衡”，而是让网关自身具备从多个服务实例中智能选一个的能力，并与服务发现机制联动。它取代了传统Nginx里静态写死upstream的方式，实现动态、可感知健康状态的流量分发。
明确网关负载均衡的定位
网关的负载均衡发生在“路由到服务后、转发到具体实例前”这一环节。例如：
- 请求
/api/users/123→ 网关先匹配路由规则，确认目标是userservice； - 接着查注册中心（如Nacos/Eureka），拿到所有存活的
userservice实例列表； - 再用轮询/随机/最小连接等策略，从中挑出一个IP:PORT；
- 最后将请求代理过去。
这和单纯用Nginx做反向代理有本质区别：网关知道“服务名”，不关心具体地址；地址由注册中心实时提供，故障实例自动剔除。
关键接入步骤
以主流 Spring Cloud Gateway 为例，接入要点如下：
-
引入服务发现客户端：添加
spring-cloud-starter-alibaba-nacos-discovery或spring-cloud-starter-netflix-eureka-client，让网关能连上注册中心； -
路由 URI 使用
lb://协议：例如uri: lb://userservice，其中lb表示“load balance”，触发内置负载均衡逻辑； -
确保服务已注册且健康：下游
userservice必须在 Nacos/Eureka 中显示为UP状态，否则不会被选中； -
（可选）自定义负载均衡算法：通过配置
spring.cloud.loadbalancer.configurations=custom或替换ReactorLoadBalancerBean 来切换策略，如权重、一致性哈希等。
对比其他常见方式
不同技术栈实现路径略有差异，但目标一致：
-
Nginx + 服务发现插件：需配合
nginx-upsync-module或lua-resty-consul，定时拉取服务列表并更新upstream； -
Kong 网关：通过
upstream+target抽象，结合健康检查和ring-balancer实现动态节点管理； -
Go 自研网关（如文中 Day2 架构）：手动实现
Backend管理、存活状态锁、RoundRobinBalance等接口，与配置中心或 API 同步服务实例。
必须注意的细节
实际落地时容易忽略但影响稳定性的问题：
- 网关与注册中心的心跳超时、重试次数要合理设置，避免因短暂网络抖动误判实例下线；
- 下游服务启动后，需预留几秒注册+健康检查通过时间，再将流量切过去；
- 若使用一致性哈希，要注意 key 的选择（如用户ID、请求头字段），避免 key 分布倾斜导致某实例压力过大；
- 日志中应记录每次选中的实例地址，便于问题回溯。
