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

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

什么是分布式配置中心?

  所谓配置中心,就是将配置的数据放在某种存储介质中,该介质可以是文件/数据库/中间件等等,像业界常用的zookeeper/Apollo/阿里开源的Nacos等等,阿里内部使用的config serverhttps://img.qb5200.com/download-x/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 发布！