多项目如何高效协同合作 | springcloud系列之bus消息总线

Posted 2022-02-03 烟花散尽13141

前言

• 在springcloud config章节中我们完成了配种中心的搭建，以及通过配置中心完成配置的抽离通过springcloud config模块我们将配置抽离到git仓库中我们不必要每次为了改配置而发包了。但是springcloud config并没有彻底的帮我们解决配置自动更新的问题。我们在config章节中我们遗留最后是每次修改git仓库后需要人为手动调用actuator/refresh接口才能促使配置的更新。当时也指出了在分布式微服务众多的情况人为调用接口耗时而且没有保障！！！当然你也可以写个脚本批量调用。但是今天我们即将学习的springcloud bus正好可以我们规避掉上述的问题
• 之前在springcloud config中有一点这里做一个补充说明。在git仓库发生变化时如何进行调用refresh接口。主要是通过git仓库的WebHooks来进行回调的。

整合springcloud bus

• config章节我们使用的是framework-root项目中的order模块来进行的。本次我们选择payment模块作为config客户端演示(再次操作熟练下记忆)。
• 首先我们的pom中需要添加config作为client。 和上次不同的是我们本次需要引入bus模块。因为需要用到端点刷新所以actuator必不可少

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>

配置文件

• 这里我们需要回顾上章节内容。首先需要在bootstrap.yml文件中指定config-server地址

spring:
  cloud:
    config:
      label: master
      name: config-server
      profile: dev
      uri: http://localhost:8070

• 因为bus借助到消息队列我们这里通过rabbitmq来进行演示。所以我们还需要配置rabbit信息在application.yml中

rabbitmq:
  host: 39.102.60.114
  port: 5672
  username: 'zxhtom'
  password: '025025'

• 为了更加了解每个模块功能涉及的端点情况，我们这里端点并没有全部放开所以需要啥端点需要我们自己配置

management:
  endpoints:
    web:
      exposure:
        include: hystrix.stream,info,bus-refresh

• 这里还是注意下因为springboot版本升级，在actuator监控中会发生变化。低版本中bus涉及的端点接口是/bus/refresh 。但是笔者这里actuator 是2.2.2.RELEASE版本的。这里的刷新接口是/actuator/bus-refresh 。

controller

• 当然这里为了测试方便能够直白的看到配置发生了变化。我们写个接口读取配置 .。和普通的接口唯一区别就是controller类上多了一个@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;
    

多实例部署

• 上面我们简单对payment进行改造完成了config-client的升级。但是在bus自动刷新config-client中需要多台config-client 。 这里抛个小技巧—idea一份代码多实例部署
• 其实这个功能我们在eureka章节中也提到过。不过笔者这里还是为什么大家整理出来就不需要你们去翻啦。毕竟最近高产不好找！！！

• 我们在idea中Edit Configurations 。 然后添加一个springboot启动类配置。

• 我们直接在VM Options中指定其他端口。这样就完成了多实例部署。但是有的情况下我们不仅仅需要端口不一样。那么我们就可以通过Enviroment varables 配置指定外部配置文件。这里我们仅仅设置端口不一样就可以了。

测试

• 经过上面的多实例部署的方式我们可以在idea中启动两个payment服务。

• 这里我们仅启动了config-server + euraka + 2* payment 。 实际上此时我们还未使用到eureka。 不过因为项目之前使用了eureka。
• 全部启动成功之后我们先访问两个payment服务中配置接口查看此时的配置信息。

• 然后我们在修改仓库中的对应的值，这里对应git仓库中config-server-dev.properties 。 至于为什么是这个文件就不分析了config章节里详细分析过了。
• 修改完仓库配置文件后，就到了我们bus的重头菜了，这里我们payment起了两个实例。为什么我要起多个实例了就是为了这里能够演示蔓延的效果。我们这个时候通过刷新其中一个实例的数据就可以实现两个实例数据全部刷新了。但是actuator/refresh这个接口是不能满足的我们需要使用actuator/bus-refresh来实现。

• 刷新完之后我们在访问两个payment数据会发现发生变化。这里读者自己操作下就可以看出效果了。

各归其位

• 不知道你有没有发现，上面通过bus我们实现了只需要执行一次刷新接口就可以完成所有的配置刷新了。但是还有有点缺点的，springcloud bus模块在springcloud中的定位是【消息总线】 。 总线的意思个人理解应该是龙头的意思。但是上面的实现好像只是一个中转的作用。就好像一个组织里龙头老大需要听命与其中一个手下办事一样
• 所有大多数项目架构中都不采用上述的方式来实现config的动态刷新。而是将config-server进行改造升级。让config-server拥有bus刷新的能力。这样在git仓库中钩子配置成config-server对应的刷新接口就可以了。这样从职能上分析也会变得职责分明；总线做数据的回调、各个微服务订阅消息刷新配置就可以了。
• 还有人说为了让职责更加的分明，我们可以新建一个模块叫做bus。让他充当钩子回到的函数。这样config-server做为配置的数据源、config-client读取配置、bus作为配置刷新通知功能。这样三者互相相辅相成。
• 总之，至于怎么划分就是每个架构中需要考虑的事情了。我们这里不做探讨。

局部刷新

• 上面通过引入第三方模块我们将模块功能职责分的很明晰了。而且也能够实现配置的动态刷新，但是有的时候我们服务刷新配置的消耗是巨大这种情况我们就需要精准刷新。换句话说就是如非必要拒绝刷新。有的时候我们git仓库并不会影响到所有模块的刷新这个时候我们就需要只刷部分服务。
• 上述中两个payment端口分别为8001/8003 。 加入这个时候我们想在git更新时只刷新8003端口服务。我们可以调用刷新接口是指定服务名
• localhost:8092/actuator/bus-refresh/cloud-payment-service:8003 。 这样8003的payment的配置会发生变化。而8001的配置还是之前旧数据
• 重点就是在刷新接口上。actuator/bus-refresh/destination 。 destination的取值就是对我们下发服务的一种描述。关于他的格式主要是如下
• $spring.cloud.client.hostname:$spring.application.name:$spring.application.instance_id:$server.port 。正常情况下我们通过$spring.application.name:$server.port进行识别。

源码

点我下载哦