服务注册：
配置管理：
注册中心的比较：
在微服务的世界中，服务注册是必不可少的。现在比较流行的也就是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/downloads
https://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-demo
cloud:
consul:
host: localhost
port: 8500
discovery:
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-demo
cloud:
consul:
host: localhost
port: 8500
discovery:
service-name: ${spring.application.name}
prefer-ip-address: true
config:
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 - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
目录
