[Turn]springcloud (ix): Configuration Center and message bus (configuration center finalization)

Springcloud (ix): Configuration Center and message bus (configuration center finalization)

In Springcloud (vii): Configuration Center svn example and refresh, refresh we can use the mechanism of Webhook to flush the client each time the client gets the latest configuration information if it needs to be executed, and when clients are getting more and more , which requires each client to be executed again, this scenario is less appropriate. Using spring Cloud Bus can solve this problem perfectly.

Spring Cloud Bus

Spring Cloud Bus connects the nodes of each distribution through a lightweight message broker. This will be used for changes in broadcast status (such as configuration changes) or other message instructions. One of the core ideas of spring bus is to extend the spring boot application through a distributed launcher, or to establish a communication channel between multiple applications. The only way to do this is to use the AMQP message agent as a channel, with the same set of attributes (some depending on the settings of the channel) in the document for more channels.

Spring Cloud Bus has been translated into the message bus in many countries, also quite image. It can be understood as the management and dissemination of all distributed projects in the message can be, in fact, the essence is the use of MQ broadcasting mechanism in distributed systems to disseminate messages, the current commonly used are Kafka and RABBITMQ. Using the bus mechanism can do a lot of things, in which the Configuration Center client Refresh is one of the typical application scenarios, we use a graph to describe the mechanism used by bus in the configuration center.

From this diagram we can see the steps to make a configuration update with spring Cloud bus:

• 1. Commit code to trigger post to client a send Bus/refresh
• 2. Client a receives a request to update the configuration from server side and sends it to spring Cloud Bus
• 3. Spring Cloud Bus receives a message and notifies other clients
• 4, other clients receive the notification, request the server side to obtain the latest configuration
• 5. All clients get the latest configuration

Project examples

We chose the previous article Springcloud (eight): Configure the Hub service and the highly available version of the sample code to retrofit, MQ we use RABBITMQ to do the example.

Client Spring-cloud-config-client Retrofit

1. Add dependencies

<dependency>    <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId></dependency>

Need to introduce more spring-cloud-starter-bus-amqp packages and increase support for message bus

2. Configuration files

## 刷新时，关闭安全验证management.security.enabled=false## 开启消息跟踪spring.cloud.bus.trace.enabled=truespring.rabbitmq.host=192.168.9.89spring.rabbitmq.port=5672spring.rabbitmq.username=adminspring.rabbitmq.password=123456

The configuration file needs to increase the configuration of the REBBITMQ so that the client code is completed.

3. Testing

Start the Spring-cloud-eureka, Spring-cloud-config-server, spring-cloud-config-client projects in turn, When starting the Spring-cloud-config-client project we will find that the boot log will output such a record.

2017-05-26 17:05:38.568 INFO 21924 --- [ main] o.s.b.a.e.mvc.EndpointHandlerMapping : Mapped "{[/bus/refresh],methods=[POST]}" onto public void org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh(java.lang.String)

Indicates that the client has the ability to notify the message bus, in order to better simulate the effect of the message bus, we change the client Spring-cloud-config-client project port to 8003, 8004 start, so the test environment is ready. After starting the Eureka background as follows:

Let's test separately if the server and client are running correctly, Access: http://localhost:8001/neo-config/dev , return information:

{    "name": "neo-config",     "profiles": [        "dev"    ],     "label": null, "version": null, "state": null, "propertySources": [ { "name": "https://github.com/ityouknow/spring-cloud-starter/config-repo/neo-config-dev.properties", "source": { "neo.hello": "hello im dev" } } ]}

Indicates that the server side has read the configuration information normally.

Access: http://localhost:8002/hello ,, http://localhost:8003/hello http://localhost:8004/hello , return: hello im dev . Indicates that the client has read the contents of the server side.

