Spring Cloud构建企业级总线-第五部分分布式配置中心

     分布式配置管理应该是分布式系统和微服务应用的第一步。想象一下如果你有几十个服务或应用需要配置，而且每个服务还分为开发、测试、生产等不同维度的配置，那工作量是相当大的，而且还容易出错。如果能把各个应用的配置信息集中管理起来，使用一套机制或系统来管理，那么将极大的提高系统开发的生产效率，同时也会提高系统开发环境和生产环境运行的一致性。

                                           


     在传统开发中我们往往需要自己开发“配置管理服务器”，你可以使用Redis、Ldap、Zookeeper、Db等来存放统一配置信息，然后开发一个管理界面来进行管理。传统的做法没什么问题，和Spring Cloud所提供的配置管理方案相比，就是前者需要自己开发，而后者直接简单使用现成的组件即可。当然还有很重要的一点，Spring配置管理模块由于是Spring Boot核心来实现的，因此做了大量的工作，可以把一些启动参数进行外部配置，这在传统的方案中是很难办到的，因为涉及到要改写第三方组件的问题，难度很大。比如Web应用的绑定端口，传统应用只能在tomcat配置文件里改，而Spring
Cloud却可以放到远程，类似的还有数据库连接、安全框架配置等。

Spring Cloud分布式配置步骤

首选你需要创建存放配置文件的仓库，然后创建一个配置文件服务器，该服务器将配置文件信息转化为Rest接口数据，然后创建一个应用服务，该服务演示使用分布式配置文件信息。

创建配置文件存放仓库

Spring cloud使用git或svn存放配置文件，默认情况下使用git，因此你需要安装git私服或者直接使用互联网上的github或者git.oschina。

创建spring cloud配置服务器

配置文件仓库创建好了后，就需要创建配置管理服务器，如前所述该服务器只是将配置文件转换为rest接口服务，不做其它用途。这个服务器的功能也是spring cloud提供的，所以我们只需要引入相关jar包，稍微设置一下即可。

创建一个服务使用该远程配置

Spring Cloud Config

     相比较同类产品，Spring Cloud Config最大的优势是和Spring无缝集成，支持Spring里面Environment和PropertySource的接口，对于已有的Spring应用程序的迁移成本非常低，在配置获取的接口上是完全一致，结合SpringBoot可使你的项目有更加统一的标准（包括依赖版本和约束规范），避免了应为集成不同开软件源造成的依赖版本冲突。

     Spring Cloud Config就是我们通常意义上的配置中心，把应用原本放在本地文件的配置抽取出来放在中心服务器，从而能够提供更好的管理、发布能力。SpringCloudConfig分服务端和客户端，服务端负责将git（svn）中存储的配置文件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST方法触发各自的/refresh。

使用实例

配置Svn目录上的配置文件

首先在svn上面创建了一个文件夹config-repo用来存放配置文件，为了模拟生产环境，我们创建以下三个配置文件

 


didispace-config-dev.properties：开发环境
didispace-config-test.properties：测试环境
didispace-config-pro.properties：生产环境
didispace.properties：生产环境

    每个配置文件中都写一个属性from，属性值分别是git-dev-3.0，git-test-1.0，git-prod-1.0，git-default-1.0。下面我们开始配置server端

构建Config Server

通过Spring Cloud构建一个Config Server，非常简单，只需要三步：

pom.xml中引入spring-cloud-config-server依赖，完整依赖配置如下：
创建Spring Boot的程序主类，并添加@EnableConfigServer注解，开启Config Server

 

@SpringBootApplication
@EnableConfigServer
@EnableEurekaClient
public class ConfigServerApplication
{
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}

application.properties中配置服务信息以及svn信息，例如：application.properties里面
server.port=8761

spring.cloud.config.server.svn.uri=https://IP/...../cloudConfig
spring.cloud.config.server.svn.searchPaths=config-repo
spring.cloud.config.server.svn.username=
spring.cloud.config.server.svn.password=
spring.cloud.config.server.default-label=config-repo
spring.profiles.active=subversion
spring.application.name=spring-cloud-config-server

logging.levels.org.springframework.boot.env.PropertySourcesLoader=TRACE
logging.levels.org.springframework.cloud.config.server=DEBUG

#是否将eureka自身作为应用注册到eureka注册中心
eureka.client.register-with-eureka=true
eureka.client.fetch-registry=false
eureka.client.serviceUrl.defaultZone=http://IP:1111/eureka/
eureka.instance.prefer-ip-address=true
到此server端相关配置已经完成。

服务端验证

首先我们先要测试server端是否可以读取到svn上面的配置信息，直接访问：http://IP:8761/didispace/from，返回信息如下：



上述的返回的信息包含了配置文件的位置、版本、配置文件的名称以及配置文件中的具体内容，说明server端已经成功获取了svn仓库的配置信息。

如果直接查看配置文件中的配置信息可访问：http://IP:8761/didispace-dev.properties，返回：from:git-dev-3.0

修改配置文件didispace-dev.properties中配置信息为：from:git-dev-4.0，再次在浏览器访问http://IP:8761/didispace-dev.properties，返回：from: git-dev-4.0。说明server端会自动读取最新提交的内容

client端

主要展示如何在业务项目中去获取server端的配置信息

添加依赖

 

引入spring-boot-starter-web包方便web测试

开启更新机制
需要给加载变量的类上面加载@RefreshScope，在客户端执行/refresh的时候就会更新此类下面的变量值。

@RestController
@RefreshScope
class TestController {
@Value("${from}")
private String from;
@RequestMapping("/from")
public String from() {
return this.from;
}
} 
配置文件：
server.port=7002

spring.cloud.config.uri=http://IP:8761
spring.cloud.config.profile=from
spring.cloud.config.label=config-repo
spring.application.name=didispace

eureka.client.serviceUrl.defaultZone=http://IP:1111/eureka/
       我们再次来测试，首先访问http://IP:7002/from，返回：git-default-1.0，我将库中的值修改为git-default-1.01。在win上面打开cmd执行curl -X POST http://IP:7002/refresh，返回git-default-1.01说明已经更新了from的值。我们再次访问http://IP:7002/from，返回：git-default-1.01，客户端已经得到了最新的值。