(1) Relevant blog address:
Learn it SpringCloud (1)-- From single architecture to micro-service architecture, code splitting ( maven Aggregation): https://www.cnblogs.com/l-y-h/p/14105682.html Learn it SpringCloud (2)-- Service Registration Center Eureka,Zookeeper,Consul,Nacos : https://www.cnblogs.com/l-y-h/p/14193443.html Learn it SpringCloud (3)-- Service Calls, Load Balancing Ribbon,OpenFeign : https://www.cnblogs.com/l-y-h/p/14238203.html Learn it SpringCloud (4)-- Service demotion, melting Hystrix,Sentinel : https://www.cnblogs.com/l-y-h/p/14364167.html
(2) Code address:
https://github.com/lyh-man/SpringCloudDemo
1. Introducing the Configuration Center
1. Problem and Solution
[Question:] Basic project creation, service registry, service invocation, load balancing, service downgrade and service meltdown have been completed through the previous blog posts. That is, each module has been able to communicate normally, provide services to the outside world together, and has a certain fault tolerance capability. For a complex distributed system, there may be dozens of modules, each with different configuration information. And that brings a problem -- How do I modify the configuration information? [How to modify configuration information:] Typically, after modifying the configuration information, the service has to be restarted to apply the new configuration. In the development phase, it is normal to frequently modify the configuration information and start the service, but for a running system, every time you modify the configuration information, you have to restart the service, which must cause a great loss. For instance: Suspend maintenance in the game. You're playing a game. Hey, you're notified you need to stop 3 Days of maintenance, it is not very painful, instantly lost interest in playing games. For a complex distributed system, there may be dozens of modules. Modifying and restarting services from one module to another can be a tedious and error-prone task. A software is required to centrally manage configuration information and dynamically modify it. [Solution:] Centrally manage configuration information and dynamically modify configuration information. Note: Centralized management, similar to Eureka The service registry understands that configuration information can be processed somewhere (you can see the configuration information for all microservices). Dynamic modifications, which do not require restarting the microservice, can be applied directly to a running system. Related technology: Config Nacos(Recommended)
Config
1. What is Config?
(1) What is Config?
[Config: ] SpringCloud Config Provides centralized external configuration support for distributed systems. Divided into server-side ( Config Server) And clients ( Config Client). Config Server: The server side, also known as the Distributed Configuration Center, is an independent microservice application. It connects to the configuration server and provides configuration information to clients. Even if used Config Server Configuration information for all environments can be centrally managed, which is used by default Git Implement centralized management. Note: Use Git Manage configuration information for ease of version control (you can use Git Client tools operate). Config Client: The client binds the specified server to obtain configuration information from the configuration center. [Official address:] https://spring.io/projects/spring-cloud-config https://docs.spring.io/spring-cloud-config/docs/current/reference/html/
(2) Config function
[Function:]
Centrally manage profiles.
You can specify an environment to configure. For example: dev,test,prod,release Wait.
Configuration is dynamically modified during runtime (after the configuration center is modified, the microservice gets configuration information from the configuration center, and the microservice does not need to be restarted).
Configuration information Rest The form of the interface is exposed to the outside world.
2. Set up Config Server
(1) Build a Git repository
Config Server uses Git by default for centralized management of configuration information, even if it stores configuration information.
Therefore, a Git repository is needed to store configuration information.
The following:
Enter the code cloud (or Github) and create a Git repository called SpringCloudConfig.
The warehouse address is: https://gitee.com/lyh-man/spring-cloud-config.git
(2) Create a new subproject config_server_9100, as Config Server
Step1:
Modify parent project, current project pom.xml file and introduces related dependencies.
With Eureka as the service registry, dependencies need to be introduced.
[Dependency:]
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
Step2:
Modify the configuration file.
[application.yml] server: port: 9100 spring: application: name: config_server cloud: config: # Gets the branch of the configuration file, defaulting to master label: master server: git: # git repository address uri: https://gitee.com/lyh-man/spring-cloud-config.git # Profile Search Path search-paths: - SpringCloudConfig eureka: instance: appname: config_server # Priority ratio spring.application.name High instance-id: ${eureka.instance.appname} # Set current instance ID client: register-with-eureka: true # Default to true，Register with the Registry fetch-registry: true # Default to true，Get registration information from the registry service-url: # Point to the registry address, eureka_ Server_ Address of 7000. defaultZone: http://localhost:7000/eureka
Step3:
In config_ Server_ Add the @EnableConfigServer annotation on the 9100 startup class.
Step4:
- Start eureka_server_7000 and config_server_9100.
A new file, config-dev.yml, is added and submitted to the master branch as follows:
[config-dev.yml: ] server: port: 9100 spring: application: name: config_server cloud: config: # Gets the branch of the configuration file, defaulting to master label: master server: git: # git repository address uri: https://gitee.com/lyh-man/spring-cloud-config.git # Profile Search Path search-paths: - SpringCloudConfig eureka: instance: appname: config_server # Priority ratio spring.application.name High instance-id: ${eureka.instance.appname} # Set current instance ID client: register-with-eureka: true # Default to true，Register with the Registry fetch-registry: true # Default to true，Get registration information from the registry service-url: # Point to the registry address, eureka_ Server_ Address of 7000. defaultZone: http://localhost:7000/eureka
Access at this time: http://localhost:9100/master/config-dev.yml, you can get the contents of the config-dev.yml file under the master branch.
3. Get common HTTP formats for profiles in Git
(1) Format description
[Three parameters: label: Branch name application: Application name (service name) profile: Environmental Science Note: Submit to Git Configuration file names are typically created by application and profile Form. Its naming style is generally: application-profile.yml perhaps application-profile.properties. For example: config-dev.yml ,config-prod.yml Wait. [HTTP Format:] /{label}/{application}-{profile}.yml perhaps /{label}/{application}-{profile}.properties /{application}/{profile}/{label} For example: /master/config-dev.yml Equivalent to /config/dev/master Note: master Omit, default is master，That is, equivalent to /config-dev.yml
4. Set up client (Config Client)
(1) Create a new subproject config_client_9200, as Config Client
Step1:
Modify parent project, current project pom.xml file and introduces related dependencies.
With Eureka as the service registry, dependencies need to be introduced.
[Dependency:]
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
Step2:
Modify the configuration file (bootstrap.yml).
[Note: Config Client The configuration file is bootstrap.yml，Not application.yml. Note: bootstrap.yml Priority Ratio application.yml High (i.e. bootstrap.yml Load first). Config Client After startup, the bootstrap.yml Configured Config Server Information and Config Server Make a binding, So you get Config Server Stored in Git Configuration information. [bootstrap.yml] server: port: 9200 spring: application: name: config_client cloud: # Binding Configuration Center, http://localhost:9100/master/config-dev.yml config: # Branch name label: master # Name of profile name: config # Suffix Name profile: dev # config server configuration center address uri: http://localhost:9100 eureka: instance: appname: config_client # Priority ratio spring.application.name High instance-id: ${eureka.instance.appname} # Set current instance ID client: register-with-eureka: true # Default to true，Register with the Registry fetch-registry: true # Default to true，Get registration information from the registry service-url: # Point to the registry address, eureka_ Server_ Address of 7000. defaultZone: http://localhost:7000/eureka
Step3:
Write TestController for testing,
The @Value annotation is used to introduce the contents of the configuration file stored in Git.
Note:
When the service is initially started, @Value will cause the service to fail to start if the config client fails to bind to the config server, that is, it cannot get the configuration information in Git.
[TestController] package com.lyh.springcloud.config_client_9200.controller; import org.springframework.beans.factory.annotation.Value; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/config") public class TestController { @Value("${config.info}") private String info; @GetMapping("/getInfo") public String getInfoAndMessage() { String result = ""; if (info != null) { return "success " + info + "\n"; } return "error"; } }
Step4:
Modify the config-dev.yml file in the Git repository as follows:
[config-dev.yml: ]
config:
info: helloworld!!!
Step5:
Testing. Start eureka_server_7000, config_server_9100, config_client_9200.
Front bootstrap.yml is configured to get http://localhost:9100/master/config Content in -dev.yml.
After the config client starts successfully, you can get the config-dev.yml content, and @Value is injected successfully and returned successfully.
Note:
When config client starts, the service may fail to start due to @Value injection failure.
Possible reasons:
The config server is not configured correctly. The config client cannot bind the config server properly.
The config server is normal, but the config-dev.yml file does not exist.
The config-dev.yml file exists, but there is no config in it. Info.
5. Problems (Refresh Problems)
(1) Questions
[Question:] Pass above config server as well as config client Build, config client Successfully passed config server Get Git Stored configuration information. But there is one problem: stay config client as well as config server Modify the service after it's all started Git Configuration files in the You will find that config server It's okay to get the latest configuration information, but config client Get is still the original value. Only restart config client The latest configuration information is not available until the service is available. Restarting is definitely not an option, so what can I do about it? [Solution 1: Introduce actuator，Refresh and reload with it. Disadvantages: Need to trigger manually POST Request, access refresh Port ( http://localhost:9200/actuator/refresh). Of course, you can write a script, send requests regularly, and refresh. [Solution 2: Schema pair may need to be executed once or more for each microservice POST Request to refresh configuration information. It's still a bit cumbersome to implement. So is there a mechanism for one notification to take effect everywhere? You need to use a message bus here SpringCloud Bus(Follow-up, skipped here for now).
(2) Solution 1 (using actuator):
Step1:
Introduce an actuator dependency.
[Dependency:]
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Step2:
Configure the exposed ports, mainly refresh, while the rest are arbitrary (you can use * directly for all).
# Exposure Monitoring Endpoint management: endpoints: web: exposure: # include: "refresh" include: "*"
Step3:
Add the @RefreshScope comment to the TestController.
@RestController @RequestMapping("/config") @RefreshScope public class TestController { @Value("${config.info}") private String info; @GetMapping("/getInfo") public String getInfoAndMessage() { String result = ""; if (info != null) { return "success " + info + "\n"; } return "error"; } }
Step4:
Restart the config client and get the latest configuration information.
Modify config-dev.yml again as follows:
config:
info: refresh
At this point config server is accessing the latest configuration information
But config client still gets the last configuration information
Send POST requests using Postman http://localhost:9200/actuator/refresh After that,
The config client gets the latest configuration information again.
3. Introducing Message Bus
1. Problem and Solution
[Question:]
Previous Use Spring Cloud Config As a configuration center, there was a pit left:
To update Git After the stored configuration file, Config Client It is not possible to get the latest configuration in real time.
Config Client Need to restart the service or use actuator Refresh the configuration to get the latest profile information.
In microservices, Config Client The number will increase if each Config Client Need to restart or send refresh There are still some accompanying effects of requests.
Can auto refresh be achieved? That's it Git After the configuration file, Config Client Auto refresh to get the latest configuration.
[Solution:]
Use Spring Cloud Bus Coordination Spring Cloud Config Configured automatic refresh functions can be implemented.
4. Message Bus
1. What is Bus?
(1) What is Bus?
[Spring Cloud Bus What is:] Spring Cloud Bus It is a framework that links lightweight messaging systems to distributed system nodes and integrates the functions of event handling mechanisms and message middleware. It can manage and propagate messages that need to be delivered in a distributed system. It can be used for broadcasting state changes (e.g., configuration modifications), event pushing, etc., or as a communication channel between micro-service applications. [Bus Supported messaging systems: Spring Cloud Bus Two messaging systems are currently supported: RabbitMQ and Kafka. Corresponding dependencies need to be introduced when using: spring-cloud-starter-bus-amqp or spring-cloud-starter-bus-kafka. [Understand the message bus: Message bus can be understood as a message center. RabbitMQ,Kafka)，All micro service instances in the system are connected to the bus. An instance of a microservice can send or receive messages to a messaging center (listening for messages from a messaging center). Messages from message centers are monitored and consumed by all instances of microservices. For example: Microservice Instances A Send a message to the bus and the rest of the micro service instances can listen for it and process it accordingly. [Official address:] https://spring.io/projects/spring-cloud-bus https://docs.spring.io/spring-cloud-bus/docs/current/reference/html/
(2) How to achieve it?
Mode 1:
Client Config Client refresh.
[Basic process:] Step1: To update Git Repository Configuration file in. Step2: To Client Config Client C Send out POST Request: /actuator/busrefresh， here Config Client C according to Config Server Get the latest configuration file. also Config Client C To message bus Bus Send a message (that is, you need to refresh). Step3: Bus After receiving the message, notify the other client instances of the message ( Config Client A,Config Client B). Step4: When other client instances receive information, it is equivalent to refreshing, according to Config Server Get the latest configuration file. At this point, all client instances have the latest configuration information available. [Question:] Client refresh is not generally used because the client itself belongs to a business module, and the refresh function is not part of its business function, which would destroy its single responsibility.
Mode 2:
Server Config Server refresh.
[Basic process:] Step1: To update Git Repository Configuration file in. Step2: To server Config Server Send out POST Request: /actuator/busrefresh， also Config Server To message bus Bus Send a message (that is, you need to refresh). Step3: Bus After receiving the message, notify all client instances of the message ( Config Client A,Config Client B,Config Client C). Step4: When the client instance receives the information, it is equivalent to a refresh, based on Config Server Get the latest configuration file. At this point, all client instances have the latest configuration information available.
2. Use RabbitMQ as message middleware
(1) Build a basic environment on CentOS7 using docker-compose
The basic use of docker-compose can be referred to as: https://www.cnblogs.com/l-y-h/p/12622730.html#_label8_2
[structure docker-compose.yml The following are: # Specify the compose file version, compatible with docker, higher versions of docker are generally used 3.x. version: '3.7' # Define all service information that needs to be managed services: # This refers to the name of the service rabbitmq: # Specify the mirror path (which can be a remote warehouse image or a local image) image: rabbitmq:3.8.3-management # Specify the name of the container (equivalent to docker run) --name) container_name: rabbitmq # Define a container restart policy, no means no restart under any circumstances (default), and always means always restart. restart: always hostname: myRabbitmq # Define port mapping between host and container ports: - 15672:15672 - 5672:5672 # Define host-container data volume mapping volumes: - /usr/mydata/rabbitmq/data:/var/lib/rabbitmq # Setting environment variables environment: # Set RabbitMQ login user to root and login password to root (default guest if not configured) - RABBITMQ_DEFAULT_USER=root - RABBITMQ_DEFAULT_PASS=root
(2) Start RabbitMQ
After RabbitMQ is started via docker-compose up-d, its Web page can be accessed via port number 15672.
Note:
For cloud servers, you need to configure security group rules to open ports 15672 and 5672.
15672 is RabbitMQ Visual web Interface Access Port.
5672 is the RabbitMQ access port.
3. Config Integration Bus
(1) Config Server Integrated Bus (RabbitMQ)
Scenario 2 is used here to refresh on the server side, so Config Server needs to introduce an actuator dependency.
Step1:
In config_ Server_ RabbitMQ and actuator dependencies were introduced in 9100.
[Dependency:]
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Step2:
In the configuration file, add the RabbitMQ configuration and expose the Bus refresh port.
Access bus refresh through/actuator/bus-refresh.
[application.yml: ] spring: # rabbitmq configuration rabbitmq: username: root password: root host: 120.26.184.41 port: 5672 # Expose monitoring endpoints (busrefresh, or write directly) *) management: endpoints: web: exposure: # include: "*" include: "busrefresh"
(2) Config Client Integration Bus (RabbitMQ)
Step1:
config_client_9200 also needs to introduce RabbitMQ dependency.
[Dependency:]
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
Step2:
In the configuration file, add the RabbitMQ configuration.
[bootstrap.yml: ] spring: # RabbitMQ related configuration rabbitmq: username: root password: root host: 120.26.184.41 port: 5672
(3) Add a new Config Client
Add a new one with config_client_9200 Similar config_client_9201, simulate multi-instance refresh.
Build steps and config_client_9200 is the same, just modify the port number.
For the sake of config_client_9200 Difference, config_ Client_ Actor dependencies are not introduced in 9201.
(4) Testing.
Start separately: eureka_server_7000, config_server_9100, config_client_9200, config_client_9201.
Step1:
The initial access profile is as follows:
http://localhost:9100/master/config-dev.yml http://localhost:9200/config/getInfo http://localhost:9201/config/getInfo
Step2:
After modifying the configuration file, get the configuration file again as follows:
http://localhost:9100/master/config-dev.yml http://localhost:9200/config/getInfo http://localhost:9201/config/getInfo
Step3:
Send a POST request/actuator/bus-refresh to Config Server to get the configuration file again:
POST Request: http://localhost:9100/actuator/bus-refresh http://localhost:9100/master/config-dev.yml http://localhost:9200/config/getInfo http://localhost:9201/config/getInfo
Step4 (Scenario 1: Client refresh, for reference only):
Modify the configuration file again and send a POST request to 9200 this time.
Because 9200 is configured with an actuator and the exposed endpoint is *, refresh, bus-refresh can be executed.
When the POST request sent is refersh, only your own profile will be updated at this time, and 9201 will not be changed.
POST Request: http://localhost:9200/actuator/refresh http://localhost:9100/master/config-dev.yml http://localhost:9200/config/getInfo http://localhost:9201/config/getInfo
The 9201 configuration file is also modified when the POST request sent is bus-refresh.
POST Request: http://localhost:9200/actuator/bus-refresh http://localhost:9100/master/config-dev.yml http://localhost:9200/config/getInfo http://localhost:9201/config/getInfo
Step5:
Specify the endpoint to update, add information about the microservice instance after the POST request,
Generally: spring.application.name:server.port
For example:
config_client:9201 means only config_is specified Cliet_ 9201 This microservice is updated.
config_client:** denotes config_client updates all microservices associated with it.
POST Request: http://localhost:9100/actuator/bus-refresh/config_client:9201 http://localhost:9100/master/config-dev.yml http://localhost:9200/config/getInfo http://localhost:9201/config/getInfo
5. Distributed Link Tracking
1. Problem and Solution
[Question:]
In a complex micro-service system, requests sent by a client may go through multiple service nodes that work together to produce the final request result.
The microservice through which the request passes can be viewed as a service call link (distributed service call link).
High latency or errors from any of the services in the link will cause the entire request to fail.
When a request fails, how do I determine which service is having problems?
Looking at the log line by line is definitely not a good way to do this. Are there simple tools to help us quickly locate error services?
[Solution:]
Use SpringCloud Sleuth，Track and display service call links.
2. Distributed Link Tracking--Sleuth
(1) What is Sleuth?
[What is? Sleuth: ] Spring Cloud Sleuth Provides a complete set of distributed service tracking solutions that are compatible Zipkin. In a complex micro-service system, if more than one request is processed at a time, it is difficult to determine which micro-services a request needs to be associated with from the log alone. The general solution is to pass a unique request for each request ID，And according to ID Find its log. and Sleuth Can work with the log framework ( Logback,SLF4J) Easy to integrate and use log tracking with unique identifiers to facilitate analysis of service call links. Sleuth Tracking the processing of a request in a distributed system (data collection, data transmission, data storage, data analysis, data visualization) allows you to easily monitor the microservice call link through a visual interface. [Official address:] https://spring.io/projects/spring-cloud-sleuth https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/getting-started.html
(2) Download and start Zipkin Server
Zipkin is used to visualize the interface. Download the jar package and start it directly.
[Download Address:] http://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/ For example: http://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/2.12.9/zipkin-server-2.12.9-exec.jar
Via java-jar zipkin-server-2.12.9-exec. Jar can be started directly.
Visual Web interfaces are accessible through port 9411.
For example: http://120.26.184.41:9411/
3. Simple integration of Sleuth
(1) Description
[Description:]
Use here eureka_server_7000,config_server_9100,config_client_9200,config_client_9201 Demonstrate.
Where:
To demonstrate a link call, the request passes through config_client_9201，call config_client_9200，Recall config_server_9100.
Use openfeign Make service remote calls.
(2) Modify config_server_9100
Step1:
Introduce sleuth dependencies and modify configuration files.
[Dependency:] <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> [bootstrap.yml: ] spring: zipkin: base-url: http://120.26.184.41:9411 sleuth: # Sampling rate range 0 ~ 1，1 Represents all collections sampler: probability: 1
Step2:
Write business code.
[SleuthController] package com.lyh.springcloud.config_server_9100.controller; import org.springframework.beans.factory.annotation.Value; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RequestMapping("/sleuth") @RestController public class SleuthController { @Value("${server.port}") private String port; @GetMapping("/getInfo") public String getInfo() { return port; } }
(3) Renovation of config_client_9200
Step1:
Introduce openfeign, sleuth dependencies, and modify configuration files.
[Dependency:] <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> [bootstrap.yml] spring: zipkin: base-url: http://120.26.184.41:9411 sleuth: # Sampling rate range 0 ~ 1，1 Represents all collections sampler: probability: 1
Step2:
- Write business code,
config_client_9200 remote call config_server service.
Add the @EnableFeignClients annotation to the startup class.
[SleuthService: ] package com.lyh.springcloud.config_client_9200.service; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.stereotype.Component; import org.springframework.web.bind.annotation.GetMapping; @FeignClient(value = "CONFIG-SERVER") @Component public interface SleuthService { @GetMapping("/sleuth/getInfo") String getInfo(); } [SleuthController] package com.lyh.springcloud.config_client_9200.controller; import com.lyh.springcloud.config_client_9200.service.SleuthService; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/sleuth") public class SleuthController { @Autowired private SleuthService sleuthService; @Value("${server.port}") private String port; @GetMapping("/getInfo") public String getInfo() { return sleuthService.getInfo() + "current port : " + port; } }
(4) Modify config_client_9201
config_client_9201 and config_client_9200 Modify code similar, just config_client_9201 is calling config_remotely Client_ 9200 services.
(5) Testing
Start eureka_in turn Server_ 7000, config_server_9100, config_client_9200, config_client_9201 service and call its methods.
(6) Error in demo service invocation
Following figure, in config_ Client_ Simulate an error call in 9200 and send the request again to config_client_9201.
4. Link identification, log integration
(1) Link identification
From the screenshot above, each link point has three IDs after it is opened: traceID, spanID, parentID.
[ID: ]
traceID Represents a unique identification of a request link in which each service node contains the same traceID，Indicates that it belongs to the current link.
spanID Represents the ID，Used to distinguish each request in a link.
parentID Represents the parent service of the current request ID，This is used for requests in the associated link.
(2) Log Integration
Following figure, in config_ Client_ Print the log in 9200 and send the request again to config_client_9201.
The log output format is: [application name, traceId, spanId, export].
Note:
The application name represents the application name.
export Boolean type indicating whether information is exported to zipkin for collection and presentation.
[SleuthController: ] package com.lyh.springcloud.config_client_9200.controller; import com.lyh.springcloud.config_client_9200.service.SleuthService; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/sleuth") public class SleuthController { @Autowired private SleuthService sleuthService; private final Logger logger = LoggerFactory.getLogger(SleuthController.class); @Value("${server.port}") private String port; @GetMapping("/getInfo") public String getInfo() { logger.info("test"); return sleuthService.getInfo() + "current port : " + port; } }
6. Configuration Center Nacos
Not finished yet.