Now we update neo-config-dev.properties neo.hello the value in hello im dev update and commit to the code base, access: http://localhost:8002/hello still returns hello im dev . We send a POST request to a client with Port 8002 /bus/refresh . Under Win, use the following command to simulate the Webhook.

http://localhost:8002/bus/refresh

When execution is complete, go to: http://localhost:8002/hello ,, http://localhost:8003/hello http://localhost:8004/hello , return: hello im dev update . Indicates that three clients have already received the information of the most recent configuration file, so that we have implemented the example in figure one.

Improved version

In the process above, we have reached the goal of triggering a client with the message bus bus/refresh and refreshing the configuration of all clients. But this approach is not elegant. The reasons are as follows:

• Break the role of microservices in singleness. The microservices themselves are business modules, which should not assume responsibility for configuration refreshes.
• The reciprocity of each node of the microservices is compromised.
• have certain limitations. For example, when a microservices is migrated, its network address is often changed, and if you want to refresh automatically, you have to modify the Webhook configuration.

So let's change the schema pattern above a little bit.

Then Spring Cloud Bus does the following configuration update steps:

• 1. Commit code to trigger POST request to Bus/refresh
• 2. Server side received the request and sent to spring Cloud Bus
• 3. Spring Cloud Bus receives a message and notifies other clients
• 4, other clients receive the notification, request the server side to obtain the latest configuration
• 5. All clients get the latest configuration

In this case, we have some changes in the server-side code to supportbus/refresh

1. Add dependencies

<Dependencies><Dependency><Groupid>org.springframework.cloud</Groupid><Artifactid>spring-cloud-config-server</Artifactid></Dependency><Dependency><Groupid>org.springframework.cloud</Groupid><Artifactid>spring-cloud-starter-bus-amqp</artifactid> </dependency> <dependency> <groupId> Org.springframework.cloud</groupId> <artifactid>spring-cloud-starter-eureka </artifactid> </dependency></DEPENDENCIES>            

Need to introduce more spring-cloud-starter-bus-amqp packages and increase support for message bus

2. Configuration files

ServerPort8001SpringApplication:Name:spring-cloud-config-serverCloudConfigServerGit:uri:https://github.com/ityouknow/spring-cloud-starter/# Configure the address of the GIT repositorySearch-paths:config-repo# The relative address of the GIT repository address, can be configured multiple, with, split.Username:username# git repository account  Password:password # Git repository password  Rabbitmq: host: 192.168.0.6 port: 5672< Span class= "hljs-attr" > Username:admin password: 123456eureka: Client: serviceurl:  Defaultzone:http://localhost:8000/eureka/ ## Registry Eurka address management: security:< Span class= "Hljs-attr" > enabled: false        

The configuration file increases the REBBITMQ configuration and turns off security validation. This allows the server-side code to be transformed.

3. Testing

Start the Spring-cloud-eureka, Spring-cloud-config-server, spring-cloud-config-client projects in turn, Change the Spring-cloud-config-client project port to 8003, 8004 to start in turn. The test environment is ready to complete.

The access server side and three client tests can return information correctly, as described above. neo-config-dev.propertiesthe values in the same modification are neo.hello and are hello im dev update submitted to the code base. Under Win, use the following command to simulate the Webhook trigger server side bus/refresh .

http://localhost:8001/bus/refresh

When execution is complete, go to: http://localhost:8002/hello ,, http://localhost:8003/hello http://localhost:8004/hello , return: hello im dev update . Indicates that three clients have already received the information for the most recent configuration file, so we have implemented the example in.

Other local refreshes

In some scenarios, such as grayscale publishing, we may only want to refresh the configuration of a subset of the microservices, at which point /bus/refresh the destination parameter of the endpoint is used to locate the application to be refreshed.

For example /bus/refresh?destination=customers:8000 , a microservices instance on a message bus will determine if it needs to be refreshed based on the value of the destination parameter. customers:8000this refers to the ApplicationContext ID of each micro-service.

