springcloud 配置容灾_[springcloud数据库同步]spring cloud config–基于JDBC数据库配置

在线QQ客服：1922638

专业的SQL Server、MySQL数据库同步软件

Spring Cloud Config

Spring Cloud Config为分布式系统中的外部配置提供服务端和客户端支持，所谓的服务端是用一台，或者一组(为实现高可用)机器实现从某个固定的地方，默认是git，也可以是其它版本控制工具如SVN，文件服务器，或者JDBC等源头获取配置信息。然后给多个客户端使用，做到统一配置。

一、先动手，创建Spring Cloud Config Server

1、建立Spring boot项目，建立的时候除了勾选web，再勾选一个cloud config-> config server

2、配置application.properties(application.yml)

在创建完项目之后，需要等待maven加载依赖，不然无法进行下一步。我这一步经常卡住，可能是网络渣渣，然后我会将idea中下载maven的progress停止掉。去文件所在目录中敲mvn命令更新，一般会很快。然后回过头来有可能停止maven的操作还卡在那里，索性关掉idea重新打开就好了。

到这里我们停一下，稍微看下源码，spring cloud有几种配置方式，都在下图里了。

默认是使用git来配置，git这个东西不太会用，其实用来讲spring cloud config程度的”会用”我还是会的，只是发现好特么卡。我们可以使用本地配置，svn配置，或者数据库配置。其实大同小异。git、svn配置的不讲，大家自己去百度搜，基于JDBC的着重再讲一下。先从最简单的本地配置开始。

#指定应用程序名称

spring.application.name=config-server

#指定端口

server.port=8888

#指定配置方式是本地文件

spring.profiles.active=native

#配置文件的目录

spring.cloud.config.server.native.search-locations=D:/spring-config/config-file

我们去D盘下，建这两个目录，然后按照xx-xxx的命名规则，建一个.properties的配置文件。比如我们叫做config-dev.properties。

3、打开Application.java，添加一句@EnableConfigServer，开启配置中心服务器选项。

4、浏览器里面敲击http://localhost:8888/config/dev，就可以看到是否能成功获取配置

扩展:

1、扩展名只能是.properties或者.yml

基于文件的叫别的扩展名是不行的，只能叫xxx.properties，或者xxx.yml也可以。假设我们把config-dev.properties改成config-dev.txt就不行

2、即使找不到也会有返回信息的

即使查询不到配置值，也会有返回信息，会把查询信息返回回来，所以要看后半段的”propertySources”是否为空。

3、目标文件应该长什么样

Spring配置规范，要求按照applicationName+profile+label组合的方式来存放配置资源，供客户端读取。其中label是可选的。配置源可以通过三种方式组织，restful，xx-xx.yml，xx-xx.properties，也就是一共包括6种方式，每一种都可缺省label的方式。其中jdbc通过restful组织，其它方式是基于文件系统的，通过后两种方式组织，注意这两种方式的label的位置是不相同，基于文件系统时候，label拼在上级目录的最后(不是一层新的目录，而是就拼在上级目录的最后，等于说是用来区分上级目录的，看到后面会明白)。

restful(jdbc)

application/profile[/label]

yml (基于文件系统)

[label/]application-profile.yml

properties (基于文件系统)

[label]/application-profile.properties

4、中文乱码

看上面的图，会发现中文是乱码。

原因:jdk加载properties时候使用的是ISO-8859-1的字符集。

1)分析:

我们看一下源码，Spring使用PropertiesPropertySourceLoader这个类加载.properties文件，顺着代码往上追，最后是调用java.util.Properties的load方法。

java.util.properties中默认使用ISO-8859-1来解析，所以如果xml中出现中文是无法解析的。

2)解决方法1:

我们可以和PropertiesPropertySourceLoader这个类一样，实现自己的PropertySourceLoader接口，使用utf-8编码读取流。并通过spring boot的配置项org.springframework.boot.env.PropertySourceLoader=com.example.configserver.MyPropertiesHandler

重新指定读取.propeties文件的类。

3)解决方法2:

还可以索性使用yml来实现，这个是通过utf-8来解析的。可能代表java不倾向于properties格式的配置方式了，改用xml、yml这两种配置方式，这两种默认是utf-8的编码格式。

为了方便编写yml语句，可以通过在线yml编辑器，或者下载一款叫做Atom的编辑工具进行编辑。

5、label在不同模式下表现出的差异性

label可选。但是在不同的配置方式下，label表现出来不一样的效果，每一种模式都有一个自己实现的配置解析逻辑。在本地文件访问的时候，表现的特别奇怪。。。

经过查看源码，会发现并不是新增一层label的文件夹，比如localhost:8888/config/dev/test

我们新建一个test文件夹，把yml拷贝一份放进去，把name改成”小红”，新建一个test文件夹到”config-file”文件夹下。会发现访问不到。查看源码原来是要把config-file后面拼上label，就可以访问了(不是一层新的目录，而是就拼在上级目录的最后)。

6、profile这一层，会默认先不匹配，只匹配applicationName。如果有profile，会再匹配profile对不对。

先会把不带dev的这一层也会读取出来，假设我准备了两个文件config.yml和config-dev.yml，都会读出来。

然后我们再复制一个config-test试试看，发现dev的是读取不出来的，只能读取出config-test.yml和config.yml，也就是先用applicationName去找，然后如果有env，再用env去找。

7、本地配置的作用，只是提供一个临时开发环境，最好不要用于生产。

Spring官方文档上说，label是用来在版本控制工具作为配置源的时候，确定版本分支的，并且可以用逗号分隔的方式配置多个，找到任意一个都可以。

