SpringCloud的Consul

最新推荐文章于 2024-07-07 15:55:08 发布

b2105859

最新推荐文章于 2024-07-07 15:55:08 发布

阅读量1.2k

点赞数 30

本文链接：https://blog.csdn.net/b2105859/article/details/136358116

版权

SpringCloud 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本文介绍了如何在Java应用中集成Consul进行服务发现和配置管理，包括依赖管理、配置设置和代码实现。同时，对比了CAP理论中的CA、CP和AP原则，指出Consul遵循CP原则，提供了强一致性与分区容错，但可能牺牲可用性。

摘要由CSDN通过智能技术生成

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