SpringCloud实战7-Config分布式配置管理

分布式环境下的统一配置框架，已经有很多了，好比百度的disconf,阿里的diamand

官方文档对spring Cloud Config的描述以下：

　　Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持，使用Config Server,您能够在全部环境中管理应用程序的外部属性。客户端和服务器上的概念映射与Spring Environment和PropertySource抽象相同，

　　所以它们与Spring应用程序很是契合，但能够与任何以任何语言运行的应用程序一块儿使用。随着应用程序经过从开发人员到测试和生产的部署流程，您能够管理这些环境之间的配置，并肯定应用程序具备迁移时须要运行的一切。

　　服务器存储后端的默认实现使用git，所以它轻松支持标签版本的配置环境，以及能够访问用于管理内容的各类工具。很容易添加替代实现，并使用Spring配置将其插入。

 

1.为何要配置中心？

一个应用中不仅是代码,还须要链接资源和其它应用,常常有不少须要外部设置的项去调整应用行为,如切换不一样的数据库，设置功能开关等。

随着系统微服务的不断增长，首要考虑的是系统的可伸缩、可扩展性好，随之就是一个配置管理的问题。各自管各自的开发时没什么问题，到了线上以后管理就会很头疼，到了要大规模更新就更烦了。

并且你不可能中止你的服务集群去更新的你配置，这是不现实的作法，所以springcloud配置中心就是一个比较好的解决方案，下图就是一个springcloud配置中心的解决方案：

 

常见的配置中心的实现方法有:

　　1.硬编码(缺点:须要修改代码,风险大)

　　2.放在xml等配置文件中,和应用一块儿打包(缺点:须要从新打包和重启)

　　3.文件系统中(缺点:依赖操做系统等)

　　4.环境变量(缺点:有大量的配置须要人工设置到环境变量中,不便于管理,且依赖平台) 5.云端存储(缺点:与其余应用耦合)

 

Spring Cloud Config就是云端存储配置信息的,它具备中心化,版本控制,支持动态更新,平台独立,语言独立等特性。其特色是：

　　1.提供服务端和客户端支持(spring cloud config server和spring cloud config client)
　　2.集中式管理分布式环境下的应用配置
　　3.基于Spring环境，无缝与Spring应用集成
　　4.可用于任何语言开发的程序
　　5.默认实现基于git仓库，能够进行版本管理
　　6.可替换自定义实现

spring cloud config包括两部分：

　　1.spring cloud config server 做为配置中心的服务端：

　　　　1.拉取配置时更新git仓库副本，保证是最新结果

　　　　2.支持数据结构丰富，yml, json, properties 等

　　　　3.配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新

　　　　4.配置存储基于 git 仓库，可进行版本管理

　　　　5.简单可靠，有丰富的配套方案

　　2.Spring Cloud Config Client 客户端：

　　　　1.Spring Boot项目不须要改动任何代码，加入一个启动配置文件指明使用ConfigServer上哪一个配置文件便可

 

SpringCloud Config与百度的disconf之类的有很大不一样，主要区别在于下面三点：

　　1.配置的存储方式不一样：disconf是把配置信息保存在mysql、zookeeper中，而spring cloud config是将配置保存在git/svn上 （即：配置当成源代码同样管理）

　　2.配置的管理方式不一样：spring cloud config没有相似disconf的统一管理界面，既然把配置都当成git之类的源码来看待了，git的管理界面，就是配置的管理界面

　　3.配置变化的通知机制不一样：disconf中配置变化后，依赖zk的事件watcher来通知应用，而spring cloud config则是依赖git每次push后，触发webhook回调，最终触发spring cloud bus(消息总线），而后由消息总线通知相关的应用。

从配置变化的通知机制上看，若是有100个应用节点，都依赖于统一配置，若是修改了配置，只想让某几个节点"灰度"更新配置，spring cloud config server更容易作到，这一点相对disconf更灵活

 

首先SpringCloud Config 是分为Server端和Client端的，Server端负责管理配置，Client端用来加载配置。咱们每个为服务都要集成一个Client端的。上面也提到过。所以，咱们如今看一下Config的Server端的Demo实现。

首先在原来的项目中新建一个springcloud-config-server模块，而且引入相关依赖，以下：

　　<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-server</artifactId>
        <version>1.4.0.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-eureka</artifactId>
        <version>1.3.5.RELEASE</version>
    </dependency>

咱们能够看到引入了Eureka，为何呢？很明显是为了高可用。

接着在启动类上面加入@EnableConfigServer注解，表示这里是配置中心服务。还有Eureka的客户端的注解代码以下：

@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class ConfigApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigApplication.class, args);
    }
}

