spring cloud understands the components and call relations from the perspective of operation and maintenance

summary

background

Evolution of application framework

1. Single application architecture
2. Vertical application architecture
3. Distributed service architecture
4. Flow computing architecture

Microservice

The concept of Microservices originated from an article "Microservices" written by Martin Fowler in March 2014.
Microservice architecture is a kind of architecture mode, which advocates that a single application can be divided into a group of small services, and services can coordinate and cooperate with each other to provide the ultimate value for users. Each service runs in its own process and uses lightweight communication mechanism (usually HTTP based RESTful API) to communicate with each other between services. Each service is built around a specific business, and can be independently deployed to the production environment, class production environment, etc. In addition, we should try to avoid a unified and centralized service management mechanism. For a specific service, we should select the appropriate language and tools to build it according to the business context.
Microservice is an architectural style. A large complex software application consists of one or more microservices. Each microservice in the system can be deployed independently, and each microservice is loosely coupled. Each microservice focuses on only one task and accomplishes it well. In all cases, each task represents a small business capability.

spring boot

Spring Boot is a new framework provided by the Pivotal team, which is designed to simplify the initial construction and development process of new spring applications. The framework uses a specific way to configure, so that developers no longer need to define a templated configuration.
Spring Boot is not a new framework. By default, it configures the use of many frameworks. For example, maven integrates all jar packages and Spring Boot integrates all frameworks (I don't know if this metaphor is appropriate).
Spring Boot simplifies the application development based on spring, and creates an independent, product level spring application with a small amount of code. Spring Boot provides out of the box settings for the spring platform and third-party libraries, so you can start in an orderly manner.
The core idea of Spring Boot is that convention is greater than configuration. Most Spring Boot applications only need a few Spring configurations. Adopting Spring Boot can greatly simplify your development mode. All the common frameworks you want to integrate have corresponding component support.

spring cloud

Spring Cloud is an orderly collection of frameworks. It makes use of the development convenience of Spring Boot to ingeniously simplify the development of distributed system infrastructure, such as service discovery registration, configuration center, message bus, load balancing, circuit breaker, data monitoring, etc., all of which can be started and deployed with one click using the development style of Spring Boot.
Spring Cloud doesn't make wheels repeatedly. It just combines the mature and practical service frameworks developed by various companies, encapsulates and shields the complex configuration and implementation principles through the Spring Boot style, and finally leaves a set of simple, easy to understand, easy to deploy and easy to maintain distributed system development kit for developers.

characteristic

• spring cloud focuses on typical use cases and extensibility mechanism coverage that provide good out of the box experience
• Distributed / versioned configuration
• Service registration and discovery
• route
• Service to service call
• load balancing
• Break route
• Distributed messaging

assembly

spring cloud config

• Remote configuration service.
• Remote configuration is an essential middleware for each. The characteristics of remote configuration generally need: multi node active standby, configuration, dynamic modification, configuration of localized cache, real-time push of dynamic modification, etc.
• config allows configuration files to be placed on git or svn, which is very easy to integrate with spring boot. However, the disadvantage is that after the configuration on Git is modified, only one interface can be requested for each service to update the configuration, which needs to be used together with message bus and queue junction

spring cloud bus

• Event, message bus, used to propagate state changes in a cluster (for example, configuration change events). Often used in conjunction with Spring Cloud Config.
• spring cloud config itself cannot provide push of real-time updates to registered services. For example, if our configuration is on git, when we modify the configuration content on github, we can configure webhook to a config server at most, but config server will not push the configuration update to each service in real time.
• The function of bus is to link everyone on a bus. All servers on this line share the same state. When webhook is connected to a server on the bus, other servers will receive the same hook state. However, the use of bus depends on MQ. Bus inherits rabbitmq & Kafka directly, and only needs to configure address directly in spring

eureka

• The service discovery component of spring cloud.
• eureka is responsible for service registration and service discovery. In order to be highly available, multiple eureka servers are generally required to register with each other to form a cluster. The synchronization of eureka server follows a very simple principle: as long as there is one side connecting the nodes, information dissemination and synchronization can be carried out.
• The registered service in eureka mainly monitors whether the service has been hung up by heartbeat. The default heartbeat time is 15s. This means that when a service provider hangs up, the service subscriber may not find out until 30 s later.
• After the service is started and connected to eureka, a service list will be synchronized to the local cache. When there is an update in the service registration, eureka will be pushed to each service.
• eureka also has some strategies to prevent the avalanche phenomenon that all services' heartbeat stops due to the instability of the network where a service is located.
• eureka has its own web page, on which you can see all the service registration and eureka cluster status.
  *eureka supports the service to drop itself. By requesting the following address of the service, the service can drop itself from eureka. At the same time, the service process will stop itself.
  curl -H 'Accept:application/json' -X POST localhost:$/shutdown

consul

• It is also a service discovery tool with key value storage service, health check and web page.
• Consumer provides the official docker image. If you directly use the docker consumer cluster user service discovery, the operation and maintenance cost will drop in a straight line

ribbon

• Client load balancing component.
• After the service discovery, each service locally knows how many machines it wants to call, what is the ip address of the machine, and what is the port number. Then the service locally needs to have a load balancing strategy, which is to select a target machine for each request to call. What ribbon does is to select the load balancing strategy.
• Ribbon provides a variety of load balancing strategies, including BestAvailableRule, availabilityfiltering rule, WeightedResponseTimeRule, RetryRule, roundrobin rule, RandomRule, zoneavodiacerule, etc. if you remember correctly, the default is zoneavodiacerule. Of course, you can also customize your own load balancing strategy. For example, if the called service needs gray-scale publishing or A/B testing, you can customize it in the ribbon layer.

feign

• A declarative, templated HTTP client.
• The essence of calling between microservices is still http request. If you need to write request code for each request, add request parameters, and process the request results at the same time, there will be a lot of repetitive work. Feign is very elegant to help us solve this problem. Just define an interface, feign will know how to set the parameters when http request.
  At the same time, feign also integrates the ribbon. As long as it depends on the ribbon in the micro service, feign will use the load balancing strategy defined by the ribbon by default.
• Feign is not only used in the micro service system with eureka or ribbon. In any system, as long as it involves http calling a third-party service, feign can be used to help us solve the code duplication of http requests.

hystrix

• Circuit breaker, similar to circuit breaker in physical circuit diagram.
• Under normal circumstances, when a service provider responds very slowly due to network, database or performance reasons in the whole service environment, the caller may accumulate a large number of request threads in a short period of time, eventually causing the caller to down, or even the whole system to crash. After joining hystrix, if hystrix finds that a machine call of a service is very slow or fails many times, it will break this path in a short time, and all requests will not be sent to this machine again.
• If all the machines of a service hang up, hystrix will fail quickly and return immediately to ensure that the callee will not have a large number of threads.
• Feign integrates hystrix by default.
  *As mentioned above, when using eureka, when a service provider hangs up, the service subscriber may not know for 30 s at most, then there will be a lot of call failures in this 30 s. If hystrix is integrated in the system, the suspended service provider will be disconnected immediately, so that the request will not be forwarded to this machine, and the call failure will be greatly reduced.
• After the hystrix performs the open circuit operation, it does not mean that the path will be broken forever, but will slowly try to request the path within a certain time interval. If the request is successful, the open circuit will be restored.

zuul

• Is a gateway component. Provide the framework of dynamic routing, monitoring, flexibility, security and other edge services.
• Zuul master needs to simply configure the properties file, and can forward the request to the corresponding service without writing specific code. You can also customize some filter s for verification, isolation, current restriction, file processing and other aspects. For gateways, zuul can reduce a lot of code.

turbine

• It is a tool for aggregate server to send event flow data, which is used to monitor the metrics of hystrix under cluster
• In a complex distributed system, the nodes with the same service often need to deploy hundreds or even thousands of nodes. In many cases, the operation and maintenance personnel hope to show the node status of the same service in the form of an overall cluster, so that they can better grasp the status of the whole system.
• Turbone provides multiple hystrix.stream The content of is aggregated into a data source for display by Dashboard

Spring Cloud Starters

• spring boot hot plug, provides default configuration, and out of the box dependencies.
• Starter is a very basic part of the spring boot framework. You can customize the starter.

Presentation notes

About code

The component function implementation of spring cloud is basically based on Java code implementation. From the perspective of operation and maintenance, you need to understand the operation mechanism and the yard. For the specific implementation, please refer to the cloned java code

About profiles

• boostrap.yml ( bootstrap.properties )It is used to execute when the program is booted and to read configuration information in earlier period. For example, it can be used to configure application.yml Parameters used by middle peasants
• application.yml ( application.properties )Application specific configuration information, which can be used to configure the common parameters to be used in subsequent modules, etc
• bootstrap.yml Salted fish application.yml load
• There are two configuration files under src/main/resources / of maven directory structure. One is application.properties , the other is application.yml , both of which can be used to configure the definition and parameter setting of some variables in the springboot project
• Generally, there are multiple configuration files (multiple environments). Generally, when the application is started, the configuration files to be started are specified

About starting

In the demonstration, the following two startup modes are available

1. Pack and run
   mvn clean package
   java -jar target/xxxx.jar
2. Run the spring boot project directly
   mvn spring-boot:run

About directories and addresses

The address and directory used in the demonstration are for reference. The specific allocation can be set according to the actual directory and ip address

Eureka components

Eureka is a service discovery framework developed by Netfix. Spring cloudeureka is a sub project of spring cloudnetfix. It encapsulates Eureka twice. By adding the automatic configuration of spring boot style to Eureka, we need to simply introduce dependency and annotation to easily integrate the microservice application built by spring boot with Eureka service governance system.

structure

The above figure briefly describes the basic architecture of Eureka, which consists of three roles:

• Eureka Server: provide service registration and discovery
• Service Provider: a Service Provider that registers its services with Eureka so that service consumers can find
• Service Consumer: Service Consumer. Obtain the list of registered services from Eureka, so as to consume services.

###It should be noted that the three roles in the above figure are all logical roles. In practice, these roles can even be the same instance

Create Eureka registry

Stand alone demonstration

[root@localhost ~]# git clone https://github.com/luojunyong/spring-cloud-examples.git Cloning into 'spring-cloud-examples'... remote: Enumerating objects: 700, done. remote: Total 700 (delta 0), reused 0 (delta 0), pack-reused 700 Receiving objects: 100% (700/700), 67.17 KiB | 3.00 KiB/s, done. Resolving deltas: 100% (208/208), done. [root@localhost ~]# cd spring-cloud-examples/spring-cloud-eureka/spring-cloud-eureka [root@localhost spring-cloud-eureka]#

[root@localhost spring-cloud-eureka]# vim src/main/resources/application.properties spring.application.name=spring-cloud-eureka #App name server.port=8000 #Listening port eureka.client.register-with-eureka=false #Whether to register yourself with eureka server? true by default eureka.client.fetch-registry=false #Whether to obtain registration information from eureka server? true by default eureka.client.serviceUrl.defaultZone=http://localhost:8000/eureka/ #Set the address to interact with eureka server

Package and run

[root@localhost spring-cloud-eureka]# mvn clean package [root@localhost spring-cloud-eureka]# java -jar target/spring-cloud-eureka-0.0.1-SNAPSHOT.jar //After running, it will block. Under such lines of code, there are the words start and running 2019-01-31 18:41:44.556 INFO 5853 --- [ main] com.neo.SpringCloudEurekaApplication : Started SpringCloudEurekaApplication in 17.553 seconds (JVM running for 18.766) 2019-01-31 18:42:44.349 INFO 5853 --- [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry : Running the evict task with compensationTime 0ms [root@localhost spring-cloud-eureka]# firefox 127.0.0.1:8000

Eureka cluster

If it is a single node, it is destructive to encounter a fault. In a distributed system, service registry is the most important basic part, which should be able to provide service status at any time. In order to maintain its availability, using clusters is a good solution. eureka implements highly available deployment through mutual registration, so we only need to client.serviceUrl Configuring other available eureka nodes enables high availability deployment.

Server planning

• The two servers clone the demo code respectively, and application.properties Inside client.serviceUrl Point to the opposite end and enable the application registration function
• Two servers bind hosts respectively, corresponding to the host name

Clone demo code (same for both hosts)

[root@localhost ~]# git clone https://github.com/luojunyong/spring-cloud-examples.git Cloning into 'spring-cloud-examples'... remote: Enumerating objects: 700, done. remote: Total 700 (delta 0), reused 0 (delta 0), pack-reused 700 Receiving objects: 100% (700/700), 67.17 KiB | 3.00 KiB/s, done. Resolving deltas: 100% (208/208), done. [root@localhost ~]# cd spring-cloud-examples/spring-cloud-eureka/spring-cloud-eureka [root@localhost spring-cloud-eureka]#

Bind hosts (two servers operate the same)

[root@localhost spring-cloud-eureka]# vim /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.43.249 eureka1 192.168.43.74 eureka2

Modify profile

Node 1 [root@localhost spring-cloud-eureka]# vim src/main/resources/application.properties spring.application.name=spring-cloud-eureka server.port=8000 #eureka.client.register-with-eureka=false #eureka.client.fetch-registry=false eureka.instance.hostname=eureka1 #Current instance host name eureka.client.serviceUrl.defaultZone=http://eureka2:8000/eureka / ා set the address to interact with eureka server //Node 2 [root@localhost spring-cloud-eureka]# vim src/main/resources/application.properties spring.application.name=spring-cloud-eureka server.port=8000 #eureka.client.register-with-eureka=false #eureka.client.fetch-registry=false eureka.instance.hostname=eureka2 eureka.client.serviceUrl.defaultZone=http://eureka1:8000/eureka/

Pack and start (same for both hosts)

[root@localhost spring-cloud-eureka]# mvn clean package [root@localhost spring-cloud-eureka]# java -jar target/spring-cloud-eureka-0.0.1-SNAPSHOT.jar

Cluster effect
Browser access to any node
firefox 127.0.0.1:8000

Once in protected mode, Eureka Server will try to protect the information in its service registry and no longer delete the data in the service registry (that is, no microservices will be logged out).

More nodes

In production, we may need three or more registration centers to ensure the stability of services. The principle of configuration is the same. The registration center's client.serviceUrl Point to other registration centers respectively.

About multiple profiles

Distinguish configuration files between different environments or different hosts, and multiple application.properties , which can be specified when restarting.
For example: establish application at the same time- dev.properties And Application- online.properties , you only need to specify
java -jar spring-cloud-eureka-0.0.1-SNAPSHOT.jar --spring.profiles.active=dev
java -jar spring-cloud-eureka-0.0.1-SNAPSHOT.jar --spring.profiles.active=online

About Eureka address call

Although we are using cluster now, when our service provider is registered, it should be that all nodes will have this service provider, even if one is hung, it doesn't matter. However, if the registration center specified by our service provider is already hung when registering, then it cannot be registered, and other nodes will not be synchronized to the registration information. Therefore, it is recommended to write all nodes when calling:
eureka.client.serviceUrl.defaultZone=http://192.168.43.249:8000/eureka,http://192.168.43.74:8000/eureka

Service provision and consumption

Service provider

The service provider has a hello method that can provide a service that outputs "hello xxx, this is first message" according to the parameters passed in. Here we dome two service providers at the same time on different servers

On the basis of the above experiment, do not interrupt the project, open another terminal to continue operation, the operation of the two servers is the same

#Enter the directory of the cloned code [root@localhost spring-cloud-eureka]# cd /root/spring-cloud-examples/eureka-producer-consumer/spring-cloud-producer/

Modify profile application.properties The two servers operate the same

[root@localhost spring-cloud-producer]# mvn clean package [root@localhost spring-cloud-producer]# java -jar target/spring-cloud-producer-0.0.1-SNAPSHOT.jar //Node 1 access test: firefox 192.168.43.249:9000//hello?name=junyong //Node 2 access test: firefox 192.168.43.74:9000/hello?name=junyong

Service consumers

[root@localhost ~]# cd spring-cloud-examples/eureka-producer-consumer/spring-cloud-consumer/

Modify profile application.properties

[root@localhost spring-cloud-consumer]# vim src/main/resources/application.properties spring.application.name=spring-cloud-consumer server.port=9001 eureka.client.serviceUrl.defaultZone=http://192.168.43.249:8000/eureka/,http://192.168.43.74:8000/eureka

[root@localhost spring-cloud-consumer]# mvn clean package [root@localhost spring-cloud-consumer]# java -jar target/spring-cloud-producer-0.0.1-SNAPSHOT.jar [root@localhost spring-cloud-consumer]# curl http://192.168.43.249:9001/hello/junyong hello junyong，this is first messge [root@localhost spring-cloud-consumer]# curl http://192.168.43.249:9001/hello/junyong hello junyong，this is first messge from producer1 [root@localhost spring-cloud-consumer]# curl http://192.168.43.249:9001/hello/junyong hello junyong，this is first messge [root@localhost spring-cloud-consumer]# curl http://192.168.43.249:9001/hello/junyong hello junyong，this is first messge from producer1

At this time, you can log in to port 8000 on either of the two servers to check the server status and port, as shown in the following figure

The demonstration code has integrated feignclient feign, including ribbon, and uses the default polling load balancing mode, as shown in the above access test results

• A service registry with port 8761 of eureka server
• The micro service project runs two copies, with ports of 8082 and 8083 respectively, which are registered with the service registry
• When micro client calls hello interface of micro service through restTemplate, it will call micro in turn because of load balancing with ribbon- service:8082 And 8083 two port hello interface
• restTemplate should be misspelled in the figure

Consumer needs to modify java code

[root@localhost spring-cloud-consumer]# vim src/main/java/com/neo/controller/ConsumerController.java //Add another class public class LoadBalanced { @Bean public IRule ribbonRule() { return new RoundRobinRule(); //polling //return new WeightResponseTimeRule(); / / weighted weight //Return new returnrule(); / / polling with retry mechanism //return new RandomRule(); / / random //return new TestRule(); / / custom rule } }

Hystrix components

Avalanche effect

In IO services, suppose that service A depends on service B and Service C, while service B and Service C may continue to rely on other services, which will make the call link too long

If one or several called subservices on A link are unavailable or have high latency, the request to call A service will be blocked. Blocked requests will consume the system's threads, io and other resources. When more and more such requests occupy more and more computer resources, it will lead to system bottlenecks, and other requests are also unavailable, resulting in business system crash, also known as avalanche effect.

Solution

hystrix provides fusing mode and isolation mode to solve or link avalanche effect. When service access fails, it can reduce the impact range of blocking and avoid the whole service being dragged down.

The circuit breaker can realize fast failure. If it detects many similar errors (such as timeout) in a period of time, it will force its subsequent multiple calls to fail quickly, and no longer request the services it depends on, so as to prevent the application from constantly trying to perform the operations that may fail, so that the application can continue to execute without waiting for the error to be corrected, or wasting C Pu time to wait for a long timeout. The circuit breaker also enables the application to diagnose whether the error has been fixed, and if so, the application attempts to invoke the operation again.

Feign Hystrix

Because the fusing only works at the service invocation end, we only need to change the relevant code of spring cloud consumer project. Because feign already relies on hystrix, there is no need to change the maven configuration

application.properties Open in feign.hystrix , add the specified fallback class, and return the contents of the fallback class when the service is broken. Currently, it operates on only two servers. The services of 8000 port and 9000 port of the two servers are running unchanged. In this way, the registry is running and the producer is running. Stop the consumer on the first server of the last experiment.

The next operation is still performed on the first server, that is, the host of 249

[root@localhost spring-cloud-consumer]# cd /root/spring-cloud-examples/spring-cloud-hystrix/spring-cloud-consumer-hystrix/ //Modify the code to confirm that there is a fallback class to return that the service is not available [root@localhost spring-cloud-consumer-hystrix]# vim src/main/java/com/neo/remote/HelloRemoteHystrix.java package com.neo.remote; import com.neo.remote.HelloRemote; import org.springframework.stereotype.Component; import org.springframework.web.bind.annotation.RequestParam; /** * Created by summer on 2017/5/15. */ @Component public class HelloRemoteHystrix implements HelloRemote{ @Override public String hello(@RequestParam(value = "name") String name) { return "hello " +name+", this messge send failed "; } } //I found that the code has been written. Let's continue with the following operations [root@localhost spring-cloud-consumer-hystrix]# vim src/main/resources/application.properties spring.application.name=spring-cloud-consumer-hystrix #App name server.port=9001 feign.hystrix.enabled=true #Enable hystrix fusing eureka.client.serviceUrl.defaultZone=http://192.168.43.249:8000/eureka/,http://192.168.43.74:8000/eureka

[root@localhost spring-cloud-consumer-hystrix]# mvn clean package [root@localhost spring-cloud-consumer-hystrix]# java -jar target/spring-cloud-consumer-hystrix-0.0.1-SNAPSHOT.jar

• Default load balancing polling mode when all nodes are normal

[root@localhost spring-cloud-consumer-hystrix]# curl http://192.168.43.249:9001//hello/luojunyong hello luojunyong，this is first messge [root@localhost spring-cloud-consumer-hystrix]# curl http://192.168.43.249:9001//hello/luojunyong hello luojunyong，this is first messge from producer1

• Stop the producer service of the first server, and provider 2 returns data

[root@localhost spring-cloud-consumer-hystrix]# curl http://192.168.43.249:9001//hello/luojunyong hello luojunyong，this is first messge [root@localhost spring-cloud-consumer-hystrix]# curl http://192.168.43.249:9001//hello/luojunyong hello luojunyong，this is first messge

• Two producer s, return hystrix data, fuse succeeded

[root@localhost spring-cloud-consumer-hystrix]# curl http://192.168.43.249:9001//hello/luojunyong hello luojunyong, this messge send failed [root@localhost spring-cloud-consumer-hystrix]# curl http://192.168.43.249:9001//hello/luojunyong hello luojunyong, this messge send failed

Hystrix Dashboard

Hystrix dashboard is mainly used to monitor the indicators of hystrix in real time. Through the real-time information fed back by hystrix dashboard, we can quickly find the problems in the system

Consumer startup class add enable systrix dashboard and fuse

[root@localhost spring-cloud-consumer-hystrix]# cd /root/spring-cloud-examples/hystrix-dashboard-turbine/spring-cloud-consumer-hystrix-dashboard/ [root@localhost spring-cloud-consumer-hystrix-dashboard]# vim src/main/resources/application.properties spring.application.name=spring-cloud-consumer-hystrix-dashboard server.port=9001 feign.hystrix.enabled=true eureka.client.serviceUrl.defaultZone=http://192.168.43.249:8000/eureka/,http://192.168.43.74:8000/eureka [root@localhost spring-cloud-consumer-hystrix-dashboard]# mvn clean package [root@localhost spring-cloud-consumer-hystrix-dashboard]# java -jar target/spring-cloud-consumer-hystrix-dashboard-0.0.1-SNAPSHOT.jar

Visit the dashboard page: http://192.168.43.249:9001/hystrix

Tips on the launch page:

• If viewing the default cluster, use: http://turbine-hostname:port/turbine.stream
• To view the specified cluster, use: http://turbine-hostname:port/turbine.stream?cluster=[clusterName]
• Monitoring of a single application, using: http://hystrix-app:port/hystrix.stream

We are here to monitor a single application, input in the input box http://192.168.43.249:9001/hystrix.stream
After input, click the [monitor stream] button, fill it in as shown in the figure above, and enter the monitoring as shown in the figure below

Data testing
In the normal case of producer, the consumer requests several times, and then the data collection shows the access http://192.168.43.249:9001/hystrix.stream

error test
Stop the producer, make the consumer request less than the content, and then view the monitoring page

Turbine components

• Aggregate monitoring

There is not much value in looking at the data of a single hystrix dashboard. To look at the data of the system's hystrix dashboard, you need to use the hystrix turbine, which integrates the dashboard data of each service
In the distributed system, the nodes with the same service often need to deploy hundreds or even thousands of nodes. In many cases, the operation and maintenance personnel hope to show the node state of the same service in the form of an overall cluster, so as to better grasp the state of the whole system. For this purpose, Netflix provides an open source project, turbine, to provide multiple hystrix.stream The content of is aggregated into a data source for display by the dashboard

ZUUI components

• In the service architecture, the back-end services are often not directly open to the caller, but are routed to the relevant services through an API network management according to the requested url
• zuul routing is an indispensable part of microservice architecture, which provides dynamic routing, monitoring, flexibility, security and other edge services. zuul is a load balancer based on JVM routing and services produced by Netflix
• zuul needs a simple configuration. The properties file can forward the request to the corresponding service without writing specific code
• Customize some filter s for verification, isolation, current restriction, file processing, etc. for gateways, using zuul can reduce a lot of code
• Zuul, as a gateway layer, is also a micro service. Like other services, zuul is registered in Eureka On the server, you can find out which services zuul can perceive online. At the same time, by configuring routing rules, zuul can automatically forward requests to the specified back-end microservices. For some public preprocessing (such as permission authentication and token validity verification), it can be placed in the so-called zulfilter. In this way, the back-end services will add services later, zuul Layers are almost unmodified

Presentation notes

1. Because the gateway server is dealing with all external requests, in order to avoid potential security risks, we need to make certain restrictions on the request. For example, if the request contains a token, the request will continue to go down. If the request does not have a token, it will directly return and give a prompt token is empty
2. Custom fallback method, and assign it to a route to implement the fuse handling of the route access problems. It is mainly implemented by inheriting zulfallback interface. Zulfallbackprovider has two methods by default, one is to indicate which service is blocked by fusing, and the other is to return the service is unavailable
3. Sometimes because of the network or other reasons, the service may be temporarily unavailable. At this time, we hope to retry the service again. The demo code has configured two retries
4. The default routing rule of the gateway: spring cloud zuul has helped us make the default configuration. By default, Zuul will proxy all microservices registered to Eureka Server, and Zuul's routing rules are as follows: http://Zuul_ HOST:Zuul_ The serviceId / * * of port / microservice on Eureka will be forwarded to the microservice corresponding to serviceId.
5. This demonstration includes a zuul gateway and two service providers (corresponding display contents are different and application names are the same)

Demo code

The server is still two, one is 249, the other is 74. Both servers start producer and eureka. zuul is still operating on the first server

Switch code directory [root@localhost ~]# cd /root/spring-cloud-examples/spring-cloud-zuul/spring-cloud-zuul/ //Modify profile [root@localhost spring-cloud-zuul]# vim src/main/resources/application.properties spring.application.name=gateway-service-zuul server.port=8888 eureka.client.service-url.defaultZone=http://192.168.43.249:8000/eureka,http://192.168.43.74:8000/eureka #The routing rules are as follows #zuul.routes.api-a.path=/producer/** #zuul.routes.api-a.serviceId=spring-cloud-producer #Whether to turn on retry function zuul.retryable=true #Number of retries to the current service ribbon.MaxAutoRetries=2 #Number of times to switch the same Server ribbon.MaxAutoRetriesNextServer=0 //start-up [root@localhost spring-cloud-zuul]# mvn spring-boot:run

Effect test

Registry registered services
If any of the two servers log in to port 8000 of the machine, you can see the registered service of the registration center, as shown in the following figure

Token Test (with token and without token)

[root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' hello luojunyong，this is first messge [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' hello luojunyong，this is first messge from producer1 [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' hello luojunyong，this is first messge [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' hello luojunyong，this is first messge from producer1 [root@localhost ~]# [root@localhost ~]# [root@localhost ~]# [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong' token is empty [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong' token is empty

zuul has integrated the functions of ribbon and feign hystrix by default, so it implements load balancing according to the default polling strategy of ribbon

A producer failure (shutting down the producer of node 2)

[root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' The service is unavailable. [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' The service is unavailable. [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' The service is unavailable. //The above indicates that the first visit polled the producer of node 2, but the producer of node 2 failed, so it tried again twice. After waiting for 15 seconds, only the message returned by the producer from node 1 will be sent (eureka server communicates with the registered service for 15s once, the communication with producer 2 failed last time, and it still fails after two attempts. This time, it is found that the communication fails again. The registration center will remove producer 2, and zuul gateway will no longer load the request to producer 2). The result is as follows [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' hello luojunyong，this is first messge from producer1 [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' hello luojunyong，this is first messge from producer1 [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' hello luojunyong，this is first messge from producer1

Both producer s fail
Based on the above operation, stop producer 1, and the access result is as follows

[root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' The service is unavailable. [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' The service is unavailable. [root@localhost ~]# curl 'http://192.168.43.249:8888/spring-cloud-producer/hello?name=luojunyong&token=123' The service is unavailable.

Sleuth components

• Microservice architecture is a distributed architecture, which divides service units according to business. A distributed system often has many service units. Due to the large number of service units and the complexity of business, it is difficult to locate if there are errors and exceptions. It is mainly reflected in that a request may need to call many services, and the complexity of internal service calls determines that the problem is difficult to locate. Therefore, in the microservice architecture, it is necessary to implement distributed link tracking to follow up which services are involved in a request and what is the order of participation, so that the steps of each request can be clearly seen, there is a problem, and it will be located soon.
• In the microservice system, A request from the user first reaches the front-end A (such as the front-end interface), then reaches the middleware B and C (such as load balancing, gateway, etc.) of the system through remote call, and finally reaches the back-end service D and E. the back-end returns the data to the user after A series of business logic calculation. For such A request, after so many services, how to record the data of its request process? This requires service link tracking.
• A distributed service tracking system consists of three parts: data collection, data storage and data display
• The tracking unit of service tracking is a process from the request initiated by the customer to the boundary of the tracked system, until the tracked system returns the response to the customer, which is called a "trace". Several services will be called in each trace. In order to record which services are called and the consumption time of each call, a call record is embedded in each call, which is called a "span". In this way, several ordered spans form a trace. In the process of the system providing services to the outside world, there will be continuous requests and responses, and tracks will also be generated. If these tracks with span are recorded, a service topology of the system can be depicted. With the information of response time in span and whether the request is successful or not, you can find the abnormal service when the problem occurs; according to the historical data, you can also analyze where the performance is poor from the overall level of the system and locate the goal of performance optimization.
• spring cloud sleuth can use zipkin to send information to zipkin, use zipkin's storage to store information, and use zipkin to display data
• Call between spring cloud sleuth microservices to provide link tracking. Sleuth can clearly understand which services a request goes through and how long each service takes to process. So we can easily clarify the call relationship between the microservices. In addition, sleuth can help us
  • Time consumption analysis: isomorphic sleuth can easily understand the time consumption of each sampling request, so as to analyze which service calls are more time-consuming
  • Visual error: for the exception not caught by the program, you can see it on the zipkin service interface
  • Link optimization: for services with frequent calls, some optimization measures can be implemented for these services

zipkin component

• spring cloud sleuth is a package of zipkin, which automatically generates span, trace and other information, intervenes in HTTP request, and sends collection information to zipkin server
• Spring cloud sleuth zipkin is provided by spring cloud to facilitate the integration of zipkin implementation (zipkin client), transfer the collected data to zipkin server for storage and display by zipkinui service
• Each service reports timing data to zipkin. zipkin will generate a dependency graph through zipkinui according to the call relationship, which shows how many tracking requests pass through each service. The system allows developers to easily collect and analyze data through a web front-end, such as the time of each service request, etc., which can easily detect the bottleneck in the system
• zipkin provides pluggable data storage: in memory MySQL Cassandra and Elasticsearch

Service deployment

1. The container docker zipkin project can establish docker image, provide script and docker-compose.yml To start the pre built image. The fastest way to start is to run the latest image directly
   docker run -d -p 9411:9411 openzipkin/zipkin
2. Download the jar. If you have Java 8 or later, the fastest way to start is to use the latest version as a stand-alone executable jar. zipkin uses spring boot to build it
   curl -sSL https://zipkin.io/quickstart.sh | bash -s
   java -jar zipkin.jar
3. Download the source code and run zipkin if you are developing new features. To do this, you need to get the source code for zipkin and build it
   Get source code: git clone https://github.com/openzipkin/zipkin
   Switch Directory: cd zipkin
   Build the server and handle the dependencies:. / mvnw - dskiptests -- also make - pl Zipkin server clean install
   Startup service: Java - jar. / Zipkin server / target / Zipkin server-* exec.jar
4. springboot add dependency boot (this method is used in this operation)

Presentation notes

1. Start two registries, one service provider (java code injected with tracking information), one zuul gateway (java code injected with tracking information) and one zipkin server (listening to 9000 port)
2. Address of ZIPkinServer configured in configuration file of service provider and zuul gateway

It is the same as the previous two servers, one is 192.168.43.249 and the other is 192.168.43.74. The registration center of the two servers is still running. The new zipkinserver producer and zuul are both running on the first server

to configure zipkinserver [root@localhost ~]# cd spring-cloud-examples/spring-cloud-sleuth-zipkin/zipkin-server/ [root@localhost zipkin-server]# vim src/main/resources/application.yml eureka: client: serviceUrl: defaultZone: http://192.168.43.249:8000/eureka,http://192.168.43.74:8000/eureka ා Registration Center server: port: 9000 spring: application: name: zipkin-server //start-up root@localhost zipkin-server]# mvn spring-boot:run //Configure producer [root@localhost spring-cloud-producer]# cd /root/spring-cloud-examples/spring-cloud-sleuth-zipkin/spring-cloud-producer/ [root@localhost spring-cloud-producer]# vim src/main/resources/application.yml server: port: 9001 spring: application: name: producer zipkin: base-url: http://192.168.43.249:9000 ip and port of Zipkin server sleuth: sampler: percentage: 1.0 #Sampling proportion of monitoring data, 1 for 100%, 0.1 for 10% eureka: client: serviceUrl: defaultZone: http://192.168.43.249:8000/eureka/,http://192.168.43.74:8000/eureka //start-up [root@localhost spring-cloud-producer]# mvn spring-boot:run //Configure zuul gateway [root@localhost spring-cloud-zuul]# cd /root/spring-cloud-examples/spring-cloud-sleuth-zipkin/spring-cloud-zuul/ [root@localhost spring-cloud-zuul]# vim src/main/resources/application.yml server: port: 8888 spring: application: name: zuul zipkin: base-url: http://192.168.43.249:9000 sleuth: sampler: percentage: 1.0 eureka: client: serviceUrl: defaultZone: http://192.168.43.249:8000/eureka/,http://192.168.43.74:8000/eureka //start-up [root@localhost spring-cloud-zuul]# mvn spring-boot:run

Demonstration effect

eureka registration service page
firefox 192.168.43.74:9000

Users request producer several times through zuul network management with curl command

[root@localhost ~]# curl '192.168.43.249:8888/producer/hello?name=junyong' hello junyong，this is first messge[root@localhost ~]# curl '192.168.43.249:8888/producer/hello?name=junyong' hello junyong，this is first messge[root@localhost ~]# curl '192.168.43.249:8888/producer/hello?name=junyong' hello junyong，this is first messge[root@localhost ~]# curl '192.168.43.249:8888/producer/hello?name=junyong' hello junyong，this is first messge[root@localhost ~]# curl '192.168.43.249:8888/producer/hello?name=junyong' hello junyong，this is first messge[root@localhost ~]# curl '192.168.43.249:8888/producer/hello?name=junyong' hello junyong，this is first messge[root@localhost ~]#

zipkinUI display
firefox 192.168.43.249:9000

**Request time and order**
The sequence is as shown by the red arrow in the figure. From producer - > zuul, it takes 3.773 seconds to pass through span

Project call dependency

About zipkin storage

• For the convenience of the above process, zipkin server uses to save the received data directly to in memory, but the data needs to be persisted in the production environment. zipkin natively supports mysql Cassandra and elastic search

About performance

• sleuth sampling rate is 0.1 by default, the larger the value is, the more timely the collection is, the greater the impact on Performance
• The zipkin client wants the zipkin server program to send data using http communication, and each time it sends data, it involves the connection and sending process. When zipkin server is shut down or started, it cannot receive data, which will result in data loss in this period of time. Improvement method: add the message middle price between zipkin client and zipkin server, such as MQ or redis, or rabbitmq. After such processing, even if zipkin server is unavailable (closed, network unavailable), the tracking information will not be lost, because the information is saved on rabbitmq, and read from rabbitmq until zipkin server is available

Spring boot Admin

• Spring Boot Admin is an open source software for managing and monitoring Spring Boot applications. Each application is considered as a client. It is displayed in the admin server through HTTP or Eureka registration. The Spring Boot Admin UI uses AngularJs to display the data in the front end.
• Monitor the basic information of spring boot project, detailed Health information, memory information, JVM information, garbage collection information, various configuration information (such as data source, cache list and hit rate), etc., and directly modify the level of logger
• If we use a single spring boot application, we need to configure the address information of AdminServer in each monitored application; if the application is registered in eureka, we don't need to configure each application anymore, and spring boot admin will automatically grab the relevant information from the registry

Presentation notes

1. All applications are registered in eureka, and spring boot admin will automatically grab application information from the registry
2. Use four examples of a server (localhost) to demonstrate
   • Spring boot admin server admin server
   • Spring cloud Eureka registry
   • Spring cloud producer application - Admin Client
   • spring-cloud-producer-2 application II Admin Client
3. Spring boot admin turns on the email alarm. If there is an exception in the service, it will be notified by email
4. First of all, automatic spring cloud Eureka, spring cloud producer, spring cloud producer-2 projects (no need to modify, just start directly)

On the basis of the operation of the above experiment, stop all services, and the operation of the bottom is performed on the first server 192.168.43.249

Demo code

Start directly without modifying the code eureka [root@localhost spring-boot-admin-server]# cd /root/spring-cloud-examples/spring-boot-admin-eureka/spring-cloud-eureka/ [root@localhost spring-cloud-eureka]# mvn spring-boot:run //Run producer directly without modifying the code [root@localhost ~]# cd /root/spring-cloud-examples/spring-boot-admin-eureka/spring-cloud-producer [root@localhost spring-cloud-producer]# mvn spring-boot:run //Run producer-2 directly without modifying the code [root@localhost ~]# cd /root/spring-cloud-examples/spring-boot-admin-eureka/spring-cloud-producer-2/ [root@localhost spring-cloud-producer-2]# mvn spring-boot:run //Modify the code and run spring boot admin [root@localhost ~]# cd /root/spring-cloud-examples/spring-boot-admin-eureka/spring-boot-admin-server/ [root@localhost spring-boot-admin-server]# vim src/main/resources/application.yml server: port: 8000 #admin's listening port spring: application: name: admin-server #App name mail: #Email notification function host: smtp.qq.com username: [email protected] password: xxx properties: mail: smtp: auth: true starttls: enable: true required: true boot: admin: notify: mail: from: [email protected] #Define sender and recipient to: [email protected] # http://codecentric.github.io/spring-boot-admin/1.5.6/#mail-notifications eureka: instance: leaseRenewalIntervalInSeconds: 10 #Renewal time client: registryFetchIntervalSeconds: 5 #Scheduled task time, how many seconds to refresh renewal time serviceUrl: defaultZone: $/eureka/ management.security.enabled: false [root@localhost spring-boot-admin-server]# mvn spring-boot:run

The configuration file of admin server needs to be modified. You need to fill in your own mailbox, authorization code, and sender

Authorization code askxovsposyaeadb
As shown in the figure after configuration

Effect test

View Registration Center
firefox 192.168.43.249:8761

View monitoring application list
firefox 192.168.43.249:8000
You can see four applications, and the status is up

Click Details on the right to view the details, as shown below

Monitoring event and email alarm

Click JOURNAL to view the monitored time, and the alarm email will be automatically sent to the set recipient. The received email is as follows

Monitor application environment variables
Steps and effects are as follows

Thread monitoring of application

Application request tracking details