使用Spring Cloud Config进行分布式配置:自动重新加载配置
Posted jinggege795
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了使用Spring Cloud Config进行分布式配置:自动重新加载配置相关的知识,希望对你有一定的参考价值。
自动重新加载配置
前文已经讨论过Spring Cloud Config最重要的功能。现在我们可以实现一个示例,并通过它来演示如何将不同的后端存储用作存储库。但是,无论开发人员决定选择的是文件系统、Git还是Vault,客户端应用程序都需要重新启动才能从服务器端获取最新配置。当然,本示例有时候并不是最佳解决方案,特别是如果有许多微服务运行,并且其中一些使用相同的通用配置的话,则更是如此。
解决方案架构
即使开发人员已经为每一个应用程序创建了一个专用的property 文件,如果能有机会动态重新加载它而不必重启,那么这也是很有帮助的。很多人可能已经想到了,既然Spring Booit 可以有这样的解决方案,那么对于Spring Cloud来说自然也是适用的。本书第4章“服务发现"在解释从服务发现服务器注销时,曾经引入了一个端点/shutdown,它可以用于从容地关闭。
还有一个可用于Spring环境重启的端点,其工作方式与/shutdown类似。
客户端上的端点只是一个大得多的系统的组件,而该系统需要被包含才能启用SpringCloud Config的推送通知。最流行的源代码存储库提供商(如GitHub、GitLab和Bitbucket)能够通过提供WebHook机制发送有关存储库中更改的通知。开发人员可以使用提供商的Web仪表板将WebHook配置为URL和所选事件类型的列表。这样,提供商就可以使用包含提交列表的正文调用WebHook中定义的POST方法。
在项目中需要包含SpringCloudBus依赖项,以便在Config Server端启用监控端点。当由于WebHook激活而调用此端点时,Config Server 会准备并发送一个事件, 其中包含已通过最近一次提交 而修改的属性源列表。该事件将被发送给消息代理。Spring Cloud Bus为RabbitMQ和Apache Kafka提供了实现。对于RabbitMQ来说,可以通过包括spring-cloud- sarter -bus amqp依赖项来启用该项目:而对于Apache Kafka 来说,可以通过包括spring-cloud-starter -bus-kafka依赖项来启用。此外,还应为客户端应用程序声明这些依赖项,才能从消息代理那里接收到消息。开发人员还应该通过使用@RefreshScope注解所选的配置类来启用客户端上的动态刷新机制。此解决方案的架构如图5.5所示。
使用@RefreshScope重新加载配置
这次异常将从客户端开始。示例应用程序可在GitHub (
tp:/ihub.com/piomin/sample-spring-cloud-config-bus.git)上获得。 与前面的示例相同,它使用了Git 存储库作为后端存储,这也可以在GitHub hps:/itub.co/piomin/imple-pring.cloudo config-repo).上创建。此外,我们还向客户端的配置文件添加了一些新属性,并将更改提交到存储库。以下是客户端配置的当前版本。
eureka:
instance:
metadataMap :
zone: zone1
client:
serviceUrl :
defaultZone: http://localhost:8761/eureka/
server:
port: ${PORT:8081}
management:
security:
enabled: false
sample:
string:
property: Client ApP
int:
property:1
开发人员可以通过将management.security.enabled 设置为false 来禁用Spring Boot Actuator端点的安全性,这是在不传递安全凭证的情况下调用这些端点所必需的。此外还需要添加sample. string property和sample.int.property两个测试参数,以根据示例中的值来演示bean刷新机制。Spring Cloud为Spring Boot Actuator提供了一些额外的HTTP管理端点。其中一个是/refresh, 它负责重新加载Bootstrap上下文和使用@RefreshScope注解的刷新bean。这是一个HTTP POST方法,可以在客户端实例( htp://ocahost:808 1/refresh)上调用。在测试该功能之前,开发人员需要运行发现和配置服务器。应使用--springprofiles.active-zonel参数启动客户端应用程序。在以下类中,可以将测试属性sample.string.property和sample intproperty注入字段中。
@Component
@RefreshScope
public class ClientConfiguration {
@Value ("' {sample.string .property)")
private String sampleStringProperty;
@Value ("${sample. int.property}")
private int sampleIntProperty;
public String showProperties() {
return String. format("Hello from 8号d", sampleStringProperty,
sampleIntProperty);
}
}
该bean被注入ClientController 类并在ping方法中调用,该方法在ht:/ocalhosth8081/ping位置处公开。
@RestController
public class ClientController {
CAutowi red
private ClientConfiguration conf;
@GetMapping ("/ping")
public String ping() {
return conf. showProperties() ;
}
}
现在,开发人员可以改变client-service zonel.yml中测试属性的值并提交它们。如果调用Config Server HTTP端点/client-service/zone1,则将看到作为响应返回的最新值。但是,当调用客户端应用程序上公开的/ping方法时,开发人员仍会在如图5.6所示的屏幕截图的左侧看到较旧的值。为什么?其实这也很好理解,虽然Config Server 会自动检测存储库更改,但是客户端应用程序无法在没有任何触发器的情况下自动刷新。它需要重新启动才能读取最新设置,或者开发人员也可以通过调用之前所描述的/refresh方法来强制重新加载配置。
在客户端应用程序上调用/efresh端点后,开发人员将在日志文件中看到已经重新加载配置。现在,如果再次调用/ping,则会在响应中返回最新的属性值,如图5.7所示。该示例说明了热重载如何适用于Spring Cloud 应用程序,但它显然不是我们的目标解决方案。我们的下一步是启用与消息代理的通信。
使用来自消息代理的事件
前文已经提到过,开发人员可以选择两个与Spring Cloud Bus 集成的消息代理(Message Broker) 。在本示例中,将演示如何运行和使用RabbitMQ。关于这个解决方案有必要多做一些介绍,因为这是在本书中第一次处理它。RabbitMQ 已经发展成为最受欢迎的消息代理软件。它是用Erlang编写的,并且实现了高级消息队列协议(Advanced Message Queueing Protocol, AMQP)。它易于使用和配置,即使对于我们正在讨论的集群或高可用性等机制来说也不例外。
要在开发人员的机器.上运行RabbitMQ,最简便的方法是通过Docker容器。该容器已经公开了两个端口。第一个端口用于客户端连接(5672),第二个端口用于管理仪表板(15672)。此外,我们还使用了management标记来运行镜像(Image),以启用用户界面仪表板,这在默认版本中是不可用的。
docker run -d --name rabbit -P 5672:5672 -P 15672:15672 rabbi tmq:management
要为我们的示例客户端应用程序启用对于RabbitMQ 代理的支持,应该在pom.xml中包含以下依赖项。
<dependency>
<groupId>org . springframework. cloud</groupId>
<artifactId>spring-cloud-starter -bus- amqp</artifactId>
</ dependency>
该库包含自动配置设置。因为我们是在Windows系统上运行Docker,所以需要覆盖一些默认属性。 完整的服务配置存储在Git存储库中,因而更改仅影响远程文件。开发人员应该将以下参数添加到以前使用的客户端属性源版本中。该库包含自动配置设置。因为我们是在Windows系统上运行Docker,所以需要覆盖一些默认属性。完整的服务配置存储在Git存储库中,因而更改仅影响远程文件。开发人员应该将以下参数添加到以前使用的客户端属性源版本中。
spring:
rabbi tmq:
host: 192.168.99.100
port: 5672
username: guest
password: guest
此时如果运行该客户端应用程序,则将在RabbitMQ中自动创建交换消息和队列。开发人员可以登录htp://92/./ 168.99.100:15672.上的管理仪表板轻松查看。默认用户名和密码是guest/guest.如图5.8所示是笔者的RabbitMQ实例的屏幕截图,可以看到已经创建了一个名为springCloudBus的交换消息(Exchange),有两个绑定到客户端队列和Config Server队列(笔者已经使用更改运行它,详见第5.7.4 节中的说明)。在目前这个阶段,开发人员还不必着急深入了解RabbitMQ及其架构,在本书第11章“消息驱动的微服务”有关SpringCloudStream项目的讨论中将会对此做更详细的说明。
监视Config Server,上的存储库更改
Spring Cloud Config Server必须在前面描述的过程中执行两项任务。首先,它必须检测存储在Git存储库中的property文件中的更改。这可以通过公开特殊端点来实现,该端点将由存储库提供商通过WebHook调用。第二个步骤是准备并发送--个针对可能已更改的应用程序的
RefreshRemotcApplicationEvent 事件,这反过来又要求开发人员与消息代理建立连接。spring-cloud-config-monitor 库负责启用/monitor端点。要启用对RabbitMQ代理的支持,应该包含与客户端应用程序相同的启动工件。
<dependency>
<groupId>org. springframework. cloud</groupId>
<arti factId>spring-cloud-config-monitor</arti factId>
</ dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter -bus- amqp</artifactId>
</ dependency>
这还不是全部。开发人员还应在application.yml 中激活配置监控程序(Monitor) 。由于每个存储库提供商都在SpringCloud中具有专用实现,因而有必要选择应该启用哪一个存储库提供商。
spring:
application:
name: config- server
cloud:
config :
server :
monitor :
github :
enabled:: true
开发人员可以自定义更改检测机制。默认情况下,它会检测与应用程序名称匹配的文件中的更改。要覆盖该行为,需要提供
PropertyPathNotificationExtractor的自定义实现。它接受请求头和正文参数,并返回已更改的文件路径列表。为了支持来自GitHub的通知,可以使用spring-cloud- config-monitor提供的GithubPropertyPathNotifcationExtractor.
@Bean
publit Gi thubPropertyPathNoti ficationExtractor
gi thubPropertyPathNotificationExtractor() {
return new Gi thubPropertyPathNotificationExtractor();
}
1.手动模拟更改事件
monitor端点可以由Git存储库提供商( 如GitHub、Bitbucket 或GitLab). 上配置的WebHook调用。使用在localhost. 上运行的应用程序测试此类功能很麻烦。事实证明,开发人员可以通过手动调用POST /monitor来轻松模拟这样的WebHook激活。例如,Github命令应该在请求中包含标头X -Github-Event.具有property文件更改的JSON正文应该如以下cURL请求中所示。
$ curl -H "X-Gi thub-Event: push" -H "Content -Type: application/json" -X
POST -d ' {"commits": [ { "modified": ["client-service- zone1。yml"]}]}'
http: / /localhost: 8889 /monitor
现在,可以在client-service zonel.yml文件中更改并提交-一个属性的值,例如,修改属性sample.int.property.然后,可以使用前面示例命令中显示的参数调用POST /monitor方法。如果根据上面的说明配置了所有内容,则应在客户端应用程序端看到以下日志行:Received remote refresh request. Keys refreshed [sample int.property] (已接收到远程刷新请求。键值已刷新sample.int.property])。如果调用客户端微服务公开的/ping端点,那么它应该返回已更改属性的最新值。
2.使用GitLab实例
在本地进行测试对于那些不喜欢模拟事件的开发人员,我们提出了一个更实际的练习。但是,需要指出的是,它不仅需要开发技能,还需要掌握持续集成(Continuous Integration)工具的基本知识。我们将首先使用GitLab的Docker镜像在本地运行GitLab实例。GitLab 是一个开源的基于Web的Git存储库管理器,具有维基百科和问题跟踪的特点。它与GitHub或Bitbucket等工具非常相似,但可以轻松部署在本地计算机上。
docker run -d --name gitlab -P 10443:443 -P 10080:80 -P 10022:22
gitlab/gitlab-ce :latest
Web仪表板可在htp://92.16899.100:10080获得。第一步是创建管理员用户,然后使用提供的凭据登录。对于GitLab其实不必做过多介绍,它具有用户友好且直观的GUI界面,因而开发人员肯定能够轻松使用它。现在继续进行下一步操作,我们已经在GitLab中创建了一个名为sample-spring clou-config-repo的项目,开发人员可以从ht:/192.168.99.100: 1080/ootsample-spring -cloud-config-repo.git克隆它。我们在该位置提交了相同的配置文件集,可以在GitHub 上的示例存储库中找到。下一步是定义一个WebHook,它将通过推送通知调用Config Server的/monitor 端点。要为项目添加新的WebHook,需要转到Settings | Integration (设置|集成) 部分,然后用服务器地址填写URL字段(注意,是使用主机名而不是localhost),然后保持选中Push events (推送事件)复选框,如图5.9所示。
与使用GitHub 作为后端存储库提供商的Config Server 实现相比,我们需要在application.yml中更改已启用的monitor类型。当然,还需要提供不同的地址。
spring:
application:
name: config-server
cloud:
config:
server :
monitor:
gitlab:
enabled: true
git:
uri:
http://192.168.99.100:10080/root/ sample-spring-cloud-config-repo.git
username: root
password: root123
cloneOnStart: true
还应该注册另一个bean以实现PropertyPathNotificationExtractor。
@Bean
publio GitlabPropertyPathNotificationExtractor :
gitlabPropertyPathNotificationExtractor( {
return new GitlabPropertyPathNotificationExtractor();
}
最后,开发人员可以在配置文件中进行一些更改,此时WebHook应该被激活,并刷新客户端应用程序的配置。
小结
本章详细介绍了Spring Cloud Config 项目的最重要功能。与“服务发现"的介绍方式相同,本章从最基础的并且很简单的客户端和服务器端用例开始,详细讨论了Config Server的不同后端存储库类型,并且通过实现示例的方式说明了如何使用文件系统、Git甚至第三方工具(如Vault)作为property文件的存储库。本章还特别关注与其他组件(如服务发现或大型系统中的多个微服务实例)的互操作性。最后,本章演示了如何在不重启的情况下重新加载应用程序的配置,这是基于WebHooks 和消息代理实现的。总之,在阅读本章之后,开发人员应该能够将Spring Cloud Config 用作基于微服务架构的一个元素,并充分利用其主要功能。在掌握了使用Spring Cloud 实现“服务发现”和“配置服务器”功能之后,即可进行对服务间通信机制的讨论。在接下来的两章中,我们将分析与其相关的基本示例和一些更高级的应用,这些示例将演示若干个微服务之间的同步通信。
总结
因为文章包含的内容实在是太多了,就不给大家做过多的介绍了,需要这份文档来学习的小伙伴,可以转发此文关注小编。
扫码来获取就可以了!
以上是关于使用Spring Cloud Config进行分布式配置:自动重新加载配置的主要内容,如果未能解决你的问题,请参考以下文章
使用Spring Cloud Config进行分布式配置:自动重新加载配置
spring cloud 入门系列七:基于Git存储的分布式配置中心--Spring Cloud Config
Spring Cloud-鸿鹄Cloud分布式微服务云系统—Config
Spring cloud--鸿鹄Cloud分布式微服务云系统—Config