Spring Cloud构建微服务架构(四)分布式配置中心(续)
本文接之前的《Spring Cloud构建微服务架构(四)分布式配置中心》,继续来说说Spring Cloud Config的使用。
先来回顾一下,在前文中我们完成了什么:
- 构建了config-server,连接到Git仓库
- 在Git上创建了一个config-repo目录,用来存储配置信息
- 构建了config-client,来获取Git中的配置信息
在本文中,我们继续来看看Spring Cloud Config的一些其他能力。
高可用问题
传统作法
通常在生产环境,Config Server与服务注册中心一样,我们也需要将其扩展为高可用的集群。在之前实现的config-server基础上来实现高可用非常简单,不需要我们为这些服务端做任何额外的配置,只需要遵守一个配置规则:将所有的Config Server都指向同一个Git仓库,这样所有的配置内容就通过统一的共享文件系统来维护,而客户端在指定Config Server位置时,只要配置Config Server外的均衡负载即可,就像如下图所示的结构:
注册为服务
虽然通过服务端负载均衡已经能够实现,但是作为架构内的配置管理,本身其实也是可以看作架构中的一个微服务。所以,另外一种方式更为简单的方法就是把config-server也注册为服务,这样所有客户端就能以服务的方式进行访问。通过这种方法,只需要启动多个指向同一Git仓库位置的config-server就能实现高可用了。
配置过程也非常简单,具体如下:
config-server配置
- 在
pom.xml
的dependencies节点中引入如下依赖,相比之前的config-server就,加入了spring-cloud-starter-eureka
,用来注册服务
1
2
3
4
5
6
7
8
9
10
|
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
</dependencies>
|
- 在
application.properties
中配置参数eureka.client.serviceUrl.defaultZone
以指定服务注册中心的位置,详细内容如下:
1
2
3
4
5
6
7
8
9
|
spring.application.name=config-server
server.port=7001
# 配置服务注册中心
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/
# git仓库配置
spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/SpringCloud-Learning/
spring.cloud.config.server.git.searchPaths=Chapter1-1-8/config-repo
spring.cloud.config.server.git.username=username
spring.cloud.config.server.git.password=password
|
- 在应用主类中,新增
@EnableDiscoveryClient
注解,用来将config-server注册到上面配置的服务注册中心上去。
1
2
3
4
5
6
7
8
9
10
|
@EnableDiscoveryClient
@EnableConfigServer
@SpringBootApplication
public class Application {
public static void main(String[] args) {
new SpringApplicationBuilder(Application.class).web(true).run(args);
}
}
|
- 启动该应用,并访问
http://localhost:1111/
,可以在Eureka Server的信息面板中看到config-server已经被注册了。
config-client配置
- 同config-server一样,在
pom.xml
的dependencies节点中新增spring-cloud-starter-eureka
依赖,用来注册服务:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
</dependencies>
|
- 在
bootstrap.properties
中,按如下配置:
1
2
3
4
5
6
7
8
|
spring.application.name=didispace
server.port=7002
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=config-server
spring.cloud.config.profile=dev
|
其中,通过eureka.client.serviceUrl.defaultZone
参数指定服务注册中心,用于服务的注册与发现,再将spring.cloud.config.discovery.enabled
参数设置为true,开启通过服务来访问Config Server的功能,最后利用spring.cloud.config.discovery.serviceId
参数来指定Config Server注册的服务名。这里的spring.application.name
和spring.cloud.config.profile
如之前通过URI的方式访问时候一样,用来定位Git中的资源。
- 在应用主类中,增加
@EnableDiscoveryClient
注解,用来发现config-server服务,利用其来加载应用配置
1
2
3
4
5
6
7
8
9
|
@EnableDiscoveryClient
@SpringBootApplication
public class Application {
public static void main(String[] args) {
new SpringApplicationBuilder(Application.class).web(true).run(args);
}
}
|
- 沿用之前我们创建的Controller来加载Git中的配置信息
1
2
3
4
5
6
7
8
9
10
11
12
13
|
@RefreshScope
@RestController
public class TestController {
@Value("${from}")
private String from;
@RequestMapping("/from")
public String from() {
return this.from;
}
}
|
- 完成了上述配置之后,我们启动该客户端应用。若启动成功,访问
http://localhost:1111/
,可以在Eureka Server的信息面板中看到该应用已经被注册成功了。
- 访问客户端应用提供的服务:
http://localhost:7002/from
,此时,我们会返回在Git仓库中didispace-dev.properties
文件配置的from属性内容:”git-dev-1.0”。
配置刷新
有时候,我们需要对配置内容做一些实时更新的场景,那么Spring Cloud Config是否可以实现呢?答案显然是可以的。下面,我们看看如何进行改造来实现配置内容的实时更新。
在改造程序之前,我们先将config-server和config-client都启动起来,并访问客户端提供的REST APIhttp://localhost:7002/from
来获取配置信息,可以获得返回内容为:git-dev-1.0
。接着,我们可以尝试使用Git工具修改当前配置的内容,比如,将config-repo/didispace-dev.properties
中的from的值从from=git-dev-1.0
修改为from=git-dev-2.0
,再访问http://localhost:7002/from
,可以看到其返回内容还是git-dev-1.0
。
下面,我们将在config-client端增加一些内容和操作以实现配置的刷新:
- 在config-clinet的
pom.xml
中新增spring-boot-starter-actuator
监控模块,其中包含了/refresh
刷新API。
1
2
3
4
|
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
|
- 重新启动config-clinet,访问一次
http://localhost:7002/from
,可以看到当前的配置值 - 修改Git仓库
config-repo/didispace-dev.properties
文件中from
的值 - 再次访问一次
http://localhost:7002/from
,可以看到配置值没有改变 - 通过POST请求发送到
http://localhost:7002/refresh
,我们可以看到返回内容如下,代表from
参数的配置内容被更新了
1
2
3
|
[
"from"
]
|
- 再次访问一次
http://localhost:7002/from
,可以看到配置值已经是更新后的值了
通过上面的介绍,大家不难想到,该功能还可以同Git仓库的Web Hook功能进行关联,当有Git提交变化时,就给对应的配置主机发送/refresh
请求来实现配置信息的实时更新。但是,当我们的系统发展壮大之后,维护这样的刷新清单也将成为一个非常大的负担,而且很容易犯错,那么有什么办法可以解决这个复杂度呢?后续我们将继续介绍如何通过Spring Cloud Bus来实现以消息总线的方式进行通知配置信息的变化,完成集群上的自动化更新。
Spring Cloud构建微服务架构(四)分布式配置中心(续)相关推荐
- Spring Cloud构建微服务架构:分布式配置中心【Dalston版】
Spring Cloud Config是Spring Cloud团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分.其中服务端也称为 ...
- Spring Cloud构建微服务架构:分布式配置中心(加密解密)
最近正好想发一篇关于配置中心加密的细节内容,结果发现基础的加密解密居然漏了,所以在这个入门系列中补充一下.后面再更新一下,使用配置中心的一些经验和教训. 在微服务架构中,我们通常都会采用DevOps的 ...
- Spring Cloud构建微服务架构:分布式服务跟踪(整合zipkin)【Dalston版】
通过上一篇<分布式服务跟踪(整合logstash)>,我们虽然已经能够利用ELK平台提供的收集.存储.搜索等强大功能,对跟踪信息的管理和使用已经变得非常便利.但是,在ELK平台中的数据分析 ...
- Spring Cloud构建微服务架构:分布式服务跟踪(整合logstash)【Dalston版】
通过之前的<入门示例>,我们已经为两个由SpringCloud构建的微服务项目 trace-1和 trace-2引入了Spring Cloud Sleuth的基础模块 spring-clo ...
- Spring Cloud构建微服务架构:分布式服务跟踪(跟踪原理)
通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一 ...
- Spring Cloud构建微服务架构:分布式服务跟踪(入门)
通过之前的N篇博文介绍,实际上我们已经能够通过使用它们搭建起一个基础的微服务架构系统来实现我们的业务需求了.但是,随着业务的发展,我们的系统规模也会变得越来越大,各微服务间的调用关系也变得越来越错综复 ...
- Spring Cloud构建微服务架构:分布式服务跟踪(入门)【Dalston版】
通过之前的N篇博文介绍,实际上我们已经能够通过使用它们搭建起一个基础的微服务架构系统来实现我们的业务需求了.但是,随着业务的发展,我们的系统规模也会变得越来越大,各微服务间的调用关系也变得越来越错综复 ...
- Spring Cloud构建微服务架构:分布式服务跟踪(抽样收集)【Dalston版】
通过 TraceID和 SpanID已经实现了对分布式系统中的请求跟踪,而这些记录的跟踪信息最终会被分析系统收集起来,并用来实现对分布式系统的监控和分析功能,比如:预警延迟过长的请求链路.查询请求链路 ...
- Spring Cloud构建微服务架构:分布式服务跟踪(收集原理)【Dalston版】
在本节内容之前,我们已经对如何引入Sleuth跟踪信息和搭建Zipkin服务端分析跟踪延迟的过程做了详细的介绍,相信大家对于Sleuth和Zipkin已经有了一定的感性认识.接下来,我们介绍一下关于Z ...
- Spring Cloud构建微服务架构:分布式服务跟踪(跟踪原理)【Dalston版】
通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一 ...
最新文章
- 嵌入式系统在井下煤炭井下监控系统的应用
- [中英对照]How PCI Works | PCI工作原理
- 欧几里得算法扩展欧几里得算法
- Windows访问Ubuntu8.10分区
- jQuery应用之(二)使用jQuery管理选择结果(荐)
- java xml获取属性值_java – 如何获取具体属性值的特定XML元素?
- 为什么我不建议产品经理硬“抄”别人的用户画像?
- 不要让别人左右自己的心情
- 解析MATLAB短时傅里叶变换函数spectrogram()
- 计算机论文中期报告进展情况,自动化毕业论文中期报告进展情况怎么写
- 领峰:个人如何投资白银炒白银有哪些方法
- 世界药林:首款PRCP抑制剂奥拉帕利已经批准4种适应症
- 专访OKEX Jay Hao:期权市场的需求从何而来?
- 小米电视刷鸿蒙系统,小米电视怎么刷鸿蒙OS系统?一招立省上千块
- 使用微信js-sdk上传语音并将语音下载到服务器
- 2022数学建模国赛B题思路分析
- 【C语言】字符数组初始化方法
- 10份可直接套用的华为项目管理模板
- ARM立即数合法性快速判断--求8位常数和4位移数位
- wp7和wp8的区别
热门文章
- 阶段3 1.Mybatis_09.Mybatis的多表操作_1 mybatis表之间关系分析
- 阶段1 语言基础+高级_1-3-Java语言高级_08-JDK8新特性_第1节 常用函数接口_13_常用的函数式接口_Predicate接口中的默认方法and...
- Linux笔记--Linux进程通信
- media=screen是什么意思?
- 写了一个验证数字范围的正则表达式
- html页面简单访问限制
- 在win7 64位上安装VS2015的问题汇总
- 【XSY2732】Decalcomania 可持久化线段树 分治
- MVC学习笔记----缓存
- 运行 Docker 容器时的安全风险:别丢了你的套接字