This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

preface

  • In the SpringCloud Config section, we completed the setup of the seed center and the extraction of the configuration through the configuration center. Through the SpringCloud Config module, we removed the configuration to the Git repository. We didn’t have to send out a package every time we changed the configuration. But SpringCloud Config does not completely solve the problem of automatic configuration updates. The last thing we left in config is that every time git repository is modified, the interface of the actuator/refresh needs to be manually invoked to update the configuration. It was also pointed out that in the case of numerous distributed micro-services, manual invocation of the interface is time-consuming and not guaranteed!! Of course, you can also write a script to batch call. But the SpringCloud Bus we’re going to look at today can help us avoid these problems
  • There was a point in springCloud Config that I added here. How to invoke the Refresh interface when the Git repository changes. This is done primarily through WebHooks in the Git repository.

Integrated springcloud bus

  • In the config section, we use the order module in the Framework -root project. This time, we choose the Payment module as the Config client for demonstration.
  • First, we need to add config as client in poM. Different from last time, we need to introduce bus module this time. The actuator is essential because it uses endpoint refresh

pom

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Copy the code

The configuration file

  • Here we need to review the previous chapter. You first need to specify the config-server address in the bootstrap.yml file
spring:
  cloud:
    config:
      label: master
      name: config-server
      profile: dev
      uri: http://localhost:8070
Copy the code
  • Because bus uses message queues we will demonstrate this using RabbitMQ. So we also need to configure the Rabbit information in application.yml
Rabbitmq: host: 39.102.60.114 Port: 5672 username: 'zxhtom' password: '025025'Copy the code
  • In order to better understand the endpoints involved in each module function, we have not released all endpoints here, so we need to configure our own endpoints
management:
  endpoints:
    web:
      exposure:
        include: hystrix.stream,info,bus-refresh
Copy the code
  • Note that because of the Springboot update, the monitoring in the actuator changes. The endpoint interface involved in bus in earlier versions is /bus/refresh. However, the actuator in my edition is 2.2.2.RELEASE. The refresh interface is /actuator/bus-refresh.

controller

  • Of course, for the sake of testing, it is straightforward to see the configuration change. We write an interface to read the configuration. The only difference from a normal interface is that there is an extra one on the Controller class@RefreshScope
@RestController @RefreshScope @RequestMapping(value = "/payment/config") public class ConfigController { @Value("${zxhtom}") String value; @RequestMapping(value = "/getConfig" , method = RequestMethod.GET) public String getConfig() { return value; }}Copy the code

Multi-instance deployment

  • Above, we simply reformed payment to complete the upgrade of config-client. However, multiple config-clients are required in the bus automatic refresh of the config-client. Here’s a tip -idea a code multi-instance deployment
  • This feature is also mentioned in the Eureka chapter. But the author here or why you sort out do not need you to turn over. After all, high productivity is hard to find recently!!

  • We Edit Configurations in the idea. Then add a SpringBoot boot class configuration.

  • We specify other ports directly in VM Options. This completes multi-instance deployment. But there are cases where we don’t just need ports to be different. Then we can specify external configuration files through the Enviroment Varables configuration. Here we just set the ports to be different.

test

  • After the above multi-instance deployment we can start two Payment services in IDEA.

  • Here we just enable config-server + Euraka + 2* Payment. We’re not actually using Eureka at this point. But because the project used Eureka before.
  • After the successful startup, we first access the configuration interfaces in the two Payment services to check the configuration information.

  • Git repository config-server-dev.properties = config-server-dev.properties The reason for this file is not analyzed in detail in the config section.
  • After modifying the warehouse configuration file, we come to the main dish of our bus, where we have two instances of Payment. The reason WHY I have multiple instances is so that I can demonstrate the effect of sprawl here. We can refresh the data of both instances by refreshing the data of one instance. butactuator/refreshThis interface is not satisfied with what we need to useactuator/bus-refreshTo implement.

  • When we access both payment data after refreshing, we see changes. Here the reader’s own operation can see the effect.

Every man unto his place

  • I don’t know if you’ve noticed, but we’ve implemented the refresh interface through bus so that you only need to perform one refresh interface to complete the configuration refresh. However, there are some disadvantages. The SpringCloud Bus module is positioned as a “message bus” in SpringCloud. The meaning of bus should be the meaning of faucet. But the above implementation seems to be just a passing effect. It’s like the boss of an organization has to take orders from one of his men
  • Most project architectures do not implement the dynamic refresh of config in this way. Instead, the config-server is reformed and upgraded. Let config-server have bus refresh capability. In git repository, the hook is configured as the refresh interface corresponding to config-server. In this way, the functional analysis will become clear; The bus does the data callback and refreshes the configuration of each micro-service subscription message.
  • Some people said that in order to make the responsibilities more clear, we can create a new module called bus. Let it act as the hook back function. In this way, config-server serves as the configuration data source, config-client reads the configuration, and BUS serves as the configuration refresh notification function. So the three complement each other.
  • In short, how to divide is something that needs to be considered in each architecture. We’re not going to do that here.

Local refresh

  • By introducing third party modules above we have made module functions and responsibilities very clear. In addition, the configuration can also be dynamically refreshed, but sometimes the consumption of service refreshing configuration is huge, so we need to refresh precisely. In other words, refuse to refresh unless necessary. Sometimes the git repository does not affect the refresh of all modules, so we need to brush only part of the service.
  • The above two Payment ports are 8001/8003 respectively. At this point we want to refresh only port 8003 service with git updates. We can call the refresh interface to specify the service name
  • localhost:8092/actuator/bus-refresh/cloud-payment-service:8003. This will change the configuration of 8003’s payment. The configuration of 8001 is still the old data
  • The point is to refresh the interface.actuator/bus-refresh/{destination}. The destination value is a description of the service delivered to us. His format is mainly as follows
  • ${spring.cloud.client.hostname}:${spring.application.name}:${spring.application.instance_id}:${server.port}. Normally we pass${spring.application.name}:${server.port}Identify.

The source code

Click me to download it