而native的初衷并不是用来配置的，是用来在开发时，方便本地模拟配置。应该使用成熟的基于文件系统的版本控制工具，如git和svn来实现。因为如果没有版本控制工具的支撑，需要我们自己实现事务、同步、版本控制，而git、svn天生拥有完美的事务、同步、版本控制的功能。也就是说spring-config期望从一个有版本控制的配置源来获取配置。本地数据只是一个临时解决方案。

另一种选择是使用数据库作为配置源，利用了数据库的同步性，实现复杂一些也能实现版本控制，并且更安全。

基于数据库的配置有一个缺点，数据库不容易表现出嵌套的属性。也可以，实现起来略微复杂。文件系统的话，使用properties或者yml，可以很快实现嵌套关系，以及嵌套关系的修改。但是数据库一旦实现起来，稳定性会相对高一些。毕竟文件里可以胡乱输入，经常敲少了一个空格什么的，所以在文件中编辑，最好借助高级的文本编辑工具，或者格式检查工具。

8、yml格式的坑

上面留了一个坑，会发现上面的值是”document”:”name 小明”,理论上应该是”name”:”小明”。上面的yml格式是错误的，标准的yml，属性的冒号后面需要有个空格，然后子属性不需要空格，子属性往后缩进两个空格，而不是tab。类似下面的写法:

name: 大壮

age: 22

tt:

qq: 33

上面的冒号后面没加空格，加一下返回值就正确了。

二、创建spring cloud config客户端

1、客户端会根据自身的信息，拼接成url从服务器中拿属于自己的数据

通过spring.cloud.config.uri表示server的地址，spring.cloud.config.profile表示当前环境，spring.cloud.configlabel表示标签，uri和spring.application.name和profile,label一起作为查询条件。

2、Spring Clound Config的获取配置所需要的信息需要写在bootstrap.properties(bootstrap.yml)中。

application.yml与bootstrap.yml

bootstrap.yml会在application.yml前面加载。

所以一些需要提前进行的操作，为保证提前执行，需要放在bootstrap.yml中。如加密解密，获取配置信息。application.yml中的数据不会做其它操作，直接就当key value来读取。

所以spring.application.name 和 spring.cloud.config.xxx相关的配置，应该丢到bootstrap.yml中。配置如下:

#指定配置模式，目前是dev模式

讲解application.yml和bootstrap.yml差别的帖子网上一搜一大把

3、准备一个使用到配置信息的Controller做测试

输出:

三、从jdbc中获取配置信息

jdbc可以依赖数据库来实现数据同步，Spring并没有提供固定的配置页面，可以自己实现比较灵活的编辑、配置页面(写个前台，增删改查就行了，但要注意嵌套属性如何维护)

1、添加jdbc依赖

添加starter-jdbc和对应数据库的连接jar包，我们用mysql试一下。

2、修改application.properties

改成jdbc，指定数据连接参数，指定查询sql，这一步有点好玩，后面会细讲一下

3、查看Spring默认的sql

使用JdbcEnvironmentProperties构建查询模块逻辑，查看源码会发现这里面有默认的SQL，所以假设我们不写sql，按照这个表名/字段名(表名PROPERTIES，字段名KEY，VALUE)建表就可以了。假设我们想定制更为复杂的逻辑，需要使用自己的表和、字段和SQL。

1)我们来实现定制的sql，这样逻辑也包含默认的逻辑

先建个表，假设叫做server_config，里面两个值，我们不叫他Key和Value，换一下，叫name和value，后面查询字段，也不是application、profile和label，假设就是aa、bb、cc看看spring能不能认出来。我们建一个这样的表:

CREATE TABLE server_config (

NAME VARCHAR (32),

VALUE VARCHAR (256),

aa VARCHAR (256),

bb VARCHAR (256),

cc VARCHAR (256)

) ;

对应查询语句就是。

2)label在jdbc中的逻辑，不能为空，为空默认为”master”

我以为默认label是空的也可以，一开始表里面label没有给值，会发现查不到内容。debug发现label这个参数默认给了”master”

3)applicationName和profile也都有默认值

继续往下走，发现env还给了default进行查询

还有app=”application”, env=”dev” 和

app=”application”，env=”default”

我们照着这个debug的参数值，多准备点数据试试看

我擦嘞，都能查出来。查看源码

果然是，label为空，就会给master，profile为空就给default，profile不为default，会加上default，也就是一定会有default和我们自定义的值，同样，默认会有个application的名字和我们自定义的查询条件。

3)字段名称怎么映射的:

看源码有这么一句话

这个里面的extractor(字面意思抽取器)定义了如何从ResultSet中获取值

查看代码会发现是这样的逻辑

取第一个和第二个字段，做map的key和value，不管你自己起叫什么名字。

说明了几点:

1、sql语句的三个参数是有默认值的。

2、字段名也不用严格限定，spring会取前两个，按照第一个为key，第二个为value的逻辑构成map键值对的。

3、除了我们的查询条件，spring也会叠加上自己认为应该是默认值的值，算是一种框架的约定，我们即使扩展，也不要偏的过多，否则会带来不必要的麻烦。

那么，到底能不能完全自定义？？？答案是可以的。

网上有的文章自己实现DatabasesRepositoryConfiguration。。。但是文章看起来很老，我怀疑是不是当时没有JDBC作为后端支撑的配置方式。感兴趣的可以搜下看看，但是我觉得按照Spring提供的限定已经可以使用了。

后面再讲高可用的配置中心如何实现