spring cloud 分布式配置(使用git进行远程配置)

我们使用分布式架构 搭建项目时 就比如说我们更改了数据库的密码

那如果有十几个微服务配置在不同的服务器上 我们是不是得一个一个服务器的去更改

那样就相当的麻烦 不光麻烦 还及其容易错 所以基本是不可能这样实现

这里有一个解决方式 可以把项目的配置放到gitlab上 从gitlab来读取 这样就方便了我们的配置

那么就要登陆到gitlab上创建账号 发布项目 等等 这些东西可以到

https://blog.csdn.net/Adelly/article/details/79099772 这个教程看一下 这里不多说

然后在项目中创建一个配置中心的模块

// https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-config-server
    compile group: ‘org.springframework.cloud‘, name: ‘spring-cloud-config-server‘

添加config-server的依赖 因为它是配置中心服务端 在客户端的话需要添加

// https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-config
    compile group: ‘org.springframework.cloud‘, name: ‘spring-cloud-starter-config‘

接着往下看 配置中心的配置文件

spring:
  application:
    name: config-center //项目名
  cloud:
    config:
      server:
        git:
          uri: https://gitlab.com/wangkeee/poppy-mall.git  //git的地址
          clone-on-start: true //是否在使用配置文件时拷贝到本地
          search-paths: local //读取项目中的那个文件夹
server:
  port: 8887 //端口号

注意 这里的配置文件需要使用bootstrap.yml 而不是之前使用的application.yml

他们基本上是一样的 但bootstrap.yml的执行要比application.yml优先

想一下 在读取项目时 配置文件当然是需要优先读取的 在本地的话倒还好 这里把配置文件放到git上 读取缓慢 所以需要优先读取

然后看一下git项目的搭建

在文件夹中创建微服务的配置文件 并且把微服务的配置文件的内容拷贝进去

文件的命名是配置文件中

spring:
  application:
    name:

的值.yml

然后就可以把对应微服务的配置文件删除 也加上一个bootstrap.yml

看一下里面的配置

spring:
  application:
    name: project-poppy-mall //项目名
  cloud:
    config:
      uri: http://localhost:8887 //配置中心的地址

在配置中心的启动类上 加上

@SpringBootApplication //启动项目
@EnableConfigServer //代表它是一个配置中心

然后就可以运行配置中心 就可以运行成功了

然后就可以照常运行删除了配置文件的微服务了 如果想对微服务的配置文件更改只需要登陆gitlab上进行更改就行了 非常方便

原文地址:https://www.cnblogs.com/wangkee/p/9331033.html

时间: 2024-11-02 04:15:47

spring cloud 分布式配置(使用git进行远程配置)的相关文章

漫谈spring cloud分布式服务架构

详情请交流  QQ  709639943 01.漫谈spring cloud 与 spring boot 基础架构 02.漫谈spring cloud分布式服务架构 03.Node.js入门到企业Web开发中的应用 04.精通高级RxJava 2响应式编程思想 05.Java秒杀系统方案优化 高性能高并发实战 06.Java深入微服务原理改造房产销售平台 07.快速上手Linux 玩转典型应用 08.快速上手Ionic3 多平台开发企业级问答社区 09.Java Spring Security开

spring cloud 分布式链路跟踪(集成zipkin)

篇写了分布式链路追踪  spring cloud 分布式链路追踪 这样的链路追踪虽然可以解决问题 但日志太过于分散 如果微服务过多 就会变的相当复杂 zipkin就可以帮我们把链路调用的过程全部收集起来 它就像注册中心一样 分为客户端和服务端 想要使用 首先建一个模块 当作他的服务端 首先添加如下依赖 compile 'io.zipkin.java:zipkin-server' compile 'io.zipkin.java:zipkin-autoconfigure-ui' 在配置文件中配置它的

spring cloud分布式日志链路跟踪

首先要明白一点,为什么要使用链路跟踪? 当我们微服务之间调用的时候可能会出错,但是我们不知道是哪个服务的问题,这时候就可以通过日志链路跟踪发现哪个服务出错. 它还有一个好处:当我们在企业中,可能每个人都负责一个服务,我们可以通过日志来检查自己所负责的服务不会出错,当调用其它服务时,这时候出现错误,那么就可以判定出不是自己的服务出错,从而也可以发现责任不是自己的. 基于微服务之间的调用开始,如果看不懂的小伙伴,请先参考我上篇:spring cloud中微服务之间的调用以及eureka的自我保护机制