The destination parameter can also be used to locate a specific micro-service. For example /bus/refresh?destination=customers:** , this can trigger a configuration refresh for all instances of the customers microservices.

Track Bus Events

In some scenarios, we may want to know the details of the spring Cloud bus event propagation. At this point, we can track the bus events (the Remoteapplicationevent subclasses are bus events).

Tracking bus events is very simple, just set up so that when the spring.cloud.bus.trace.enabled=true /bus/refresh endpoint is requested, access /trace to the endpoint can result in something similar to the following:

{"Timestamp":1495851419032,"Info": {"Signal":"Spring.cloud.bus.ack","Type":"Refreshremoteapplicationevent","id":"C4d374b7-58ea-4928-a312-31984def293b","Origin":"Stores:8002","Destination":"*:**" } }, {"Timestamp":1495851419033,"Info": {"Signal":"Spring.cloud.bus.sent","Type":"Refreshremoteapplicationevent", "id":  "c4d374b7-58ea-4928-a312-31984def293b", " spring-cloud-config-client:8001 ", " *:* * "}}, {" timestamp ": 1495851422175,  "info": { "signal": Span class= "hljs-string" > "Spring.cloud.bus.ack",  "type":  " Refreshremoteapplicationevent ", " id ": " c4d374b7-58ea-4928-a312-31984def293b ", " origin ": " Customers : 8001 ", " destination ": " *:* * "}}     

This log shows the customers:8001 issue of Refreshremoteapplicationevent events, broadcast to all services, customers:9000 and received by stores:8081 . To customize the way you handle the messages you receive, you can add @EventListener the ackremoteapplicationevent and sentapplicationevent types of annotations to your own apps. Or to the Tracerepository class, process the data directly.

In this way, we will be able to clearly know the details of the event's dissemination.

/bus/refreshBUG

/bus/refreshThere is a serious bug that has not been resolved: After execution of the client /bus/refresh , the client that hangs on the bus will be revoked from the Eureka Registry, and if executed on the server side /bus/refresh , the server side will also unregister from the Eureka Registration Center. Again in the vernacular to explain, is originally someone else in the Eureka Registration Center registered good, as long as you execute it once /bus/refresh , will immediately from the Euraka hanging off.

In fact, this problem is very serious, originally you use /bus/refresh to all the nodes to update the configuration information, the result of the service from the Euraka to get rid of, then if others need to call the client's service when the direct break dishes. Do not know the domestic children's shoes company in the production of this function is not used, it is very tragic. Search on the Internet, domestic netizens and foreign netizens have met many times, but has not been resolved, very fortunate that I wrote this article a few days ago , Netflix fixed this problem, using the latest version of Spring Cloud package can solve this problem. It can also be found that spring cloud is still in rapid development, the latest version may also have some instability, visible road long and repair far.

Use the spring cloud version in the pom to fix this bug.

<Properties><Project.build.sourceencoding>utf-8</project.build.sourceencoding> <project.reporting.outputencoding>utf-8< span class= "kw" ></project.reporting.outputencoding> <java.version>1.8</java.version>  <spring-cloud.version>dalston.sr1</< Span class= "Hljs-name" >spring-cloud.version></ PROPERTIES>            

The main thing is this: <spring-cloud.version>Dalston.SR1</spring-cloud.version> , please refer to the code in this example

The bug discussion and resolution process can be seen on GitHub above these two issue:

• /bus/refresh causes instances registered in Eureka Server disappeared #692
  
• Making POST on ' refresh ' permamently deregisters the service from Eureka #1857

Reference:

Config server--automatically refreshes the configuration using Spring Cloud bus

Spring Cloud Building MicroServices Architecture (VII) message bus

Sample code

A pure Smile
Source: http://www.ityouknow.com/
Copyright belongs to the author, please specify the source of the reprint

[Turn]springcloud (ix): Configuration Center and message bus (configuration center finalization)