SpringCloud中Eureka配置详解与基本概念_springcloud eureka配置详解

Eureka

1. 服务发现与注册

• 只需要使用服务的标识符,就可以访问服务(不再需要修改配置文件)

2. 基本架构

• 采用CS架构.Eureka Server作为服务注册功能的服务器,他是服务注册中心
• 使用客户端连接到Eureka Server并维持心跳

3. pom

<!--eureka-Server服务端-->
<dependency>
	<groupId>orgg.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-eureka-server</artifactId>
<dependency>
1
2
3
4
5

4. 相关配置

//在启动类上标明启用这个新组件
//启用EurekaServer
@EnableEurekaServer

//application配置文件
eureka:
	instance:
		hostname: localhost			#eureka服务端名称
	clinent:
		register: false				#表示不想注册中心注册自己
		fetch_registry: false		#表示自己就是注册中心,职责是维护服务实例,并不需要去检索服务
		service-url:
			defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
								#设置EurekaServer交互地址查询服务和注册服务
1
2
3
4
5
6
7
8
9
10
11
12
13
14

5. 将微服务注册进Eureka

1. pom.xml下

    <dependency>
    	<groupId>org.springframework.cloud</groupId>	
    	<artifactId>springcloud-starter-eureka</artifactId>
    </dependency>
    <dependency>
    	<groupId>org.sprnigframework.cloud</groupId>
    	<artifactId>spring-cloud-starter-config</artifactId>
    <dependency>
   1
   2
   3
   4
   5
   6
   7
   8

2. application配置

    eureka:
    	client:
    		service-url:
    			defaultZone: http://localhost:7001/eureka
    						#与EurekaServer defaultZone相同
   1
   2
   3
   4
   5

3. 启动类

    @EnableEurekaClient		//自动注册进Eureka
   1

4. 每个微服务名字来源于

    spring:
    	application:
    		name: microservicecloud-dept	#注册进EurekaServer的微服务名()
   1
   2
   3

6. actuator与注册微服务信息完善

1. 主机/服务名称修改(status)

    //application配置
    eureka:
    	instance:
    		instance-id:microservicecloud-dept8001
   1
   2
   3
   4

2. 访问路径显示IP

    //application配置
    eureka:
    	instance:
    		prefer-ip-address:true		#访问路径可以显示IP地址
   1
   2
   3
   4

3. 微服务info内容详细信息

   pom

    <!--引入actuator,主管监控和信息配置-->
    <dependency>
    	<groupId>org.springframework.boot</groupId>
    	<artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
   1
   2
   3
   4
   5

   父工程pom下

    <build>
    	<finalName>microservicecloud</finalName>
    	<resources>
    		<resource>
    			<directory>src/main/resources</directoty>
    			<filtering>true</filtering>
    		</resource>
    	</resources>
    	<plugins>
    		<plugin>
    			<groupId>org.apache.maven.plugins</groupId>
    			<artifactId>maven-resources-plugin</artifactId>
    			<configuration>
    				<delimiters>
    					<delimiter>$</delimiter>
    				</delimiters>
    			</configuration>
    		</plugin>
    	</plugins>
    </build>
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20

   application配置

    info:
    	app.name:atguigu-microserivercloud
    	company.name: www.atguigu.com
    	build.artifactId:$project.artifactId$
    	build.version:$project.version$
   1
   2
   3
   4
   5

7. Eureka的自我保护

某时刻某一个微服务不可用,eureka不会立刻清理,依旧会对该微服务的信息进行保存

默认情况下,如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳,EurekaServer将会注销该实例(默认90秒).但是当网络分区故障发生时,微服务与EurekaServer之间无法正常通信,以上行为可能变得非常危险了—以为微服务本身其实是健康的,此时被不应爱注销这个微服务.Eureka通过"自我保护模式"来解决这个问题—当EurekaServer节点在短时间内丢失过多的客户端时(可能发生了网络分区故障),那么这个节点就会进入自我保护模式.一旦进入该模式,EurekaServer就会保护服务注册表中的信息,不再删除服务注册表中的数据(也就是不会注销任何微服务).当网络故障恢复后,改EurekaServer节点会自动退出自我保护模式

