微服务架构:动态配置中心搭建

版权声明:本文为博主原创文章,转载请注明出处,欢迎交流学习!

在微服务架构中,服务之间有着错综复杂的依赖关系,每个服务都有自己的依赖配置,在运行期间很多配置会根据访问流量等因素进行调整,传统的配置信息处理方式是将配置信息写入xml、.properties等配置文件中,和应用一起打包,每次修改配置信息,都需要重新进行打包,效率极低,动态配置中心就是为了解决这一问题。动态配置中心也是一个微服务,我们把微服务中需要动态配置的配置文件存放在远程git私有仓库上,微服务会去服务器读取配置信息,当我们在本地修改完代码push到git服务器,git服务器端hooks自动检测是否有配置文件更新,如果有,git服务端通过消息队列给配置中心发消息,通知配置中心刷新配置文件。因此微服务读取到的就是最新的配置信息,实现了运行期动态配置。理解了配置中心的原理,下面来介绍应用Spring Cloud框架的configserver搭建动态配置中心的整个过程。

1、Git私有仓库搭建

       由于所有配置文件放在Git远程私有仓库上,我们需要搭建Git私有仓库。

1)安装git

# cd /etc/yum.repos.d/

# wget http://geekery.altervista.org/geekery-el5-x86_64.repo

# cd /data/soft/

# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

# rpm -ivh rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

# yum -y install git

# git --version

2)搭建git仓库

a、创建一个git用户,用来运行git服务

命令:$ sudo adduser git

b、创建证书登录

收集所有需要登录的用户的公钥,就是他们自己的id_rsa.pub文件,把所有公钥加入到/home/git/.ssh/authorized_keys文件里,一行一个。

c、初始化git仓库

选定或创建一个目录作为Git仓库,如:/home/git/microservice.git,将此目录初始化为git仓库

命令:$ sudo git init --bare microservice.git

$ sudo chown -R git:git microservice.git

d、克隆远程仓库

命令:$ git clone [email protected]:microservice.git

3)在本地安装git客户端

以上操作完成Git服务端私有仓库搭建后,需要在本地安装Git客户端,并且把公钥加入到服务端的/.ssh/authorized_keys配置文件中,这样就可以在本地克隆服务端代码并向服务端进行推送了。本地Git客户端的安装可参照Git教程。

2、安装消息队列

       在远程机器上安装消息队列(rabbitmq)并启动。

3、配置中心相关配置文件

       配置中心(配置服务,例如:sample-config)的配置文件application.yml,添加如下配置:

1)configserver的git配置

configserver根据配置的Git服务器地址,去服务器上读取相应的配置文件信息。

uri: 用户名、远程Git服务器地址、私有仓库地址

username: Git服务器用户名(搭建仓库时创建的用户)

password: 用户密码

2)消息队列配置

当Git服务端检测到配置文件有更新时,会通过消息队列通知configserver刷新配置文件。

rabbitmq配置:

host: 消息队列的地址

port: 消息队列端口

username: 用户名

password: 密码 

       3)Dockerfile配置

由于采用ssh协议访问Git服务器时,需要手动输入确认连接信息,因此在这里我们需要屏蔽此检查。我们需要新建一个配置文件config(无后缀名)跟Dockerfile一起放在容器中,并在Dockerfile中进行配置(新建/.ssh目录,将config文件添加到此目录下)。

部署在容器中的文件:

config文件配置:

Dockerfile配置:

4、在服务中添加消息总线依赖配置

       在需要将配置文件放到配置中心进行动态配置的服务中,添加消息总线的配置。

在服务的pom.xml文件中添加依赖:

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-bus-amqp</artifactId>

</dependency>

5、在Git服务端编写服务端hook

       当本地Git客户端向服务端仓库推送更新时,Git服务端需要检测配置文件是否有更新,如果有,则需要向configserver发请求通知它刷新配置文件。这就需要用到服务端hook。在Git服务端的/.git/hooks/目录下,创建post-receive文件(无后缀名),并添加相应的脚本,当Git客户端推送更新,服务端更新完文件后会自动执行此post-receive文件脚本。

6、在本地Git客户端提交修改并推送到Git服务端

在本地更新配置文件后,提交到本地Git仓库,然后将本地更新push到Git服务端。

相关Git命令:

$ git add xxx.xml xx.yml -------将修改的配置文件xxx.xml、xx.yml添加到暂存区

$ git commit -m “xxxxxx”-----将暂存区文件提交到本地Git仓库

