服务注册：

配置管理：

注册中心的比较：

在微服务的世界中，服务注册是必不可少的。现在比较流行的也就是Consul和Nacos，Zookeeper没有管理界面，一般不建议使用，而Eureka已经处于停更，并且本身就存在很多bug，一般不建议使用！

我之前写过一篇spring boot整合nacos实现服务注册和配置管理：

springboot3整合nacos实现注册中心和配置中心（详细入门）_springboot3 nacos-CSDN博客

现在，就在介绍以下使用consul实现服务注册和配配管理。

先简单介绍一下Consul：

Consul 是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案相比，Consul的方案更“一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其它工具(比如ZooKeeper等) ，使用起来也较为简单。

Consul 使用Go语言编写，因此具有天然可移植性(支持Linux,Windows和Mac OS);安装包仅包含一个可执行文件,方便部署，与Docker等轻量级容器可无缝配合。
Consul 官网介绍：

Consul Documentation | Consul | HashiCorp Developer
Consul 中文教程：

Spring Cloud中文网-官方文档中文版

Spring Cloud中文网-官方文档中文版
SpringCloud官网介绍Consul：

Spring Cloud Consul

Consul的搭建：

官网：https://www.consul.io/downloadshttps://www.consul.io/downloads

Consul在windows下和linux下是都可以安装的，并且基本上不用配置就能使用！

在windows下的话下载好后就是一个可执行的exe，我们可以通过命令来查看consul是否下载成功；

consul --version
 

如果有相应的版本输出信息，表明配置完成；（我的consul的版本为v1.17.0）

接下来启动Consul服务：

consul agent -dev

consul的默认端口为8500，在自己的电脑上可以查看启动的consul服务；

新建微服务项目，并导入相应的依赖；

服务注册：

创建一个maven聚合项目，并在这个项目下新建一些模块，用来进行入住consul的测试服务。

引入consul关于服务注册的依赖：（我已经在父工程下引入了spring cloud的依赖2022.0.4）
 

  <dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-consul-discovery</artifactId></dependency>

在yml文件中进行consul的连接配置：
 

spring:application:name: test-democloud:consul:host: localhostport: 8500discovery:service-name: ${spring.application.name}prefer-ip-address: true

启动这个服务，就可以在consul的控制台中看到test-demo入驻到consul了。

在刚入住consul时，consul会去发心跳包，所以会出现红色的x号，可以稍等一会就可以消除了。

配置管理：

添加consul关于配置管理的依赖：
 

  <dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-consul-config</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bootstrap</artifactId></dependency>

在resources目录下新建一个bootstrap.yml文件：

applicaiton.yml是用户级的资源配置项

bootstrap.yml是系统级的，优先级更加高

Spring Cloud会创建一个“Bootstrap Context”，作为Spring应用的`Application Context`的父上下文。初始化的时候，`Bootstrap Context`负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的`Environment`。

`Bootstrap`属性有高优先级，默认情况下，它们不会被本地配置覆盖。 `Bootstrap context`和`Application Context`有着不同的约定，所以新增了一个`bootstrap.yml`文件，保证`Bootstrap Context`和`Application Context`配置的分离。

 application.yml文件改为bootstrap.yml,这是很关键的或者两者共存

因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml

因此，如果某些配置项需要在应用程序启动之前加载并生效，应该将它们放在 bootstrap.yml 中。而对于应用程序级别的配置，则可以放在 application.yml 中。

bootstrap.yml中的内容为：
 

spring:application:name: test-democloud:consul:host: localhostport: 8500discovery:service-name: ${spring.application.name}prefer-ip-address: trueconfig:profile-separator: '-' #默认的分隔符为  ","  我们自定义为"-"format: yaml  #文件格式为yml

接下来在consul的控制台创建相应的配置文件，并在项目中进行读取。

先创建一个config文件夹，在config文件夹下再创建一个test-demo文件夹（注意这个文件夹的名称应与模块的项目名称保持一致），在test-demo文件夹下新建一个data文件，文件格式为yml类型，在这个data文件中编写我们信息；

在项目中进行测试：

@GetMapping("/file")
public String file(@Value("${student.name}") String name){return "配置文件中的数据==>"+name;
}

访问相应的接口：

可以看到能正确的访问到我们编写的信息；

注册中心的比较：

最多只能同时较好的满足两个。

 CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。

AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

目录

---