语之溪
微服务拆分后，如果客户端直接记住每个服务的地址，前端会同时依赖认证、用户、内容、评论等多个服务。服务地址变化、跨域、认证和错误格式也会分散到各个调用点。
在 HAOVP 中，我让 Spring Cloud Gateway 作为外部请求的统一入口。客户端只面对网关，网关再根据请求路径和规则把流量转发到对应服务。
统一入口解决什么
网关位于客户端和业务服务之间，可以集中处理一部分横向问题：
客户端
-> Gateway
-> 认证服务
-> 用户服务
-> 内容服务
-> 评论服务
-> 推荐服务
-> 管理服务它适合承担：
- 统一路由；
- 基础身份信息检查；
- 请求和响应头处理；
- CORS；
- 入口限流；
- 统一日志与链路标识；
- 部分通用错误转换。
网关不是业务服务的替代品。视频状态、评论权限和管理操作等具体规则仍然属于对应服务。
路由由三部分组成
Gateway 路由通常包括目标地址、断言和过滤器。
spring:
cloud:
gateway:
routes:
- id: content-route
uri: lb://content-service
predicates:
- Path=/api/content/**
filters:
- StripPrefix=1这是脱敏示例，服务名和路径不对应真实项目配置。
uri表示请求转发目标；predicates判断请求是否匹配；filters在转发前后处理请求或响应。
使用 lb:// 时，网关会通过服务发现按服务名寻找实例，而不是依赖固定地址。
路由顺序和范围要明确
多个路由规则可能同时匹配同一请求。过于宽泛的路径容易抢先命中，导致请求进入错误服务。
我会检查：
- 公共前缀是否统一；
- 管理端与用户端路径是否隔离；
- 内部接口是否不对外开放；
- 静态资源是否需要经过网关；
- 路由顺序是否造成覆盖；
- 修改路径后前端和文档是否同步。
路由配置能加载成功，不代表每条请求都被正确转发，仍然需要逐条验证关键入口。
认证检查和业务权限要分层
网关可以检查请求是否携带身份凭证、凭证是否基本有效，并把可信的用户标识传给下游。
网关：
是否需要登录
凭证是否存在
凭证是否有效
提取基础身份
业务服务：
是否能访问这条数据
当前状态是否允许操作
是否具有具体角色或权限
是否满足业务规则如果把所有权限规则都写进网关，网关会依赖各业务的数据模型，最终变成一个难以维护的“大服务”。
下游服务也不能完全相信客户端自带的用户头。身份信息应该由网关在验证后重新写入，并防止客户端伪造同名请求头。
过滤器适合做通用处理
Gateway 过滤器可以分为全局过滤器和路由过滤器。
全局过滤器适合处理所有请求的共性逻辑，例如：
- 生成或传递请求标识；
- 记录脱敏后的访问日志；
- 清理不可信请求头；
- 统一增加安全响应头；
- 处理基础认证上下文。
路由过滤器更适合某类接口的特殊处理，例如路径重写或特定超时策略。
过滤器顺序很重要。认证、日志、限流和异常处理的执行先后不同，会影响日志内容和错误返回。
CORS 应集中但要有限制
前端开发和部署域名不同时，浏览器会执行跨域检查。网关可以统一设置允许的来源、方法和请求头。
不应简单使用“允许所有来源 + 携带凭据”。更安全的方向是：
- 只允许明确的来源；
- 限制方法和请求头；
- 正确处理预检请求；
- 区分开发与部署环境；
- 不在错误响应中遗漏 CORS 头。
真实域名和环境配置属于敏感部署信息，公开文章只讨论规则。
限流放在入口，但不是唯一保护
网关限流可以在流量进入业务服务前拒绝一部分过量请求，减少下游压力。
可以按不同维度设计：
- IP 或客户端；
- 用户身份；
- 路由；
- 接口组；
- 全局并发或请求速率。
但入口限流不能替代业务幂等、数据库约束和下游服务保护。某个服务被内部调用时，也可能绕过外部网关，因此服务自身仍要有必要的超时、熔断和资源控制。
限流阈值需要根据测试和资源情况调整，不能只复制示例参数。
错误响应要保留真实原因边界
网关层可能遇到路由不存在、认证失败、限流、下游超时和服务不可用等错误。它可以把这些通用错误转换成统一结构。
{
"code": "SERVICE_UNAVAILABLE",
"message": "The service is temporarily unavailable",
"requestId": "example-request-id"
}示例不包含真实请求标识和内部异常。
业务校验失败则应该由业务服务返回。网关不应把所有错误都改成同一个“系统异常”，否则会丢失可排查信息。
日志要能串起一次请求
请求经过网关和多个服务时，需要一个可传递的请求标识帮助关联日志。
客户端请求
-> 网关生成 requestId
-> 转发到业务服务
-> 服务间继续传递
-> 响应带回 requestId日志中可以记录路由、耗时、状态码和请求标识，但不能记录完整 Token、密码和敏感业务数据。
常见排查顺序
请求无法访问时，我会按入口链路检查：
路径是否匹配路由
-> 服务名是否正确
-> Nacos 是否有健康实例
-> 网关能否连接下游
-> 过滤器是否拒绝请求
-> 下游是否正常响应
-> 错误是否在网关被转换如果请求根本没有匹配路由，就不需要先排查业务代码；如果已经到达下游，则要继续查看业务服务日志。
网关也会成为关键依赖
统一入口减少了客户端复杂度，也让网关成为重要节点。网关自身异常可能影响所有外部请求，因此需要考虑：
- 多实例部署与负载入口；
- 配置错误的影响范围；
- 路由和过滤器的自动化验证；
- 超时、内存和连接资源；
- 健康检查与监控；
- 配置发布和回滚。
这些能力要通过实际部署和故障验证，不能因为使用 Gateway 就默认具备。
Spring Cloud Gateway 承担统一入口职责，核心是把路由、基础认证、跨域、入口限流和通用观测集中起来，同时让具体业务规则留在业务服务中。入口统一之后，边界反而要更清楚：网关负责通用流量治理，服务负责自己的业务正确性。