Spring Cloud 分布式事务管理

Spring Cloud 分布式事务管理 在微服务如火如荼的情况下,越来越多的项目开始尝试改造成微服务架构,微服务即带来了项目开发的方便性,又提高了运维难度以及网络不可靠的概率. Spring Cloud 分布式事务管理 单体式架构 微服务架构 优点: 缺点: 分布式事务的引入 分布式事务解决方案 基于XA协议的两阶段提交 消息事务+最终一致性 TCC编程模式 具体实现 LCN ByteTCC 在说微服务的优缺点时,有对比才会更加明显,首先说一下单体式结构 单体式架构 在单体式架构中,系统通常采

spring cloud分布式使用日志链路跟踪

首先要明白一点,为什么要使用链路跟踪? 当我们微服务之间调用的时候可能会出错,但是我们不知道是哪个服务的问题,这时候就可以通过日志链路跟踪发现哪个服务出错. 它还有一个好处:当我们在企业中,可能每个人都负责一个服务,我们可以通过日志来检查自己所负责的服务不会出错,当调用其它服务时,这时候出现错误,那么就可以判定出不是自己的服务出错,从而也可以发现责任不是自己的. 基于微服务之间的调用开始,如果看不懂的小伙伴,请先参考我上篇博客:spring cloud中微服务之间的调用以及eureka的自我保护

Spring Cloud 分布式链路跟踪 Sleuth + Zipkin + Elasticsear

随着业务越来越复杂,系统也随之进行各种拆分,特别是随着微服务架构的兴起,看似一个简单的应用,后台可能很多服务在支撑:一个请求可能需要多个服务的调用:当请求迟缓或不可用时,无法得知是哪个微服务引起的,这时就需要解决如何快速定位服务故障点,Zipkin 分布式跟踪系统就能很好的解决这样的问题. 那么到底怎么使用呢?接下来完成一个具体的实例来体会一把微服务链路追踪: 本文使用的 Spring Cloud Finchley 版本,和其他版本会有不同 我们使用user-service,order-serv

跟我学Spring Cloud(Finchley版)-17-Zuul路由配置详解

上一节( 跟我学Spring Cloud(Finchley版)-16-Zuul )中,已经实现用Zuul转发到Eureka上的微服务.默认的路由规则是:访问$ZUUL_URL/指定为服务/** 会被转发到指定微服务 的/** . 但在实际项目中,往往需要自己定义路由规则,Zuul的路由配置非常灵活.简单,本节详细讲解Zuul的路由配置. 一.自定义指定微服务的访问路径 配置zuul.routes.指定微服务的serviceId = 指定路径 即可.例如: zuul: routes: micros

使用Spring Cloud Feign作为HTTP客户端调用远程HTTP服务

如果你的项目使用了SpringCloud微服务技术,那么你就可以使用Feign来作为http客户端来调用远程的http服务.当然,如果你不想使用Feign作为http客户端,也可以使用比如JDK原生的URLConnection.Apache的Http Client.Netty的异步HTTP Client或者Spring的RestTemplate. 那么,为什么我们要使用Feign呢? 首先我们的项目使用了SpringCloud技术,而Feign可以和SpringCloud技术无缝整合.并且,你一

为什么我选择了 SPRING CLOUD 分布式 微服务

常见的架构单体架构单体架构在小微企业比较常见,一个应用.一个数据库.一个web容器就可以跑起来.在两种情况下可能会选择单体架构:一.在企业发展的初期,为了保证快速上线,采用此种方案较为简单灵活:二.传统企业中垂直度较高,访问压力较小的业务.在这种模式下对技术要求较低,方便各层次开发人员接手,也能满足客户需求.?单体架构的架构图: 在单体架构中,技术选型非常灵活,优先满足快速上线的要求,也便于快速跟进市场.?垂直架构在单体架构发展一段时间后,公司的业务模式得到了认可,交易量也慢慢的大起来.这时候为