This chapter complete source address: Https://github.com/kwang2003/springcloud-study-ch06.git 1. Project Summary The content of this chapter is based on the fifth chapter of the code as a https://github.com/ Kwang2003/springcloud-study-ch05.git. With the increase in the number of micro-services, the complexity of the system is also increasing, through the previous chapters of the study, we have mastered the micro-services through the Eureka Registry +feign/resttemplate Mutual Invocation, if we want to call a series of micro-services in the page how to do. and especially if our various micro services are deployed with multiple nodes, the situation can be even worse, as follows:
The caller of the API needs to understand the IP and port of each micro service deployment, and the implementation of the client's load balancing strategy, when adding or subtracting services, the UI transformation is also very cumbersome, of course, you may also take into account, in the UI and micro-services between the addition of a nginx forwarding a bit can be. Like this
For a small system architecture, this has been completely enough, but the software is changing the most often, when we are faced with an electric business system, in some festivals such as Double 11, the system's access to traffic and pressure will be very large, but the usual level is not so big, A good architecture can spread the flow of the system by scaling the number of deployments of the service nodes--this can be done through the architecture above, which means that we deploy more nodes during the holidays, and configure the new nodes on the Nginx, and after the festival, And then get these nodes off the line---do you think about the experience of the Operation engineer? When the service nodes are hundreds of thousands of times, these configurations rely on manual to complete, the probability of error will increase, or that sentence, can be automatically completed by the computer automatically completed, do not rely on people, so, The protagonist of this chapter Zuul gateway on the debut:
In the whole micro-service architecture, Zuul serves as a service gateway, which provides a unified export for all the micro services in the system, and forwards the request URL to the low-level micro-service in combination with certain routing rules. Zuul is only responsible for routing and forwarding of services, itself does not carry out specific business logic, so it is lightweight, the number of Zuul nodes deployed in the overall architecture is relatively stable, there will be no major changes, therefore, Nginx+zuul this level is relatively fixed, the change is the following micro-services, Here Zuul and specific micro-services through the Eureka Registry indirectly rely on, when the increase/offline micro services, through the Eureka Registry Mutual perception, and do not need to directly configure the Zuul on the specific micro-services, so it can be said that Zuul and micro-services are loosely coupled. In addition to the routing of Micro Services, if we want to do security control of micro-services or interface calls to the logging operations, can be unified processing on the Zuul. 2. Project transformation a) New Springcloud-zuul module
(b) Increased zuul of Maven dependencies added to Springcloud-zuul modules <dependency> <groupid>org.springframework.cloud</groupid > <artifactId>spring-cloud-starter-zuul</artifactId> </dependency> <dependency> < Groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-eureka</ Artifactid> </dependency>
We need to use the Zuul component, so we need to introduce spring-cloud-starter-zuul because we need to zuul get a list of micro-services from the registry Eureka. It is therefore necessary to bring spring-cloud-starter-eureka into the door. C Modify the configuration key is to modify the boot port to 7777, and modify the name of the service and specify the address of the registry Eureka
D Add a startup function Zuulapplication has two important annotations, @EnableZuulProxy to enable Zuul's proxy server functionality, @EnableDiscoveryClient to start the Service Registration Discovery feature Package Com.pachiraframework.springcloud.zuul;
Import org.springframework.boot.SpringApplication; Import org.springframework.boot.autoconfigure.SpringBootApplication; Import org.springframework.cloud.client.discovery.EnableDiscoveryClient; Import Org.springframework.cloud.netflix.zuul.EnableZuulProxy;
@EnableZuulProxy @EnableDiscoveryClient @SpringBootApplication public class Zuulapplication {public static void main ( String[] args) {Springapplication.run (zuulapplication.class, args);}} E The Zuul service can be found in the registry after starting Zuulapplication startup
f) Access Test in the previous case, we accessed through a specific micro-service ip+ port, following http://localhost:8082/user/regist/sms?mobile=1234567895 after the Zuul agent, We can access the http://localhost:7777/user-service/user/regist/sms?mobile=1234567895 via the Zuul ip+ port
Description: At this time, we noticed that we added a User-service context behind the Zuul, which is also the Zuul default proxy routing function, that is, when we access the specific micro-service through the Zuul, we need to add the specific service ID as the context after the Zuul address, Then followed by the specific micro-service access URL, so the request after Zuul, Zuul will be based on User-service this ID to find the corresponding micro-service instances, and then through a certain load-balancing algorithm to elect an available node, The subsequent request connection and parameters are then forwarded to the previous execution.
