Spring Cloud Learning Notes-009

• API Gateway Service: Spring Cloud Zuul

API Gateway is a more intelligent application server, it is similar to the definition of façade pattern in object-oriented design pattern, it exists as the façade of the entire microservices architecture system, all external client access needs to be dispatched and filtered. In addition to the implementation of request routing, load balancing, checksum filtering and other functions, but also need more capabilities, such as the integration with the Service governance framework, request forwarding of the fuse mechanism, the aggregation of services, and a series of advanced features.

The API Gateway component--spring Cloud Zuul, based on the Netflix Zuul implementation, is available in Spring cloud.

First, for the maintenance of routing rules and Service instances. Spring Cloud Zuul integrates itself with the spring Cloud Eureka to register itself as an application under Eureka service governance, while obtaining instance information for all other microservices from Eureka. This kind of design skillfully uses the instance information maintained in the service governance system, and gives the service management framework automatic completion, which eliminates the need for manual intervention. For the maintenance of routing rules, Zuul by default will create a route map by using the service name as a contextpath, in most cases, such default settings can already achieve most of our routing needs, In addition to some special cases (such as the compatibility of some old URLs) there are some special configurations. However, the implementation of the API gateway through the introduction of Spring Cloud Zuul has been significantly reduced compared to the operational workload of the previous architecture.

Second, for similar signature check, login check in microservices architecture redundancy problem. In theory, these check logic essentially does not have much to do with the services of the microservices application itself, so they can be completely independent of the existence of a single service, except that they are stripped and detached, not for each micro-service invocation, Instead, a unified tune on the API Gateway Service is used to pre-filter the MicroServices interface to intercept and verify the micro-service interface.

1. First, build several microservices applications for routing and filtering, but use the previous registry and Demo-member, Demo-customer-feign, to start three applications respectively.

2. Create Maven project, skeleton Select QuickStart, named: Demo-api-gateway.

3. Introduce dependent dependencies in the Pom.xml file:

4. Create a Startup class:

5. Create the Application.yml file in the Src\main\resources directory:

6. Enter the registration center and observe the services started:

7. Add the Eureka dependency in the Demo-api-gateway pom.xml file and specify the Eureka location and the configuration for routing in the Application.yml file:

8. Start the Demo-api-gateway service, initiating the following request to the gateway:

Http://localhost:5217/api-a/member: The URL conforms to the/api-a/** rule, which is forwarded by the Api-a route, the Serviceid of the route map is Member-service, and all final/ Member requests are sent to an instance of the Member-service service.

Http://localhost:5217/api-b/getMember: The URL conforms to the/api-b/** rule, which is forwarded by the Api-b route, and the Serviceid of the route map is Customer-service-feign, All final/getmember requests are sent to an instance of the Customer-service-feign service.

With service-oriented routing configuration, we do not need to maintain the location of the specific instances of the MicroServices application for each route, but rather by combining a simple path-to-serviceid mapping, the maintenance is made very simple. This is entirely due to the spring Cloud Eureka Service discovery mechanism, which enables the API Gateway service to automate the maintenance of the service instance manifest, which perfectly solves the problem of maintenance of the routing map instance.

• Request filtering

Zuul allows developers to intercept and filter requests by defining filters on the API gateway, simply inheriting the Zuulfilter abstract class and implementing the 4 abstract methods it defines to intercept and filter requests.

The following implementation of a simple Zuul filter, it implements the re-request is routed before checking if there is a token parameter in HttpServletRequest, if there is a route, if not denied access, return 401 unauthorized error.

1. Define the Accessfilter class and integrate the Zuulfilter:

Noun Explanation:

FilterType: The method needs to return a string to represent the type of the filter, which is the various stages defined during the HTTP request. The filter types for 4 different life cycles are defined by default in Zuul:

Pre: can be called before the request is routed.

Routing: Called when a request is routed.

Post: Called after the Routing and error filters.

Error: Called when a request is processed when a fault occurs.

Filterorder: Defines the order in which the filters are executed by an int value, and the smaller the value the higher the priority.

Shouldfilter: Returns a Boolea value to determine if the filter is to be executed. You can specify a valid range of filters by this method.

Run: The specific logic of the filter, in which the custom filter logic can be implemented to determine whether to intercept the current request, not to follow the route, or to do some processing after the request route returns the result.

2. After a custom filter is implemented, it does not take effect directly, and you need to create a specific bean for it to start the filter, adding the following in the startup class:

3. Restart the Gateway project and initiate the following request to verify the filter defined above:

Http://localhost:5217/api-a/member: Returns a 401 error.

Http://localhost:5217/api-a/member?token=123: Correctly routed to the Member-service/member interface and returns the appropriate content.

• Other

The integration of Eureka and Zuul has eliminated the need to maintain a large number of configuration tasks for the service instance list, leaving only the mapping of matching expressions and service names for the request path to be maintained. However, in the actual use of the process will find that most of the routing configuration rules will almost use the service name as an external request prefix, such as the above Member-seriver, and the corresponding service name is Member-service

For such a regular configuration content, we always want to be able to automate the completion. Zuul does this by default, and it automatically creates a default routing rule for each service in Eureka when the spring cloud Zuul Build API Gateway service introduces Spring Cloud Eureka. The path of these default rules uses the service name configured by Serviceid as the request prefix, such as the routing configuration rules described above, which can be commented out directly:

To restart the Gateway service, you can use the service name as a prefix for the invocation of the service:

For version management, when microservices have different versions, such as MEMBERSERVICE-V1, of course, the microservices name can be used to differentiate between different versions, thus invoking each version of the service, but the resulting expression rules are relatively single, not conducive to the use of path rules to manage. It is common practice to generate routing rules defined as the route prefix for these different versions of the MicroServices application, such as/v1/meberservie/. By this time, with a URL path with a version number prefix, we can easily categorize and manage these new versions of microservices with a path expression.

To do this, first stop the Member-service service and change its service name to Memberservice-v1, and then start the service. In the startup class for the Gateway service, add the following code:

Restart the Gateway service and access the test in the browser:

• Gateway Summary

It acts as a unified entrance to the system, shielding the details of each micro-service within the system.

It can be combined with the service governance framework to achieve automated service instance maintenance and load-balanced routing and forwarding.

It can realize the decoupling of interface privilege check and micro service business logic.

Through the Service Gateway filter, in each life cycle to verify the content of the request, the original service layer to do the check forward, to ensure the non-state of microservices, while reducing the micro-service testing difficulty, so that the service itself more focused on business logic processing.

Spring Cloud Learning Notes-009