转载请注明出处:https://blog.csdn.net/weixin_41133233/article/details/85070323
本文出自 程熙cjp 的博客
继上一篇搭建简单的单个eureka服务之后,本篇小熙将详细讲解eureka和如何搭建高可用的集群
一. 添加Dashboard模板
添加Dashboard运行模板是为了以后更好的搭建集群。(如果打开项目时右下角有提示:show Dashboard。点击即可,如果没有则按照如下配置)
1. 第一种查找Dashboard模板方法
view > Tool Windows > Run Dashboard
2. 第二种查找Dashboard模板方法
(1). 首先找到.idea,在项目名称的下面首先找到.idea,在项目名称的下面
(2). 在workspace.xml配置如下
复制代码:
<component name="RunDashboard">
<option name="configurationTypes">
<set>
<option value="SpringBootApplicationConfigurationType" />
</set>
</option>
<option name="ruleStates">
<list>
<RuleState>
<option name="name" value="ConfigurationTypeDashboardGroupingRule" />
</RuleState>
<RuleState>
<option name="name" value="StatusDashboardGroupingRule" />
</RuleState>
</list>
</option>
</component>
- Dashboard模板如图所示:
二. 修改yml文件,配置集群
1. 修改yml文件
我习惯的是写多个,用到哪一个打开哪一个,其他的注释。
这里推荐其他人的yml配置,个人习惯不同,因人而异吧。
我的yml文件是:
server:
# 注意这里的eureka注册是个模板,在搭建集群的时候会被多次复制,其中Eureka01的端口号是:8091,Eureka02的端口号是8092。注意修改
port: 8090
# port: 8091
# port: 8092
spring:
application:
# 应用名称,会在Eureka中显示
name: eureka-server
eureka:
client:
# 是否注册自己的信息到EurekaServer,默认是true。搭建集群的时候需要互相注册,提高项目的高可用性。在用Dashboard模板时,重新修改配置文件部署在Tomcat相当于把原来的复制了一份
register-with-eureka: true
# 是否拉取其它服务的信息,默认是true,同上
fetch-registry: true
# EurekaServer的地址,现在是自己的地址,如果是集群,需要加上其它Server的地址。
service-url:
# 注意搭建eureka集群的时候,要相互注册,需要修改此处配置
defaultZone: http://127.0.0.1:8091/eureka,http://127.0.0.1:8092/eureka
# defaultZone: http://127.0.0.1:8090/eureka,http://127.0.0.1:8092/eureka
# defaultZone: http://127.0.0.1:8090/eureka,http://127.0.0.1:8091/eureka
# defaultZone: http://127.0.0.1:${server.port}/eureka
2. 配置集群
由yml配置文件可知,我们是要配置三个euraka集群节点的。所以要创建三个springboot启动索引,如上图按步骤配置
配置结果如图:
运行结果如图
三. 详解Eureka
1. Eureka比Zookeeper好在哪里
著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。
2. Zookeeper保证CP
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。
3. Eureka保证AP
Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
- Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
- 当网络稳定时,当前实例新的注册信息会被同步到其它节点中
因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。
注意Eureka的心跳机制是每30秒,其他服务向注册中心发送一次心跳,如果90秒内没有发送则被保护起来(保护机制),如果15分钟内还没有续约发送心跳则保护机制失效,然后等待每60秒一次的清除机制,清除这个服务的注册。
嗯,至此小熙要讲述的Eureka高可用集群和详解就结束了。下章小熙将会介绍ribbon负载均衡之前的准备工作。