API网关和微服务的分工就像小区门禁与楼栋管理
你住的小区可能有大门保安，每栋楼还有自己的门禁系统。API网关就像是整个微服务架构的“小区大门”，所有外部请求必须先经过它，才能进入内部各个服务。微服务则是分布在不同楼栋里的独立单元，各自处理特定业务，比如用户登录、订单处理、支付接口。
没有API网关的时候，前端要直接调用十几个微服务，每个都要记住地址、端口、认证方式，就像访客得背下每栋楼的开门密码，显然不现实。API网关统一收口，对外提供一个入口，内部再把请求转发到对应的微服务，简化了调用逻辑。
路由转发：让请求走对门
比如用户发起一个订单查询请求，URL是 /api/order/123，API网关根据路径规则识别这是订单服务的请求，自动转发给 order-service 实例。配置类似这样：
routes:\n - id: order_route\n uri: http://order-service:8082\n predicates:\n - Path=/api/order/**这种路由机制让后端服务可以自由变更IP或端口，只要网关配置同步更新，外部完全无感。
统一认证和限流，减轻微服务负担
每个微服务自己做登录校验，代码重复不说，一旦策略调整就得挨个改。API网关可以在入口处统一验证JWT令牌，合法才放行。同时还能限制某个IP每秒最多请求50次，防刷防攻击。这样一来，微服务专注业务逻辑，不用再操心安全和流量控制。
比如在Nginx或Spring Cloud Gateway里加个全局过滤器，所有请求自动检查token：
filters:\n - name: AuthFilter\n args:\n tokenHeader: Authorization聚合响应，减少前端请求压力
一个商品详情页可能要拉取商品信息、库存、用户评价、推荐列表四个微服务的数据。如果前端一个个去调，页面加载慢还容易出错。API网关可以提供聚合接口，一次请求内部并行调用多个服务，整合结果返回。相当于门卫帮你把四栋楼的信息都收集好，统一交给你。
故障隔离与日志追踪
某个微服务挂了，API网关能快速熔断，返回友好提示而不是让用户卡死。同时记录完整请求链路，加上唯一trace ID，排查问题时能顺藤摸瓜找到是哪个服务出了毛病。运维人员看日志不再像大海捞针。
微服务拆得越细，API网关的作用就越明显。它不只是个转发器，更是微服务架构的“交通指挥中心”。在日常服务器维护中，调整网关配置往往比重启一堆服务更高效稳妥。