YML

一、分布式配置中心 分布式系统中，往往拥有大量的服务应用，而每个应用程序都需要有对应的配置文件来协助完成服务环境初始化、运行。因此生产了大量的服务配置文件，Spring Cloud Config 可以实现配置文件的统一管理，它支持将配置服务放置在服务端的内存中（即服务端的本地内存），并且它也默认支持 git ，所以我们也可将配置文件放置在 git 仓库，以便于我们的访问和开发。 二、Spring Cloud Config 起步 实现管理配置的方式有多种，例如使用 Eureka 或者 Spring Cloud Config 以及文件系统等，本次采用 Spring Cloud Config + Git 储存库的方式实现。 在本次的 Spring Cloud Config 组件中，总共有三个角色，一是 Config Server，一个是 Config Client，然后就是 Git 远程仓库。 构建配置中心服务端 Config Server 新建一个 Spring Boot 项目 创建 pom.xml 文件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance

长话短说，今天聊一聊使用Gitlab-CI 自动部署到远程服务器。 如果看过《 基于docker-compose的Gitlab CI/CD实践&排坑指南 》这篇文章的朋友，会注意到我是在 Gitlab-Runner服务器上自动部署的站点，本次我们结合 ssh 部署到远程机器(将CI服务器和部署服务器分离，避免资源抢占）。 SSH免密登陆 还是那句： CI/CD实质是将我们手动集成、拷贝部署的方式脚本化 ，远程部署的重要姿势是要求 免密操控 。 受控机器上的某个账户信任 CI机器上gitlab-runner账户。 先执行 su gitlab-runner 切换到 gitlab-runner 账户 在你的CI机器(主控端)上使用 ssh-keygen命令创建公钥，使用 ssh-keygen -t rsa 来创建，程序会问你存放目录，如果不需要修改，直接回车几次即可 将~/.ssh目录下 id_rsa.pub 文件拷贝到受控机器的 ~/.ssh 目录中，然后将文件内容导入到 ~/.ssh/authorized_keys 文件 主控方： scp /home/gitlab-runner/.ssh/id_rsa.pub ****@10.202.42.252:/home/***/.ssh/ 受控方： cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

一、基本介绍 　　Spring Boot提供了两种常用的配置文件，分别是properties文件和yml文件。 application.properties application.yml 　　他们的作用都是修改Spring Boot自动配置的默认值。相对于properties文件而言，yml文件更年轻，也有很多的坑。可谓成也萧何败也萧何，yml通过空格来确定层级关系，使配置文件结构更清晰，但也会因为微不足道的空格而破坏了层级关系。 二、YAML简介 yml是YAML（YAML Ain't Markup Language）语言的文件，以数据为中心，比json、xml等更适合做配置文件 　　以前的配置文件；大多都使用的是 xxxx.xml 文件；yml和xml相比，少了一些结构化的代码，使数据更直接，一目了然。举例: 　　YAML server: port: 8081 　　XML: <server> <port>8081</port> </server> 　　yml和json呢？没有谁好谁坏，合适才是最好的。yml的语法比json优雅，注释更标准，适合做配置文件。json作为一种机器交换格式比yml强，更适合做api调用的数据交换。 2.1 YAML的语法 　　k:(空格)v：表示一对键值对（空格必须有）； 　　以空格的缩进程度来控制层级关系。空格的个数并不重要

spring-boot-plus项目配置文件 配置文件说明 配置说明 项目中配置文件主要使用yml格式 配置文件位置：spring-boot-plus\src\main\resources\config spring boot 配置分为公共配置：application.yml文件 项目中各个环境配置文件 application-dev.yml 开发环境 application-local.yml 本地环境 application-prod.yml 生成环境 application-test.yml 测试环境 application-uat.yml 用户验收测试 根据项目实际情况进行配置 配置文件与maven环境一一对应，对应的pom.xml文件 <!--MAVEN打包选择运行环境--> <!-- 1:local(默认) 本地 2:dev:开发环境 3:test 4:uat 用户验收测试 5.prod:生产环境 --> <profiles> <profile> <id>local</id> <properties> <profileActive>local</profileActive> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile>

放个效果图： 准备项目 首先在MySql控制台输入一下sql语句创建student 数据库和student。 create databse student ; use student ; CREATE TABLE ` student ` ( ` stu_id ` bigint ( 20 ) NOT NULL , ` stu_name ` varchar ( 45 ) DEFAULT NULL , ` stu_sex ` varchar ( 6 ) DEFAULT NULL , ` date ` varchar ( 45 ) DEFAULT NULL , ` room ` int ( 2 ) DEFAULT NULL , ` acadimy ` varchar ( 45 ) DEFAULT NULL , PRIMARY KEY ( ` stu_id ` ) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci ; SpringBoot 修改项目名称，点击next 这里直接点next 第一次打开会很慢 打开后删除用不到的文件 连接MySql 修改 application.properties 为 application.yml 插入一下代码 要修改的内容： url: jdbc:mysql:/

1，新建springboot工程时选中mysql和liquibase，这样就不用在pom中添加dependence了 2，项目目录结构 3.pom文件依赖，依赖 spring-boot-starter-jdbc 目的是为了让 liquibase 能够获得 datasource 连接数据库，这里换成 mybatis效果一样，只是需要再配置一些文件 4.配置master.xml，做个简单实例，把changeset直接写在了master.xml中， 5.配置application.yml，里面有datasource的配置，以及liquibase的配置，enabled：true开启liquibae，默认开启，change-log就是加载luiquibase的配置文件的路径（很重要） 6.建数据库db_liquibase02,此时里面还没有表 7.执行项目 8.去数据库刷新一下，你会发现有表了 来源： oschina 链接： https://my.oschina.net/u/4268487/blog/3919882

目录 liquibase是什么 liquibase的特性 liquibase与SpringBoot整合 1.pom文件 2.application.yaml文件 3.目录 官网 liquibase是什么 liquibase是一个用于跟踪，管理和应用数据库变化的开源的数据库重构工具。它将所有数据库的变化（包括结构和数据）都保存在XML文件中，便于版本控制。 说白了就是一个将你的数据库脚本转化为xml格式保存起来，包括你对数据库的修改，以及数据的版本信息，方便数据的升级和回滚等操作。 liquibase的特性 不依赖于特定的数据库，目前支持包括Oracle/SqlServer/DB2/MySql/Sybase/PostgreSQL/Cache 等12种数据库，这样在数据库的部署和升级环节可帮助应用系统支持多数据库。 提供数据库比较功能，比较结果保存在XML中，基于该XML你可用Liquibase轻松部署或升级数据库。 以XML存储数据库变化，其中以作者和ID唯一标识一个变化(changset)，支持数据库变化的合并，因此支持多开发人员同时合作。 在数据库中保存数据库修改历史(DatebaseChangeHistory)，在数据库升级时自动跳过以应用的变化(ChangSet)。 提供变化应用的回滚功能，可按时间，数量或标签(tag)回滚已应用的变化。通过这种方式

实体类： public class ResumeDetailVO { @ApiModelProperty ( "用户信息" ) private UserInfo userInfo ; //一对一，使用association @ApiModelProperty ( "工作经验" ) List < Experience > experiences ; //一对多，使用collection } 对应的resultMap ： < resultMap id = " ResumeDetailMap " type = " ResumeDetailVO " > < association property = " userInfo " javaType = " UserInfoVO " > < result column = " name " property = " name " > </ result > < result column = " phone " property = " phone " > </ result > < result column = " email " property = " email " > </ result > < result column = " identity_card " property = " identityCard " > </

在Spring Cloud Netflix中使用Eureak作为注册中心，但是Eureka2.0停止更新，Eureka1.0 进入了维护状态。就像win7一样，同样可以用，但是官方对于新出现的问题并不能及时修复，所以我们就需要使用替代品。目前可用的注册中心替代品主要有：Zookeeper、Consul、Nacos等，这里主要讲前两个，Nacos是Spring Cloud Alilibaba中的组件，后期会说到。 使用Zookeeper作为注册中心 一、安装Zookeeper并启动服务 ​ 这一步非本文重点，请自行百度，很简单的 二、将原有的微服务注册进Zookeeper 使用过Dubbo的小伙伴对Zookeeper一定不陌生。使用Eureka时，我们是创建一个新的SpringBoot Web项目（如果是Eureka集群的话，就要创建多个项目），然后将其他微服务注册进去，而Zookeeper却不用新建项目，只需要通过修改配置和简单的编码就可以进行注册 为了和之前的项目冲突，我们先将之前的项目复制两个新的项目 zookeeper-provider-8001 和 zookeeper-consumer-80 先修改 zookeeper-provider-8001 这个提供者项目 在pom.xml中引入依赖 <dependency> <groupId>org.springframework

转载自: https://blog.csdn.net/hxpjava1/article/details/78514999 简介 gitlab-ci全称是gitlab continuous integration的意思，也就是持续集成。中心思想是当每一次push到gitlab的时候，都会触发一次脚本执行，然后脚本的内容包括了测试，编译，部署等一系列自定义的内容。本文就是利用gitlab-ci的持续集成来实现自动部署。相比之前 webhook的自动部署 还是强大以及方便了许多。 原理 自动部署涉及了若干个角色，主要介绍如下 GitLab-CI 这个是一套配合GitLab使用的持续集成系统，是GitLab自带的，也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。 GitLab-Runner 这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件之后，根据里面的规则，分配到各个Runner来运行相应的脚本script。这些脚本有的是测试项目用的，有的是部署用的。 GitLab-CI与GitLab-Runner关系示意图 .gitlab-ci.yml 这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则