使用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类似。

使用Spring Cloud Config进行分布式配置:自动重新加载配置

 

客户端上的端点只是一个大得多的系统的组件,而该系统需要被包含才能启用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所示。

使用Spring Cloud Config进行分布式配置:自动重新加载配置

 

使用@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方法来强制重新加载配置。

使用Spring Cloud Config进行分布式配置:自动重新加载配置

 

在客户端应用程序上调用/efresh端点后,开发人员将在日志文件中看到已经重新加载配置。现在,如果再次调用/ping,则会在响应中返回最新的属性值,如图5.7所示。该示例说明了热重载如何适用于Spring Cloud 应用程序,但它显然不是我们的目标解决方案。我们的下一步是启用与消息代理的通信。

使用Spring Cloud Config进行分布式配置:自动重新加载配置

 

使用来自消息代理的事件

前文已经提到过,开发人员可以选择两个与Spring Cloud Bus 集成的消息代理(Message Broker) 。在本示例中,将演示如何运行和使用RabbitMQ。关于这个解决方案有必要多做一些介绍,因为这是在本书中第一次处理它。RabbitMQ 已经发展成为最受欢迎的消息代理软件。它是用Erlang编写的,并且实现了高级消息队列协议(Advanced Message Queueing Protocol, AMQP)。它易于使用和配置,即使对于我们正在讨论的集群或高可用性等机制来说也不例外。

使用Spring Cloud Config进行分布式配置:自动重新加载配置

 

要在开发人员的机器.上运行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项目的讨论中将会对此做更详细的说明。

使用Spring Cloud Config进行分布式配置:自动重新加载配置

 

监视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所示。

使用Spring Cloud Config进行分布式配置:自动重新加载配置

 

与使用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 Config进行分布式配置:自动重新加载配置

spring cloud 入门系列七:基于Git存储的分布式配置中心--Spring Cloud Config

Spring Cloud-鸿鹄Cloud分布式微服务云系统—Config

Spring cloud--鸿鹄Cloud分布式微服务云系统—Config

Spring Cloud Config 分布式配置中心使用教程

Spring Cloud高可用的分布式配置中心 Spring Cloud Config