微服务网关访问控制的关键，在于将身份认证与权限校验统一集中到网关层处理，避免各个微服务重复开发一套登录鉴权逻辑。实际落地时，通常会选用Spring Cloud Gateway，借助全局过滤器完成JWT/OAuth2令牌校验，解析出用户身份后再通过请求头向下游服务透传；同时结合路径级权限映射表，把访问权限控制细化到接口和资源层面。当然，CORS、HTTPS、日志审计等安全配置同样不能忽视，只有这些环节协同配合，才能构建完整可靠的微服务安全防线。
微服务网关的访问控制，核心思路就是把身份校验和权限判断统一收口到网关层，避免每个微服务重复实现登录认证与鉴权逻辑。配置的关键不在于“是否可行”，而在于“如何配置得更稳定、更准确、更易维护”，这也是企业级微服务架构中网关安全治理的重点。
网关选型与基础路由配置
建议优先选用 Spring Cloud Gateway（而不是已经停止更新的 Zuul）。它基于 WebFlux，具备更好的性能表现与扩展能力，并且原生支持过滤器链、路由断言等机制，适合承担微服务网关访问控制与统一认证的职责。
- 在 pom.xml 中引入关键依赖：
spring-cloud-starter-gateway、spring-cloud-starter-alibaba-nacos-discovery（如果使用 Nacos 作为注册中心）、spring-cloud-starter-loadbalancer - 在 application.yml 中配置路由规则，目标地址使用 lb://服务名（例如
lb://userservice），由网关自动从注册中心获取实例并进行负载均衡 - 为每个路由配置清晰的 predicates（如
- Path=/user/**），明确不同请求路径由哪个下游服务进行处理
统一身份认证接入
网关本身通常不负责签发 token，但必须具备校验 token 合法性并提取用户身份信息的能力，例如 userId、roles 等关键字段。
- 推荐对接独立的认证中心或 Auth Server（如基于 OAuth2 或 JWT 的授权服务），由网关通过 全局过滤器（GlobalFilter）拦截请求，统一校验 Authorization 请求头中的 Bearer Token
- 校验通过后，将解析得到的用户信息（如 subject、roles）通过请求头透传给下游服务，例如：
AddRequestHeader=userId, {userId}、AddRequestHeader=roles, {role1,role2} - 对于非法 token 或已过期 token，直接返回 401，不允许继续访问；缺少 token 返回 401；签名错误或内容被篡改时返回 403
细粒度接口级权限控制
访问控制不能只停留在“用户已登录即可访问”，还必须进一步限制“什么角色、什么权限可以访问哪些接口、执行哪些操作”。更理想的方式是由各微服务声明权限规则，再由网关统一执行权限判断。
- 各微服务在启动时，将本服务中所有带权限注解（如
@RequiresRole("ADMIN")或@RequiresPermission("order:delete")）的接口元数据注册到共享存储中（如 Redis） - 网关监听该共享存储的变化，实时加载并缓存全量的 路径→权限要求 映射表
- 当请求到达时，网关根据路径查表获取当前接口所需角色或权限，再与请求头中携带的用户角色列表进行比对，匹配失败则返回 403
- 菜单权限可以同步纳入统一管理，非页面接口（如定时任务触发、系统内部回调）也应接入同一套权限体系，避免出现权限漏控
安全加固与生产注意事项
网关访问控制配置只是起点，在生产环境上线之前，还必须补齐各类安全防护细节，才能确保系统稳定运行。
- 关闭网关的敏感端点（如
/actuator/gateway），或至少增加访问白名单限制；同时禁止在生产环境暴露 Hystrix Dashboard 等调试接口 - 所有对外路由都应开启 CORS 配置，但不要直接使用
allowedOrigins: ["*"]；更推荐显式配置受信任域名列表 - 网关自身应采用集群部署，前置 Nginx 实现负载均衡和 TLS 终结；HTTPS 必须强制开启，并将 HTTP 自动跳转到 HTTPS
- 记录完整访问日志（包括 IP、请求路径、响应状态码、耗时、token 主体等信息），方便后续进行安全审计、问题排查与异常追踪