application.yml配置以下：

server:
  port: 7000
#服务名字
spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
#git 仓库的地址
          uri: https://gitee.com/xxxx/springcloud-config.git
#git 仓库的帐号密码
          username: xxx
          password: xxx
#加入注册中心，实现高可用
eureka:
  client:
    service-url:
       defaultZone: http://localhost:8888/eureka/,http://localhost:8889/eureka/

注意了，前提是你必需要在git仓库中先创建一个仓库，而后配置两个配置，一个开发dev,一个测试test  以下图：

dev的内容以下：

test的内容以下：

好了,让咱们把springcloud-config模块启动起来，启动启动类，运行，访问git仓库中的cloud-config-dev.properties,以下：

 

接下来，咱们进行springcloud Config的Client端的Demo,以下：

首先引入Client端的相关依赖，以下：

　　　　<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <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>
            <version>1.4.0.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
            <version>1.3.5.RELEASE</version>
        </dependency>

这里提一下，为何须要引入前面的actuctor依赖，由于，咱们Client端须要在不重启的状况下，及时更新拉取加载配置中心的改变，而后修改内存中的配置的值。 

接着在Client启动类的打上@EnableDiscoveryClient的注解，来注册到注册中心去，以下：

@SpringBootApplication
@EnableDiscoveryClient
public class ConfigClientApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigClientApplication.class, args);
    }
}

 

接下来这步骤很关键，就是要将Client模块下的application.yml文件改成bootstrap.yml,这是很关键的，由于bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml。就比如如，你应用程序都跑起来了，你配置还没加载，这不是扯淡吗？

以下：

 

 

 

server:
  port: 7005
spring:
  application:
    name: cloud-config
  cloud:
    config:
#启动什么环境下的配置，dev 表示开发环境，这跟你仓库的文件的后缀有关，好比，仓库配置文件命名格式是cloud-config-dev.properties,因此profile 就要写dev
      profile: dev
#面向服务，容许被发现
      discovery:
        enabled: true
#这个名字是Config Server端的服务名字，不能瞎写。
        service-id: config-server
#注册中心
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8888/eureka/,http://localhost:8889/eureka/
#是否须要权限拉去，默认是true,若是不false就不容许你去拉取配置中心Server更新的内容
management:
  security:
    enabled: false

 

 接着写一段测试代码，以下，创建一个测试Controller，代码以下：

@RestController
//这里面的属性有可能会更新的，git中的配置中心变化的话就要刷新，没有这个注解内，配置就不能及时更新
@RefreshScope
public class TestController {

    @Value("${name}")
    private String name;
    @Value("${age}")
    private Integer age;

    @RequestMapping("/test")
    public String test(){
        return this.name+this.age;
    }
}

接着启动启动该工程，运行结果以下：

首先咱们咱们先看没更新配置以前的值，以下：

接着咱们去git仓库中修改age的值为24，再用postman来发送post请求localhost:7005/refresh,以下：

能够看到postman返回config.client.version信息，表示告知Client，远程的仓库中的配置中心已经更新了的配置版本信息，改变的值为age。

接着咱们继续刷新浏览器，localhost:7005/test,看一下年龄是否更新了，以下：

能够看到年龄跟新到24了。

 

可是这样就行了吗？虽然服务没有重启，可是咱们要一个服务一个服务的发送post请求，咱们能受的了吗？这比以前的没配置中心好多了，那么咱们如何继续避免挨个挨个的向服务发送Post请求来告知服务，你的配置信息改变了，须要及时修改内存中的配置信息。

这时候咱们就不要忘记消息队列的发布订阅模型。让全部为服务来订阅这个事件，当这个事件发生改变了，就能够通知全部微服务去更新它们的内存中的配置信息。这时Bus消息总线就能解决，这留到下一篇随笔讲解。