使用 Spring MVC 或 Webflux 的代理交換閘道器

以下描述了一種替代風格的閘道器。接下來的內容不適用於 Spring Cloud Gateway Server 文件中的任何部分。

如何引入 Spring Cloud Gateway Proxy Exchange

要在專案中引入 Spring Cloud Gateway Proxy Exchange,對於 MVC 代理交換,請使用 group ID 為 org.springframework.cloud、artifact ID 為 spring-cloud-gateway-mvc 的依賴。對於 WebFlux 代理交換,請使用 group ID 為 org.springframework.cloud、artifact ID 為 spring-cloud-gateway-webflux 的依賴。

有關使用當前 Spring Cloud Release Train 設定構建系統的詳細資訊,請參閱 Spring Cloud 專案頁面

使用 Proxy Exchange

Spring Cloud Gateway 提供了一個名為 ProxyExchange 的工具物件。您可以在常規 Spring web 處理器中將其用作方法引數。它透過映象 HTTP 動詞的方法支援基本的下游 HTTP 交換。對於 MVC,它還透過 forward() 方法支援轉發到本地處理器。要使用 ProxyExchange,請在您的 classpath 中包含正確的模組(spring-cloud-gateway-mvcspring-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 並將其轉換為傳出的響應。

對“敏感”頭(預設為 cookieauthorization)和“跳過”頭(預設為 content-lengthhost)提供了一流的支援,這些頭不會向下遊傳遞;對於“代理”頭(x-forwarded-*)也提供了支援。“跳過”頭的理念是,當它們被複制到下游請求時可能會導致問題。例如:由於 ProxyExchange 呼叫下游端點的方式,內容的長度可能已經改變,甚至可能使用 Transfer-Encoding: chunked 而不是 Content-Length 頭。