Spring Cloud之统一配置中心Config初体验

　　对于配置的重要性懂的都懂。在普通的单体应用中通常使用配置文件管理应用的所有配置(*.yml/*.properties)，但随着微服务数量会在产品中不断增加，考虑系统的可伸缩性和可扩展性时就必须考虑配置管理问题 。在长期的实践中，要做好微服务的配置管理，通常需要处理好以下内容：

　　1）在微服务架构中配置数据与服务实例不要在同一个地方，最好各自独立分开。

　　2）在每个微服务中对于通过硬编码的方式从某个配置文件、远程仓库或者数据中读取 配置数据是拒绝的。最好是通过一种更通用的方式让微服务可快速加载这些配置资源。

　　3）虽然微服务是分布式的，但是对于配置文件的管理最好的集中式的。通过对配置文件的集中式管理可以非常方便地对微服务的配置进行统一修改和发布，并能够建立版本机制以便后续进行配置数据的回溯。

　　4）当采用集中式的配置后，如何能够保证配置服务的高可用性也是一个非常重要的考量因素，否则一旦配置服务不可用，就会造成整个服务的“雪崩”效应。

　　SpringCloud提供的Config子项目就支持以上需要处理的内容，具有中心化、版本控制、支持动态更新和语言独立等特性。Spring Cloud Config的两个角色类似Eureka——Server和Client。

　　Server作为配置中心的服务端承担如下重任：

　　　　1）当客户端获取配置时，服务端及时从仓库中获取配置副本，从而保障配置数据未最新。

　　　　2）支持从yml/json/properties等文件加载配置。

　　　　3）配合Eureka可以实现服务发现，配合CloudBus可实现配置推送更新。

　　　　4）默认配置存储基于git仓库，从而支持 配置版本管理。

　　对于Client则相对简单，即各个微服务只需在引导配置文件(bootstrap.yml/properties)中声明所使用的的配置服务器地址即可。

　　关于配置中心Config的体验实操，从最简单的微服务配置升级改造开始。其过程中遇到了很多小问题，下面将以注意事项一一记录：

　　未进行配置集中管理的项目结构如下：

　　　　　　　　　　

　　其中：1）parent就是整个项目的父类

　　　　　2）service-discovery就是Eureka作为服务注册

　　　　　3）product-service是服务消费端

　　　　　4）user-service是服务提供端

　　　　　　　　　　

　　将以上项目进行升级为配置版本化管理的项目，如下：

　　1）建立config服务端

　　　　项目结构：

　　　　　　　　　　

　　　　配置xml：

　　　　　　　　　　

 　　　　启动类(Application)：

　　　　　　　　　　

 　　　　配置文件(application.properties)：

　　　　　　　　　　

 　　　　创建应用配置文件：

　　　　　　productservice.properties：

　　　　　　　　

 　　　　userservice.properties：

　　　　　　　　

 　　　　以上两个配置文件上传至配置git仓库，就是config服务配置文件中的，注意上传文件名是有一定规则的：{application}-{profile}.yml 或者 {application}-{profile}.properties，其中， application为应⽤名称， profile指的是环境（⽤于区分开发环境，测试环境、⽣产环境等）

　　　　其中上传仓库的过程就是git应用实践的过程，对于git命令的记忆可以参考下图：

　　　　　　　　　　

　　　　启动Config服务，在Postman中输入http://localhost:8888/productservice/default并访问，可以看到git仓库中的配置文件已经被配置服务器正确读取到了，具体如下图示：

　　　　　　　　

　　对于config客户端的升级改造主要是配置文件，如下：

　　2）改造product端

　　　　xml中添加：

　　　　　　　　　　

 　　　　对于Spring Boot应用来说有两个配置文件，一个是application.properties配置文件，另一个是bootstrap.properties。应用在启动时会根据bootstrap.properties配置文件创建一个引导(Bootstrp Contex)上下文的文件。该文件将负载从外部加载配置属性并进行相应的解析，同时作为应用(Application  Context)上下文的父上下文。此外这两个上下文虽然具有不同的含义，但是仍将共享一个从外部获取的Environment。

　　　　默认情况下，引导上下文的配置属性具有高优先级，不会被本地配置覆盖，所以所要增加的配置属性信息就不是在application.properties中而是在bootstrap.properties配置文件中。

　　　　product端目录结构：

　　　　　　　　　　

 　　　　bootstrap.properties中内容：

　　　　　　　　　　

 　　　　注意红框中的内容是启动服务时报错处理的方式有些不能同时存在，有些就是不支持。

　　　　文件中内容除了服务端口、服务名及日志级别，其他都是与config配置相关的内容。此处默认使用default配置，如果不是则需要指定启用的profile：spring.cloud.config.profile=dev/sit/uat等。

　　3）改造user端同product端类似。

　　 启动config客户端服务失败，什么原因呢？因为cloud2020.*后版本config引导包不再包含bootstrap包，所以需要在pom.xml中添加这个包：

　　　　　　　　

 　　启动成功后，postman中输入http://localhost:2200/products/3/comments并访问，成功：

　　　　　　　　

 　　为什么cloud2020.*后的config版本中不包含bootstrap啦呢?对于存量项目如何处理这个问题呢？最好的方式就是参考官网Spring Cloud Config