An overview of the

An important component of SpringCloud’s bucket is the gateway, and Zuul gateway is used in 1.x;

However, zuul’s upgrade was delayed in the 2.x version, and SpringCloud finally developed a Gateway to replace Zuul. This is SpringCloud Gateway

SpringCloud GateWay is a new Project of SpringCloud, which is developed based on Spring 5.0 + Spring Boot 2.0 and Project Reactor technology. It aims to provide a unified API route management approach for microservices architecture

Spring Cloud GateWay, as the GateWay of the Spring Cloud ecosystem, is intended to replace Zuul. In Spring Cloud2.0 and above, there is no integration with Zuul 2.0 and above with the highest performance version. The old version of Zuul 1.x non-REACTOR model is still used. In order to improve GateWay performance, Spring Cloud GateWay is implemented based on WebFlux framework. At the bottom of The WebFlux framework is Netty, a Reactor model communication framework with high performance

The goal of the Spring Cloud GateWay is to provide a unified routing and Filter chaining approach to provide basic GateWay functions such as: security, monitoring/metrics, and traffic limiting.

Source architecture

role

  • The reverse proxy
  • authentication
  • Flow control
  • fusing
  • Log monitoring
  • .

The location of a gateway in a microservice architecture

Why did we choose GateWay

  • On the one hand, Zuul 1.0 is already in maintenance, and the GateWay is a trustworthy development by the Spring Cloud team. And Zuul D doesn’t use a lot of features and is very easy to use.
  • GateWay is developed on an asynchronous non-blocking model, and there are no performance concerns, although Netflix has long since released the latest Zuul 2.x, but Spring Cloud seems to have no integration plans. And netflix-related components have announced maintenance periods; What are the prospects?
  • Consider Gateway as an ideal Gateway choice

The Spring Cloud Gateway has the following characteristics:

  • Based on Spring Framework5. Project Reactor and Spring Boot 2.0.
  • Dynamic routing: can match any request attribute;
  • You can specify Predicate and Filter routes
  • Integrated Circuit breaker function of Hystrix;
  • Integrate Spring Cloud service discovery
  • Depression makes Predicate and Filter.
  • Request flow limiting empathy
  • Path rewriting is supported.

Difference between Gatway and Zuul

Prior to the official release of SpringCloud Finchley, the recommended gateway for SpringCloud was Zuul provided by Netflix

  1. Zuul 1.x is an API Gateway based on blocking I/0
  2. Zuul 1.x is based on Servlet 2.5 and uses a blocking architecture. It does not support any persistent links (such as websockets). Zuul’s involvement pattern is similar to Niginx, in that each I / 0 operation is executed from a worker thread. However, the difference is that Nginx uses a C++ implementation and Zuul uses a Java implementation, and the JVM itself has a slow first load, resulting in relatively poor Zuul performance
  3. The zuul2.x ideal is more of a trap, with Netty non-blocking and support understandable, but SpringCloud currently has no integration. The performance of Zuul2.x is significantly improved over zuul1.x. In terms of performance, Spring Cloud Gateway’s RPS (requests per second) is 1.6 times higher than Zuul’s, according to official benchmarks
  4. The Spring Cloud Gateway builds on Spring Framework5, Project Reactor, and Spring Boot 2 and uses a non-blocking API.
  5. The Spring Cloud Gateway also supports WebSocket and is tightly integrated with Spring for a better development experience.

Zuul1. X model

Zuul, which is integrated in Springcloud, uses the Tomcat container and uses the traditional Servlet IO processing model.

Servlets are managed by Servlet Containers for their life cycles.

  • When container starts, the servlet object is constructed and initialized by calling servlet init ().
  • The Container runtime accepts the request, allocates a thread for each request (typically free threads from the thread pool) and then calls service ()
  • The servlet destory () is called to destroy the servlet when the container is closed

Disadvantages of the above model:

A servlet is a simple network I/O model that binds a thread to the current request when it enters a servlet Container. This model works well in low-concurrency scenarios. However, once in high concurrency (such as with JMeter pressure test), the number of threads will increase, and the thread resource cost is expensive (context switch, high memory consumption) seriously affects the request processing time. In some simple business scenarios, you don’t want to assign a single thread to each request and only need one or more threads to handle a large number of concurrent requests. The servlet model has no advantage in this scenario.

So zuul1.x is a blocking processing model based on Servlet IQ, that is, Spring implements a servlet (DispatcherServlet) that handles the request from the lock fish and blocks it. As a result, SpringCloud Zuul cannot get rid of the shortcomings of the servlet model.

The Gateway model

Traditional Web frameworks, such as Struts2, SpringMVC, etc., run on top of Servlet APIS and Servlet containers. But asynchronous non-blocking support came with Servlet3.1. WebFlux is a typical non-blocking asynchronous framework, and its core is based on Reactor API. Compared to traditional Web frameworks, it can run on containers such as Netty, Undertow, and Servlet3.1. Non-blocking + functional programming (Spring5 must use java8).

Spring WebFlux is a new responsive framework introduced in Spring 5.0. Unlike SpringMVC, it does not rely on the Servlet API, is completely asynchronous and non-blocking, and is based on Reactor to implement the responsive flow specification.

The service gateway

GetWay

GetWay is an API gateway service built on top of the Spring ecosystem, based on technologies such as Spring 5, Spring Boot 2, and Project Reactor. Gateway is designed to provide a simple and efficient way to route apis, as well as powerful filter features such as fuses, traffic limiting, retry, and so on

Three core concepts

Routing: A route is the basic building block of a gateway. It consists of an ID, a destination URL, a set of assertions, and filters that match the route if the assertion is true

Asserts that the reference is Java8 Java. Util. Funcation. The Predicate, the developer can match all the content in the HTTP request (for example, request or request parameters), if the request is match the assertion is routed

Filtering: Refers to an instance of GateWayFilter in the Spring framework, which allows requests to be modified before or after they are routed

The overall

The Web request, through some matching criteria, locates the real service node and performs some fine control before and after the forwarding process. Predicate is our matching condition; A filter, on the other hand, can be interpreted as an omnipotent interceptor. With these two elements, and the destination URL, a specific route can be implemented.

The working process

The client makes a request to the Spring Cloud Gateway. The route matching the request is then found in GateWay Handler Mapping and sent to the GateWay Web Handler.

The Handler then sends the request through the defined filter chain to our actual service to perform the business logic, and then returns. The filters are separated by dashed lines because the filter may perform business logic before (“pre”) or after (” POST “) the proxy request is sent.

Filter of the ‘Pre’ type can be used for parameter verification, wandering monitoring, log output, protocol conversion, etc. Filter of the ‘POST’ type can be used for response content and response header modification, log output, traffic monitoring, etc.

Write technology, talk about fitness, talk about society, say life, this world is worth studying. Welcome to pay attention! This article is published by OpenWrite, a blogging tool platform