Einführung in das Spring Cloud Gateway
Die offizielle Version von Spring Boot 2 wurde erst vor einiger Zeit veröffentlicht. Spring Cloud Gateway basiert auf Spring Boot 2 und ist ein brandneues Projekt von Spring Cloud. Das Projekt bietet ein API -Gateway, das auf dem Spring -Ökosystem gebaut wurde, darunter: Spring 5, Spring Boot 2 und Project Reactor. Das Spring Cloud Gateway ist so konzipiert, dass sie eine einfache und effiziente Möglichkeit bieten, APIs zu senden und sie mit Kreuzungsbedenken wie Sicherheit, Überwachung/Metriken und Belastbarkeit zu versorgen. Die aktuelle neueste Version ist v2.0.0.m8 und die offizielle Version wird auch bald hier sein.
Merkmale des Spring Cloud Gateway:
gegen Netflix Zuul
Zuul basiert auf Servlet 2.5 (unter Verwendung der blockierenden API mit 3.x). Es unterstützt keine langen Verbindungen wie WebSockets. Während des Gateways auf dem Spring-Framework 5, dem Projektreaktor und Spring Boot 2 unter Verwendung einer nicht blockierenden API basiert. WebSockets wird unterstützt und wird eine bessere Entwicklungserfahrung sein, da es eng in den Frühling integriert ist.
Frühlingswolken -Gateway -Einführungspraxis
Der Autor hat kürzlich den Quellcode von Spring Cloud Gateway untersucht und Artikel zur Quellcodeanalyse für die meisten Funktionen geschrieben, aber die offizielle Version wurde doch nicht veröffentlicht. Dieser Artikel ist eine Einführungspraxis, die mehrere häufig verwendete Funktionen zeigt und sich auf die Veröffentlichung der neuesten offiziellen Version freut.
Beispiel startet zwei Dienste: Gateway-Server und Benutzerserver. Das simulierte Szenario ist, dass der Kunde den Backend -Service anfordert und das Gateway einen einheitlichen Eingang zum Backend -Service bietet. Alle Backend -Dienste sind beim Service registriert und haben Konsul (sowohl Build ZK als auch Eureka sind in Ordnung, und ich bin eher an die Verwendung von Konsul gewöhnt). Das Gateway wird durch Lastausgleich zu bestimmten Backend -Diensten weitergeleitet.
Benutzerdienst
Der Benutzerdienst ist bei Consul registriert und bietet eine Schnittstelle/Test.
verlassen
Die erforderlichen Abhängigkeiten sind wie folgt:
<De vorangestellt> <gruppe> org.springframework
Konfigurationsdatei
Frühling: Anwendung: Name: User-Service Cloud: Konsult: Host: 192.168.1.204 Port: 8500 Erkennung: IP-Address: $ {host_address: localhost} port: $ {server_port: $ {server. 8005management: Sicherheit: Aktiviert: FalschDie Schnittstelle freilegen
@SpringBootApplication@rastController@enablediscoveryClientPublic Class GatewayUserApplication {public static void main (String [] args) {SpringApplication.run (GatewayuserApplication.Class, Args); } @GetMapping ("/test") public String test () {return "OK"; }}Schnittstelle freilegen/testen und OK zurückgeben.
Gateway -Dienste
Der Gateway -Service bietet eine Vielzahl von Routing -Konfigurationen, Routing -Assertion -Fabriken und Filterfabriken.
verlassen
Abhängigkeiten, die eingeführt werden müssen:
<Depopentcy> <gruppe> org.springFramework.boot </Groupid> <artifactId> Spring-Boot-Actuator </artifactid> </Deponcy> // Abhängigkeit von webflux ist es erforderlich, <Depepoccy> <GroupID> org.springFramework.boot </GroupID> einzuführen </GroupID> <artifactid> Spring-Boot-Starter-Webflux </artifactId> </abhängig> <depeopcy> <gruppe org. <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-discovery</artifactId> <version>2.0.0.M6</version> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </exclusion> </exklusions> </abhängig> // kotlin abhängig <abhängigkeit> <gruppe> org.jetbrains <gruppe> org.jetbrains.kotlin </Groupid> <artifactid> kotlin-reflect </artifactid> <version> $ {kotlin.version} </Version> <option> true </optional> </abhängig>Wie oben erwähnt, werden kotlinbezogene Abhängigkeiten eingeführt, und die Routing-Konfiguration von Kotlin muss hier unterstützt werden. Die Verwendung von Spring Cloud Gateway erfordert die Ausnahme von Webkonfigurationen im Zusammenhang mit Web-bezogenen Konfigurationen. Es führt Verweise auf WebFlux ein. Es wird überprüft, wenn die Bewerbung beginnt und muss eingeführt werden.
Routing Assertion Factory
Abhängig von der Anfragezeit, des Hosts, der Pfad, der Methode usw. gibt es viele Arten von Routing-Assertion-Fabriken. Die folgende Definition ist eine pathbasierte Routenbehandlungsanpassung.
@BeanPublic Routerfunction <ServerResponse> TestFunRouterFunction () {Routerfunction <ServerResponse> Route = RouterFunctions.route (RequestPredicates.Path ("/testfun"), Anfrage -> Serverresponse (). Bodyinsers. Return Route;}Wenn der angeforderte Pfad /testfun ist, wird der Statuscode von OK direkt zurückgegeben und die Antwortkörper ist eine Hallo -Zeichenfolge.
Filterfabrik
Gateways müssen häufig Routing -Anfragen filtern und einige Vorgänge ausführen, z. B. die Konstruktion von Headern nach der Authentifizierung. Es gibt viele Arten der Filterung, z. B. Hinzufügen von Anforderungsheadern, Hinzufügen von Anforderungsparametern, Hinzufügen von Antwortheadern und Leistungsschalter usw.
@BeanPublic Routelocator CustomRoutelocator (RoutelocatorBuilder -Builder, ThrottlegatewayFilterFactory -Drossel) .uri ("http://httpbin.org:80") .build (); //@formatter: on}Wenn der Anforderungspfad/Bild/Webp ist, wird die Anforderung an http://httpbin.org:80 weitergeleitet und die Antwort filtriert, wobei der Antwortheader X-Anotherheader: Baz hinzugefügt wird.
Benutzerdefinierte Routing
Die beiden oben genannten Unterabschnitte gehören zum benutzerdefinierten API -Routing und können auch durch Konfiguration definiert werden:
Spring: Cloud: Gateway: Locator: Aktiviert: TRUE Standard-Filter:-AddResponseHeader = X-Response-Default-Foo, Standard-Bar-Routen: # =====================================================ieben =====================================================ieben =====================================================ieben =====================================================ieben
Die obige Konfiguration definiert Routing und Filter. Der globale Filter fügt alle Antworten zum Header X-Response-Default-Foo: Standard-Bar hinzu. Die Route mit ID default_path_to_http ist definiert, die Priorität ist jedoch relativ niedrig. Wenn die Anfrage nicht übereinstimmt, wird sie an Blueskykong.com weitergeleitet.
Kotlin Custom Routing
Das Spring Cloud Gateway kann Kotlin verwenden, um Routing anzupassen:
@ConfigurationClASS assoceRoutes {@Bean Fun tecesselocator (Builder: RoutelocatorBuilder): routelocator = builder.routes {route (id = "test-kotlin") {path ("/image/png") filter {addResponseheader ("x-testheader", "foobar", "foobar", "foobar", "foobar", "foobar", "foobar", "foobar"} ")} URI ("http://httpbin.org:80")}}}Wenn der angeforderte Pfad/Bild/PNG ist, wird er an http://httpbin.org:80 weitergeleitet, und ein Filter wird eingestellt, und ein X-Testheader: Foobar-Header wird seinem Antwortkopf hinzugefügt.
Service Discovery -Komponenten
In Kombination mit der Dienstregistrierung in der Discovery -Komponente wird über ServiceID an die spezifische Serviceinstanz weitergeleitet. Die entsprechenden Abhängigkeiten wurden in der vorherigen Konfiguration eingeführt.
@BeanPublic RouteDefinitionLocator DiscoveryClientRoutEdeFinitionLocator (DiscoveryClient DiscoveryClient) {return New DiscoveryClientRoutEdeFinitionLocator (DiscoveryClient);} Inject DiscoveryClient in den Konstruktor des DiscoveryClientRoutEdeFinitionLocators. Die Quellcodeanalyse wird später erläutert und wird hier nicht erweitert.
Spring: Cloud: Gateway: Locator: Aktiviert: TRUE Standard-Filter:-AddResponseHeader = X-Response-Default-Foo, Standard-Bar-Routen: # =================ieben - Stripprefix = 1
Die obige Konfiguration ermöglicht die Implementierung des DiscoveryClient -Locators. Die Route definiert, dass alle Anfragen, die mit /Benutzer beginnen, an den Benutzerdienst weitergeleitet werden und der Pfadfilter angewendet wird, um den ersten Teil des Pfadpräfixes abzufangen. Die tatsächliche Anfrage zum Zugriff/Benutzer/Test wird in lb: // user/test konvertiert.
Websocket
Sie können auch das Gateway -Routing von WebSocket konfigurieren:
Spring: Cloud: Gateway: Standard-Filter:-AddResponseHeader = X-Response-Default-Foo, Standard-Bar-Routen:-ID: WebSocket_test URI: WS: // localhost: 9000 Bestellung: 9000 Prädikate:-Path =/Echo
Starten Sie einen WS -Server WSCAT -Listen 9000, starten Sie das Gateway (Gateway -Port ist 9090) und verbinden Sie den Client mit WSCAT -Connect WS: // localhost: 9090/echo.
Kundenzugriff
Leser können den Quellcode herunterladen, um die oben genannten Funktionen auszuprobieren. Hier zeige ich nur die Ergebnisse des Zugriffs von Benutzerdiensten:
Das Gateway wurde erfolgreich in den Benutzer-Server ausgelastet und wurde OK zurückgegeben. Der Antwortheader enthält die globale Filtereinstellungen Header X-Response-Default-Foo: Standardleiste
Zusammenfassen
In diesem Artikel untersuchen wir einige Funktionen und Komponenten, die zum Spring Cloud Gateway gehören. Diese neue API bietet außergewöhnliche Tools für Gateway- und Proxy-Unterstützung. Ich freue mich auf die offizielle Version von Spring Cloud Gateway 2.0.
Quellcodeadresse
https://github.com/keets2012/spring-cloud_samples
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, es wird für das Lernen aller hilfreich sein und ich hoffe, jeder wird Wulin.com mehr unterstützen.