Why a service gateway?

We all know that in a microservice architecture, the system is broken up into many microservices. So how do you call so many microservices as a client? Do you want to call them one by one? Obviously this is not practical, we need a unified interface to deal with these microservices, which is why we need a service gateway.

As we have known, in the microservice architecture, different microservices can have different network addresses. Each microservice can call each other to complete user requests, and the client may call N interfaces of microservices to complete a user request. Such as: Users to view a commodity information, it may contain basic information of commodity, price information, reviews, and discount information, inventory information, etc., while the access to information is derived from the different services, such as product, price system, review system, promotion system, inventory system and so on, then to complete the user information to view more than you need to call the service, This leads to several problems:

The client requests different micro-services for multiple times, which increases the complexity of client code or configuration. Authentication is complicated. Each service needs to be authenticated once to access each service

How can we solve these problems? We can try to think about it, do not let the front end directly know the existence of many micro-services in the background, our system itself is divided from the level of business field, forming a number of micro-services, this is the way of processing in the background. For the foreground, the backend should still be like a single application, with one request, so we can add an API gateway between the client and server, and all external requests pass through this microservice gateway first. It only needs to interact with the gateway, and the gateway calls each microservice.

In this way, we can solve the problems mentioned above, simplify development accordingly, and have the following advantages:

Decrease the number of calls for between the client and the service, improve efficiency Facilitate monitoring, monitoring data in the gateway, can do unified aspect task processing For certification, you just need to the gateway for certification, need not every micro service authentication To reduce the complexity on the client invokes the service Here can be associated with a concept, object oriented design of the facade pattern, That is, hiding the details from the client. An API gateway is something similar, just called something different. It is the entrance of the system, encapsulates the internal structure of the application program, and provides unified services for clients. Some common logic unrelated to service functions can be realized here, such as authentication, authentication, monitoring, caching, load balancing, traffic control, routing and forwarding, and so on. Schematic diagram

This section describes the SpringCloud Gateway

  • SpringCloud Gateway is a new Project of SpringCloud, which is based on Spring 5.0, Spring Boot 2.0 and Project Reactor technology development Gateway. It aims to provide a simple and effective unified API route management approach for microservices architecture.

  • As a Gateway in the SpringCloud ecosystem, SpringCloud Gateway aims to replace Zuul. In SpringCloud 2.0 and above, there is no integration with the latest high-performance version of Zuul 2.0 and above. This is still an older version of the non-REACTOR schema used prior to Zuul 2.0. In order to improve the performance of the Gateway, SpringCloud Gateway is implemented based on the WebFlux framework, while the bottom layer of the WebFlux framework uses the high performance Reactor model communication framework Netty.

To sum up, the service gateway has four functions: unified access, traffic control, protocol adaptation, and security maintenance. Among the current Gateway solutions are Nginx+ Lua, Spring Cloud Zuul, and Spring Cloud Gateway. The Spring Cloud Gateway is used as an example.

The goal of the Spring Cloud Gateway is not only to provide a unified routing approach, but also to provide basic Gateway functions such as security, monitoring/metrics, and traffic limiting based on the Filter chain approach.

Pre-announcement: The Spring Cloud Gateway uses a high-performance communications framework called Netty underneath.

SpringCloud Gateway features

SpringCloud official, SpringCloud Gateway features are described as follows:

  1. Based on Spring Framework 5, Project Reactor and Spring Boot 2.0
  2. Integrated Hystrix circuit breaker
  3. Integrate with Spring Cloud DiscoveryClient
  4. Predicates and Filters are easy to write for specific routes
  5. Advanced gateway functions include dynamic routing, traffic limiting, and path rewriting

The main difference between SpringCloud Gateway and Zuul is in the underlying communication framework.

A brief explanation of the three terms above:

Filter:

Similar in concept to Zuul’s filter, it can be used to intercept and modify requests, as well as perform secondary processing on upstream responses.

Filter is org. Springframework. Cloud. Gateway. Filter. GatewayFilter instances of the class.

