Spring-cloud微服务实战【九】：分布式配置中心config

  回忆一下,在前面的文章中,咱们使用了spring cloud eureka/ribbon/feign/hystrix/zuul搭建了一个完整的微服务系统,无论是队内仍是对外都已经比较完善了,那咱们的系统是否还有值得继续优化的地方呢?答案确定是有的,那就是分布式配置中心config.那什么是分布式配置中心,咱们为何又须要分布式配置中心呢?

什么是分布式配置中心?

  所谓配置中心,就是将配置的数据放在某种存储介质中,该介质能够是文件/数据库/中间件等等,像业界经常使用的zookeeper/Apollo/阿里开源的Nacos等等,阿里内部使用的config server/diamond/switch等等都是分布式配置中心.而在spring cloud中的分布式配置中心就是config.

为何须要分布式配置中心?

  一个完整的微服务系统,在实际的生产环境中会有许多的服务,每一个服务都有本身的配置文件,这些服务在本身的测试环境上管理本身的配置文件还好,但全部服务一旦到了生产环境,配置文件太多,对配置文件的管理就成了一个必不可少的工做,所以,咱们须要分布式配置中心来帮助咱们进行配置文件的管理.

spring cloud config使用

  spring cloud和eureka相似,也分为服务端和客户端,服务的主要是对配置文件进行管理,而客户端拉取服务端的配置文件,另外,咱们以前说配置中心依赖于某种存储介质,springcloud官方文档中是使用git,所以咱们还须要依赖git,首先咱们在git建立一个专门存放配置文件的仓库:

  能够看到,咱们使用的是yml,而在以前的文章中,咱们一直使用的是properties配置文件,springboot中这二者均可以,spring官方更推荐使用yml,所以咱们使用config的时候,会所有替换为yml文件.
  新增一个spring cloud config的服务端module:

  老规矩,先加入父项目:

  而后配置maven依赖:

  咱们的config-server也须要进行安全验证,所以也使用了security,接下来配置文件:

  其中最重要的就是配置了git的地址,告诉config-server,从哪里去读取配置文件.而后启动类新增支持config-server的注解:

  而后启动config-server:

  能够看到,咱们成功访问到了git上的配置文件,另外地址栏中的URL遵循以下规则:

  其中,application指的是配置文件的文件名,profile是配置文件的激活的版本,label是git的分支版本,默认为master.

  接下来,咱们改造eureka-server,从git上读取配置文件.首先须要上传相应的配置文件:




  能够看到test和product的主要区别是端口号和应用名以及验证信息不一样,稍后咱们会验证一下,接下来,咱们复制一份[dhp-micro-eureka-server]到新的module[dhp-micro-eureka-server-config],用于从git读取并加载配置:

  能够看出,咱们删除了以前的配置文件,转而使用了bootstrap.yml文件,有的同窗会问,bootstrap.yml是什么文件?这是springboot的约定,咱们说springboot是约定大于配置,springboot约定系统级相关的配置放到bootstrap.yml中,而application.yml进行应用级的配置,咱们来看看bootstrap.yml的内容:

  主要就是设置配置文件的获取地址,以及获取的文件名以及profile/label(分支名)/帐号密码等信息,配置后启动能够看到:

  能够看到,控制台打印的第一句就是告诉咱们从localhost:7101获取配置,启动成功后启动producer服务看一下:

  能够看到,咱们的producer服务已经注册到eureka-server了,说明咱们的config已经生效了,同理咱们也能够替换consumer/user/producer服务的配置文件为git配置文件,这里咱们就不一一演示了,感兴趣的童鞋们能够本身去操做试一下.另外,因为改造后的全部服务都是从config-server获取配置文件,假如config-server挂了,那整个微服务就没法启动了,所以config-server也须要考虑高可用,所以咱们能够把config-server注册到eureka-server中,保证config-server的高可用,注意,这里的eureka-server和producer等业务微服务注册的eureka-server是不一样的,这个eureka-server仅仅只注册config-server一个,这就能保证config-server的高可用了.

  自此,咱们的分布式配置中心config已经成功了,思考一下,目前的config-server是否有什么问题?这就是咱们下一篇文章的内容,下一篇文章,咱们会介绍spring cloud最后一块拼图,spring cloud消息总线,敬请期待!

  本文的GitHub地址:

本文由博客一文多发平台 OpenWrite 发布！