引言

在微服务架构和分布式系统的日常开发中，负载均衡、API网关、路由分发、鉴权 这些术语经常被提及。很多开发者容易陷入一个误区：认为网关带负载均衡，所以它们是一回事；或者把路由和负载均衡混为一谈。
本文将通过清晰的层级、生动的类比和对比表格，帮你彻底理清这四个核心概念的职责、关系与差异。

一、先分清流量分流、路由与负载均衡

在开始之前，必须先理清一个包含关系：流量分流是总称，路由分发和负载均衡都是它的具体实现，但二者目的完全不同。

1.1 流量分流 —— 大概念

只要是把请求流量拆开，导向不同的目标，都叫流量分流，常见有三类：

• 路由分流：按业务接口拆开，/order 走订单服务，/goods 走商品服务。
• 灰度分流：10%用户访问新版本，90%访问旧版本。
• 负载均衡分流：同一服务的多个实例之间均分流量，避免单点压力。

1.2 路由分发 ≠ 负载均衡

很多混淆就出在这里，其实它们是微服务调用的 前后两步：

• 路由分发（Routing）
  作用：根据请求 URL / Header 等，匹配到对应的业务服务集群。
  例如：/api/order/** → 订单服务集群，/api/goods/** → 商品服务集群。
  核心：按业务分类，选择“服务组”。
• 负载均衡（Load Balancing）
  作用：在同一个服务集群内，挑一台具体的机器实例。
  前提：路由已经选定了某个服务集群（比如订单集群有3台实例），再通过轮询、最小连接数、IP哈希等算法，把请求转发给其中一台。
  核心：同一业务的多台副本之间均分流量，选择“集群内的单台机器”。

完整流程举例：
用户请求 /api/order/create
1. 网关先做 路由分发：匹配到 /api/order/**，确定转发给“订单服务集群”。
2. 再执行 负载均衡：在订单集群的3台实例中，根据轮询算法挑选一台机器，把请求转发过去。

类比

• 路由 = 商场导览台：买家电去3号区，买服装去2号区。
• 负载均衡 = 家电区收银台分流：该区有3个收银台，顾客轮流分配，不会让某一个排队爆满。

一句话总结：路由是“分到哪个业务”，负载均衡是“业务内部分给哪台机器”，两者搭配但完全不是一回事。

二、API网关 vs 负载均衡：层级与职责天差地别

2.1 核心定位不同

• 负载均衡：只是一个流量分发算法/能力，目标是把流量均匀分给多台相同的服务实例，解决单机压力过大和故障转移问题。它可以独立存在，如 Nginx、Feign、Ribbon。
• API网关：是整个系统的统一流量入口服务，而负载均衡只是它自带的基础功能之一。网关承载了鉴权、路由、限流、熔断、日志、灰度发布、跨域处理等一整套公共逻辑。

2.2 实际项目中的两层负载均衡

以一个典型的商城微服务架构为例：

第一层：网关层（Spring Cloud Gateway / Nginx）
用户请求先打到网关，这是对外的唯一大门：
- 统一身份认证（鉴权）、跨域、限流、日志；
- 路由分发：/api/order 转给订单服务，/api/goods 转给商品服务；
- 负载均衡：转发时，从后端服务集群中按算法挑一台实例。

第二层：服务间远程调用（OpenFeign + Ribbon/LoadBalancer）
微服务内部调用时，例如订单服务调用商品服务，由 Feign 自带的负载均衡组件完成实例选择，整个过程不经过网关。

2.3 功能对比表

对比维度	负载均衡	API网关
核心定位	流量分发算法/单一能力	微服务统一入口，全能中间件
核心功能	仅分配请求到多实例，均衡压力	路由分发、负载均衡、统一鉴权、限流熔断、灰度发布、跨域、日志、请求转换
能否独立存在	可以。Nginx、Feign 单独提供负载均衡	不能脱离负载均衡，分发流量必须依赖均衡算法
处理范围	只解决“多实例分流”一件事	处理所有微服务通用前置逻辑，抽离公共代码
使用层级	1. 网关转发后端服务 2. 微服务内部 RPC 调用	面向前端/外部用户的统一入口
典型产品	Nginx、Feign、Ribbon、HAProxy	Spring Cloud Gateway、Zuul、Kong、APISIX

2.4 生活化类比

• 负载均衡 = 食堂里的分菜窗口分配规则。有3个一模一样的打菜窗口，规定“来一个人按顺序轮换窗口”，只负责均匀分流，不管你是谁、不管有没有排队限流。
• API网关 = 食堂大门口的保安 + 总调度台。
  1. 进门先查饭卡（统一认证）；
  2. 根据你要买的餐品指路：面食去1号窗、套餐去2号窗（路由）；
  3. 指路时顺带控制每个窗口人数均匀（内置负载均衡）；
  4. 高峰期限制进入人数（限流）；
  5. 记录进出记录（日志）；
  可以看到，负载均衡只是保安工作里的一小步，保安（网关）要做的事情多得多。

2.5 常见误区澄清

• 误区1：网关带负载均衡，两者就是一样
  错。负载均衡是通用基础能力，Nginx、Feign、注册中心都有，不是网关的专利；网关是集成多种公共能力的入口服务，负载均衡只是其中之一。
• 误区2：没有网关就不能负载均衡
  错。单体集群用 Nginx 直接做负载均衡，没有网关；微服务内部 Feign 调用自带负载均衡，也不经过网关。
• 误区3：负载均衡=路由
  错。路由区分不同业务接口，负载均衡是同一业务多副本之间分配请求。

三、鉴权：API网关的核心职责之一

3.1 鉴权是什么？

字面拆解：鉴 = 查验、核对；权 = 访问权限。
鉴权 = 校验当前用户有没有资格访问这个接口/页面/资源

开发中的完整含义包括两步：
1. 认证（Authentication）：你是谁 —— 登录校验，确认身份合法性。
2. 授权（Authorization）：你能干什么 —— 权限校验，确认操作范围。
日常统称为“鉴权”。

生活类比：小区门禁系统
- 刷身份证进门岗（认证：确认你是小区住户）
- 只有你家楼栋的电梯能刷开（授权：不能进别人单元）
整套流程就是鉴权。

3.2 网关统一鉴权的流程

结合你的微服务项目，用户请求 http://域名/api/order/create 到达网关后：

第一步：身份认证
从请求头中取出 token，到 Redis / 认证服务中进行校验：
- token 有效且未过期 → 身份合法，放行；
- 没有 token、token 过期或伪造 → 直接返回 401 Unauthorized，不转发到订单服务。

第二步：权限授权
登录成功后，查询该用户的角色或权限标识：
- 普通用户只允许查询订单，没有创建权限 → 网关拦截，返回 403 Forbidden；
- 管理员允许创建、删除订单 → 放行到后端服务。

3.3 为什么鉴权放在网关？

• 统一拦截：所有外部请求在网关处集中校验，一处控制全部接口。
• 避免重复：商品、订单、支付等微服务不需要各自写一遍登录和权限代码。
• 安全与性能：未登录/无权限的请求在网关层就被拦截，避免无效流量打到后端服务，节省资源。

3.4 常见鉴权方案

• Token 鉴权（JWT/自定义令牌）：登录后返回 token，后续请求在 Header 中携带，网关校验。分布式微服务主流方案。
• Session 认证：服务器端存储会话，单体项目常用，分布式环境下需额外处理会话共享，不推荐。
• OAuth2.0：第三方授权登录，如微信、QQ、支付宝快捷登录。

3.5 两个关键 HTTP 状态码

• 401 Unauthorized：未鉴权（没登录、token 无效或过期）。
• 403 Forbidden：鉴权通过（已登录），但当前角色没有访问该接口的权限。

四、总结：一张图理清所有关系

我们把整个链路串起来：

1. 外部请求 → 到达 API网关 （统一入口）
2. 网关做 鉴权 （认证+授权），不合法直接返回 401/403
3. 通过后，网关根据 URL 做 路由分发 （选服务集群：订单/商品/支付）
4. 针对选中的集群，执行 负载均衡 （从多台实例中挑一台）
5. 转发请求到具体实例，后微服务内部调用时，也由 Feign 自带负载均衡 完成分流

核心关系图（抽象）：

流量分流
├── 路由分流（按业务划分，非负载均衡）
└── 负载均衡分流（同一服务多副本均分流量）
        ├── 网关侧负载均衡（对外入口）
        └── 服务间调用负载均衡（Feign/Ribbon）

负载均衡 是一种流量分流的策略，而 API网关 是一个集成了路由、鉴权、负载均衡等能力的综合服务。
理解这些概念的边界，能让你在微服务架构设计中更清晰地划分职责，避免重复造轮子和无效沟通。