网关基本概念
为什么需要 API 网关
随着微服务架构的普及，不同服务往往拥有独立的网络地址。当外部客户端需要完成一个业务需求时，可能需要调用多个服务接口。如果让客户端直接与各个微服务通信，会带来不少麻烦：
- 客户端需多次请求不同服务，增加了复杂度。
- 跨域请求处理变得复杂。
- 认证逻辑分散，每个服务都要独立处理。
- 重构困难，服务合并或拆分都会影响客户端。
- 部分服务可能使用防火墙或不友好的协议，直接访问受限。
借助 API 网关可以解决上述问题。它是介于客户端和服务端之间的中间层，所有外部请求先经过网关。业务逻辑专注于核心功能，而安全、性能、监控则交由网关处理，既提高了灵活性又保障了安全性。
Spring Cloud Gateway 简介
Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0、Spring Boot 2.0 和 Project Reactor 等技术开发的网关。它旨在为微服务架构提供简单、有效且统一的 API 路由管理方式。作为 Spring Cloud 生态系统中的网关，其目标是替代 Netflix Zuul，不仅提供统一的路由方式，还基于 Filter 链提供了安全、监控埋点、限流等基础功能。
核心概念
网关对外暴露的 URL 或接口信息统称为路由信息。对于研发过网关或使用过 Zuul 的人来说，核心在于 Filter 及其责任链。Spring Cloud Gateway 同样包含路由和 Filter 的概念：
- 路由（Route）：最基础的部分。由 ID、目标 URL、一组断言和一组 Filter 组成。只有当断言匹配成功时，请求才会被路由。
- 断言（Predicate）：基于 Java 8 的函数式接口。输入类型是 Spring 5.0 的 ServerWebExchange。允许开发者定义匹配规则，比如检查请求头或参数。
- 过滤器（Filter）：标准的 Spring Web Filter。分为 Gateway Filter 和 Global Filter 两种，用于对请求和响应进行修改处理。
请求流程大致如下：Gateway Handler Mapping 找到匹配的路由，发送到 Gateway web handler，再通过指定的过滤器链将请求转发到实际的服务执行业务逻辑，最后返回结果。
网关与 Nginx 对比
在没有网关的情况下，我们通常使用 Nginx 的反向代理来解决请求转发问题。这相当于单独配置一台代理服务器，对外表现为一个节点。这种方式虽然可行，但在微服务架构中，使用网关方案更为自然，能更好地配合服务发现与动态路由，解决前后端分离中的请求转发痛点。
下一步构思
此前我们创建了两个服务模块 service_user 和 service_file，端口分别为 9901 和 9902。接下来的重点是如何配置网关，让客户端只需调用一个端口即可对接这些服务。后续将详细演示具体配置步骤。