在自我保护模式中,EurekaServer会保护服务注册表中的信息,不再注销任何服务实例.当他收到的心跳数重新恢复到阀值以上时,该EurekaServer节点就会自动退出自我保护模式.他的设计哲学就是宁可保留错误的服务注册信息,也不盲目注销任何可能健康的服务实例

综上,自我保护模式是一种应对网络异常的安全保护措施.他的架构哲学是宁可同时保留所有微服务,也不会盲目注销任何健康的微服务.使用自我保护模式,可以让Eureka集群更加健壮,稳定

可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式(大多情况下不建议禁用)

8. Discovery服务发现

• 注册进Eureka里面的微服务通过Discovery发现并获取服务信息
• @EnableDiscovery

9. 集群配置

修改application配置中映射

1. 找到C:\Windows\System32\drivers\ect路径下host文件.

    修改映射配置添加进hosts文件
    127.0.0.1 eureka7001.com
    127.0.0.1 eureka7002.com
    127.0.0.1 eureka7003.com
   1
   2
   3
   4

2. 修改application中eureka-instance-hostname改为在host中配置的映射名

3. 修改application中eureka-client-service-url-defaultZone改为集群的所有服务地址(","号隔开)

4. 每个要注册进eureka的客户端修改application中eureka-client-service-url-defaultZone改为集群的server端所有地址(","号隔开)

10. CAP

RDBMS(mysql/oracle/sqlServer) ACID

A(Atomicity)			原子性
	要么全部做完,要么什么都不做.只要有一个操作失败,整个事务就失败,需要回滚
C(Consistency)			一致性
	也就是说数据库要一直处于一致状态,事务的运行不会改变数据库原本的一致性约束
I(Isolation)			独立性
	所谓独立性食指并发的书屋之间不会互相影响,如果一个事务要访问的数据正在被另一个事务修改,只要另一个事务未提交,他所访问的数据就不受未提交事务的影响
D(Durability)			持久性
	是指一旦事务提交后,他所作的修改将会永久保存在数据库上,即使出现宕机也不会丢失
1
2
3
4
5
6
7
8

NOSQL(redis/mongdb) CAP

C(Consistency)			强一致性
A(Availability)			可用性
P(Partition Tolerance)	分区容错性
1
2
3

CAP的3进2

在目前任何的分布式系统只能满足其中两个

由于当前网络硬件肯定会出现丢包问题,所以P(分区容错性)是我们必须实现的.所以我们只能在C(一致性)和A(可用性)之间权衡(没有NoSQL系统能同时保证这三点)

CAP理论核心

一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,因此,根据CAP原理将NoSQL分成满足CA原则,满足CP原则和满足AP原则这三大类:

• CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大
• CP - 满足一致性,分区容错性的系统,通常性能不是特别高
• AP - 满足可用性,分区容错性的系统,通常可能对一致性要求较低

11. Zookeeper与Eureka

Zookeeper保证的是CP

当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但是不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性要求要高于一致性.但是Zookeeper会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举.问题在于,选举leader的时间太长(30s~120s),且选举期间整个Zookeeper集群都是不可用,这就导致在选举期间注册服务瘫痪.在云部署环境下,因网络问题使得Zookeeper集群失去master节点是较大概率会发生的事,但是漫长的选举时间导致的注册长期不可用是不能容忍的

Eureka保证的是AP

Eureka看明白了这一点,因此在设计时就优先保证可用性.Eureka各个节点都是平等的,**几个节点down掉不会影响正常节点的工作,剩余节点依然可以提供注册和查询服务.而Eureka的客户端在想某个Eureka注册或发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保证注册服务可用(高可用),只不过查到的信息可能不是最新的(不保证强一致性).**除此之外Eureka还有一整自我保护机制,如果在15分钟内超过85%的节点都没有正常心跳,那么Eureka就任务客户端与注册中心出现了网络故障,此时会出现以下几种情况

1. Eureka不再从注册列表中移除以为长时间没受到心跳而过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上(即保证当前节点依然可用)
3. 当网络稳定时,让钱实例新的注册信息会被同步到其他节点中

因此Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像Zookeeper那样使整个注册服务瘫痪.