使用 Spring MVC 或 Webflux 的代理交换网关
以下描述了一种替代风格的网关。Spring Cloud Gateway 服务器文档中的内容均不适用于以下描述。
如何包含 Spring Cloud Gateway 代理交换
要在你的项目中包含 Spring Cloud Gateway 代理交换（Proxy Exchange），请使用以下依赖项：对于 MVC 代理交换，使用 org.springframework.cloud 作为 group ID，spring-cloud-gateway-mvc 作为 artifact ID。对于 WebFlux 代理交换，使用 org.springframework.cloud 作为 group ID，spring-cloud-gateway-webflux 作为 artifact ID。
有关使用当前 Spring Cloud Release Train 设置构建系统的详细信息，请参阅 Spring Cloud 项目页面。
使用代理交换
Spring Cloud Gateway 提供了一个名为 ProxyExchange 的实用工具对象。你可以在常规的 Spring web 处理程序中使用它作为方法参数。它通过镜像 HTTP 动词的方法支持基本的下游 HTTP 交换。在 MVC 中，它还支持通过 forward() 方法转发到本地处理程序。要使用 ProxyExchange，请在类路径中包含正确的模块（spring-cloud-gateway-mvc 或 spring-cloud-gateway-webflux）。
以下 MVC 示例将 /test 的请求代理到远程服务器：
@RestController
@SpringBootApplication
public class GatewaySampleApplication {
@Value("${remote.home}")
private URI home;
@GetMapping("/test")
public ResponseEntity<?> proxy(ProxyExchange<byte[]> proxy) throws Exception {
return proxy.uri(home.toString() + "/image/png").get();
}
}
以下示例使用 Webflux 实现了相同的功能：
@RestController
@SpringBootApplication
public class GatewaySampleApplication {
@Value("${remote.home}")
private URI home;
@GetMapping("/test")
public Mono<ResponseEntity<?>> proxy(ProxyExchange<byte[]> proxy) throws Exception {
return proxy.uri(home.toString() + "/image/png").get();
}
}
ProxyExchange 上的便利方法使处理程序方法能够发现并增强传入请求的 URI 路径。例如，您可能希望提取路径的尾部元素以将它们传递到下游：
@GetMapping("/proxy/path/**")
public ResponseEntity<?> proxyPath(ProxyExchange<byte[]> proxy) throws Exception {
String path = proxy.path("/proxy/path/");
return proxy.uri(home.toString() + "/foos/" + path).get();
}
所有 Spring MVC 和 Webflux 的特性都可以在网关处理器方法中使用。因此，您可以注入请求头和查询参数，例如，并且可以通过映射注解中的声明来约束传入的请求。有关这些功能的更多详细信息，请参阅 Spring MVC 中 @RequestMapping 的文档。
你可以通过在 ProxyExchange 上使用 header() 方法来向下游响应中添加头信息。
你也可以通过向 get() 方法（以及其他方法）添加一个映射器来操作响应头（以及响应中的任何其他内容）。这个映射器是一个 Function，它接收传入的 ResponseEntity 并将其转换为传出的 ResponseEntity。
提供了对“敏感”头信息（默认情况下为 cookie 和 authorization）和“跳过”头信息（默认情况下为 content-length 和 host）的一流支持，这些头信息不会传递到下游，同时支持“代理”头信息（x-forwarded-*）。“跳过”头信息的背后理念是，当它们被复制到下游请求时可能会导致问题。例如：由于 ProxyExchange 调用下游端点的方式，内容长度可能已经改变，甚至可能使用 Transfer-Encoding: chunked 而不是 Content-Length 头信息。