$ git push origin master ------将本地更新推送到服务端

以上就是利用configserver实现动态配置中心的整个过程,整个配置完成后就可以在本地修改配置文件push到Git服务器,我们的微服务就可以动态读取到最新的配置了。

时间: 2024-10-24 03:09:39

微服务架构:动态配置中心搭建的相关文章

Spring Cloud构建微服务架构分布式配置中心

Spring Cloud Config是Spring Cloud团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分.其中服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息.加密/解密信息等访问接口:而客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定的配置中心来管理应用资源与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息.Spring Cloud Conf

Spring Cloud构建微服务架构 分布式配置中心(加密解密)

在微服务架构中,我们通常都会采用DevOps的组织方式来降低因团队间沟通造成的巨大成本,以加速微服务应用的交付能力.这就使得原本由运维团队控制的线上信息将交由微服务所属组织的成员自行维护,其中将会包括大量的敏感信息,比如:数据库的账户与密码等.很显然,如果我们直接将敏感信息以明文的方式存储于微服务应用的配置文件中是非常危险的.针对这个问题,Spring Cloud Config提供了对属性进行加密解密的功能,以保护配置文件中的信息安全.比如下面的例子: spring.datasource.use

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段

微服务架构中主流的配置中心对比分析?

为什么需要配置中心 配置实时生效: 传统的静态配置方式要想修改某个配置只能修改之后重新发布应用,要实现动态性,可以选择使用数据库,通过定时轮询访问数据库来感知配置的变化.轮询频率低感知配置变化的延时就长,轮询频率高,感知配置变化的延时就短,但比较损耗性能,需要在实时性和性能之间做折中.配置中心专门针对这个业务场景,兼顾实时性和一致性来管理动态配置. 配置管理流程: 配置的权限管控.灰度发布.版本管理.格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分. 开源配置中心基本介

基于docker部署的微服务架构(四): 配置中心

原文:http://www.jianshu.com/p/b17d65934b58%20 前言 在微服务架构中,由于服务数量众多,如果使用传统的配置文件管理方式,配置文件分散在各个项目中,不易于集中管理和维护.在 spring cloud 中使用 config-server 集中管理配置文件,可以使用 git.svn.本地资源目录 来管理配置文件,在集成了 spring cloud bus 之后还可以通过一条 post 请求,让所有连接到消息总线的服务,重新从config-server 拉取配置文

微服务架构之「 配置中心 」

在微服务架构的系列文章中,前面已经通过文章<微服务架构之「服务网关 」>介绍过了在微服务中服务网关的原理和应用,今天这篇文章我们继续来聊一聊微服务中另外一个重要模块:「 配置中心 」.后面还会继续介绍 服务框架.服务监控.服务治理等.还是那句话,只有将这些基础设施弄清楚了,微服务实践的道路才能走的稳.走的远. 「配置中心」,顾名思义,就是用来统一管理项目中所有配置的系统.虽然听起来很简单,但也不要小瞧了这个模块.如果一个中型互联网项目,不采用配置中心的模式,一大堆的各类配置项,各种不定时的修改

构建微服务架构Spring Cloud:分布式配置中心

Spring Cloud Config是Spring Cloud团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分.其中服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息.加密/解密信息等访问接口:而客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定的配置中心来管理应用资源与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息.Spring Cloud Conf

Spring Cloud构建微服务架构(四)分布式配置中心

Spring Cloud Config为服务端和客户端提供了分布式系统的外部化配置支持.配置服务器为各应用的所有环境提供了一个中心化的外部配置.它实现了对服务端和客户端对Spring Environment和PropertySource抽象的映射,所以它除了适用于Spring构建的应用程序,也可以在任何其他语言运行的应用程序中使用.作为一个应用可以通过部署管道来进行测试或者投入生产,我们可以分别为这些环境创建配置,并且在需要迁移环境的时候获取对应环境的配置来运行. 配置服务器默认采用git来存储

微服务架构:Eureka集群搭建

版权声明:本文为博主原创文章,转载请注明出处,欢迎交流学习! 服务注册.发现是微服务架构的关键原理之一,由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构,服务之间通过轻量机制进行通信,这就必然引入一个服务注册发现的问题,也就是说服务提供方要注册报告服务地址,服务调用方要能发现目标服务.在我们的微服务架构中我们采用了Eureka来完成微服务的注册与发现.微服务通过Eureka进行注册,服务调用方通过Eureka找到目标服务.由于服务提供方以集群方式提供服务,Eureka也采用集群的方式来