Route:

The basic components of the gateway configuration module are similar to Zuul’s routing configuration module.

A Route module is defined by an ID, a target URI, a set of assertions, and a set of filters. If the assertion is true, the route matches and the target URI is accessed.

Predicate:

A Java 8 Predicate that can be used to match anything from an HTTP request, such as headers or parameters. The input type for the assertion is a ServerWebExchange.

The core architecture of the SpringCloud Gateway

With the advent of Webflux, the emergence of Webflux fills the gap in Spring’s responsive programming. The responsive programming of Webflux not only changes the programming style, but also provides responsive access development packages for a series of well-known frameworks, such as Netty and Redis.

The Reactor-NetTY responsive programming component in Webflux used by SpringCloud Gateway uses netTY communication framework at the bottom.

The core architecture of SpringCloud Zuul

SpringCloud Zuul’s IO model

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

Servlets are managed by Servlet Containers for their life cycles.

  • When container starts, it constructs a servlet object and calls servlet init() to initialize it.

  • Call servlet destory() to destroy the servlet when the container is closed.

  • The Container runtime accepts the request, allocates a thread to each request (typically free threads from the thread pool) and then calls service().

IO model of servlets

A servlet is a simple network IO model. When a request enters a Servlet Container, the Servlet Container binds a thread to it. This model works well when concurrency is low, but when concurrency increases, the number of threads increases. However, thread resources are expensive (thread switching, high memory consumption) and seriously affect the request processing time.

The servlet model has no advantage in simple business scenarios where you don’t want to assign one thread to each request and only need one or more threads to handle extremely concurrent requests.

Springcloud Zuul is a blocking processing model based on servlets, that is, Spring implements a servlet (DispatcherServlet) that handles all request requests and is handled by the servlet blocking processing.

Springcloud Zuul is not free from the shortcomings of the servlet model. Although Zuul 2.0 uses Netty from the start and there are proven cases of large-scale Zuul 2.0 cluster deployments, there are no official plans for an integrated version of Springcloud.

Webflux server

The Webflux pattern replaces the old Servlet threading model and uses a small number of threads, called Loop threads, to handle request and Response IO operations. The business is handled by a responsive programming framework, which is very flexible. The user can submit the blocking operations in the business to the work thread of the responsive framework for execution, while the non-blocking operations can still be processed in the Loop thread, which greatly improves the utilization rate of the Loop thread. Official structure:

Although Webflux is compatible with multiple underlying communication frameworks, Netty is generally used at the bottom layer. Netty is the communication framework with the highest performance recognized by the industry.

The Loop thread of Webflux is exactly the Reactor thread of the famous Reactor model IO processing model. If the high performance communication framework Netty is used, it is the EventLoop thread of Netty.

The Spring Cloud Gateway process

  1. GatewayClassPathWarningAutoConfiguration function checks whether the configuration we webflux depend on.
  2. GatewayAutoConfiguration loads the classes that our Gateway needs to inject.
  3. GatewayLoadBalancerClientAutoConfiguration gateway need to use a load balancing, Lb / / jarye – member / / name to find the real address according to the service
  4. Redis integrating Lua implementation current-limiting GatewayRedisAutoConfiguration gateway integration
  5. GatewayDiscoveryClientAutoConfiguration service registration and discovery function

  1. The client sends a Http request to the gateway to DispatcherHandler accept the request, matched to the RoutePredicateHandlerMapping.
  2. According to the RoutePredicateHandlerMapping matching to a specific routing strategy.
  3. FilteringWebHandler Obtains the GatewayFilter array of routes and creates a GatewayFilterChain to process filtering requests
  4. Perform our proxy business logic access.

Spring Cloud Gateway source code flow

There are eight filters by default, which are associated in the responsibility chain mode:

SpringCloud Gateway official resource

Source code and cases

  • Github.com/spring-clou…

  • Github.com/spring-clou…

case

  • Spring. IO/projects/sp…