0.介绍
Console是一款服务发现、健康检查、分布式配置中心，有单独的web可供配置和查看的Spring家族的一员。
1.下载
https://developer.hashicorp.com/consul/install?product_intent=consul
2.启动
consul agent-dev
访问localhost:8500
3 Java使用注册中心
3.1 pom
<!--SpringCloud consul config-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-config</artifactId>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
<!--SpringCloud consul discovery -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
3.2 yml
spring:
application:
name: cloud-payment-service
####Spring Cloud Consul for Service Discovery
cloud:
consul:
host: localhost
port: 8500
#服务注册发现
discovery:
service-name: ${spring.application.name}
#分布式配置中心
config:
profile-separator: '-' # default value is ","，we update '-'
format: YAML
3.3 启动类
@EnableDiscoveryClient
注意：如果使用RestTemplate得在@Bean的后面加入@LoadBalanced
4.分布式配置中心
4.1 沿用3.1、3.2、3.2的步骤
打开访问localhost:8500Key/Value菜单，新建config/,再建微服务名-dev/，再建data，输入
lili:
name: lili
4.2使用
@Value("${lili.name}")
private String name;
@GetMapping(value = "/test")
private String getInfoByConsul()
{
return name;
}
4.3 动态刷新
主启动类添加@RefreshScope
4.4 配置持久化
新建start_consul.bat，内容如下，用管理员启动
@echo.服务启动......
@echo off
@sc create Consul binpath= "D:\dev\consul_1.17.0_windows_386\consul.exe agent -server -ui -bind=127.0.0.1 -client=0.0.0.0 -bootstrap-expect 1 -data-dir D:\dev\consul_1.17.0_windows_386\mydata "
@net start Consul
@sc config Consul start= AUTO
@echo.Consul start is OK......success
@pause
补充知识点CAP
C：Consistency（强一致性）
A：Availability（可用性）
P：Partition Tolerance（分区容错性）
最多只能同时较好的满足两个。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
AP典型代表：Eureka
当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。
当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性结论：违背了一致性C的要求，只满足可用性和分区容错，即AP
CP典型代表：Zookeeper/Consul
当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性，Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。结论：违背了可用性A的要求，只满足一致性和分区容错，即CP
