前言
我们在上篇讲到,使用Ribbon负载均衡客户端,实现对Provider
集群的访问。微服务注册在Eureka中,访问服务通过,微服务在Eureka中的ID。先在有一个问题,如果我们这个Eureka服务挂掉了,那么整个微服务是不是都会瘫痪呢。那么我们必须保证Eureka服务系统的高可用,为了达到这一目的,我们可以通过搭建Eureka集群来实现。
什么是集群:不同的服务器上运行一个相同的服务,而这些服务器群体,对外作一个超大运算的整体。
作用:高可用,其中一台机器宕机,还是集群的其他机器还能提供相同的服务。
一、Eureka-server集群搭建
工程搭建:
microservice_eureka_7002
microservice_eureka_7003
搭建过程过程同microservice_eureka_7001
模块。模块创建完成之后,在本机hosts
配置地址映射
//之前eureka7001也配置了
127.0.0.1 eureka7002
127.0.0.1 eureka7003
创建好了三个eureka-server之后。我们要考虑的问题是,如何让他们3个之间捆绑在一起,形成一个整体。我们可以想象A B C ,三个人,手牵手围成一个圈。
A 牵着 B和C
B牵着 A和B
C牵着 A和B
那么这样,他们三个是不是就捆绑在一起了呢。Eureka,也可以效仿这种模式。在每一个Eureka-server中都注册指向两个Eureka-server.
配置如下:
microservice_eureka_7001
的配置
server:
port: 7001 #服务端口名称
eureka:
instance:
hostname: eureka7001
client:
fetch-registry: false # 不用检索服务 自己是注册中心
register-with-eureka: false #不向注册中心注册自己
service-url:
defaultZone: http://eureka7002:7002/eureka,http://eureka7003:7003/eureka
microservice_eureka_7002
的配置
server:
port: 7002 #服务端口名称
eureka:
instance:
hostname: eureka7002
client:
fetch-registry: false # 不用检索服务 自己是注册中心
register-with-eureka: false #不向注册中心注册自己
service-url:
#集群版本 配置7001 7003eureka服务的地址信息
defaultZone: http://eureka7001:7001/eureka,http://eureka7003:7003/eureka
microservice_eureka_7003
的配置
server:
port: 7003 #服务端口名称
eureka:
instance:
hostname: eureka7003
client:
fetch-registry: false # 不用检索服务 自己是注册中心
register-with-eureka: false #不向注册中心注册自己
service-url:
defaultZone: http://eureka7001:7001/eureka,http://eureka7002:7002/eureka
二、测试
启动我们配置好集群关系的3个Eureka
服务,启动过程过程可能会有点慢,等待启动成功之后,随便访问其中一个eureka服务
http://eureka7001:7001/
到此处,这三个Eureka-server,注册中心也就关联起来了。
三、修改服务的注册地址
因为我的Eureka地址已经由原来的一个,变成三个,所以,我们注册的服务的时候,应该向Eureka集群服务注册。将三个服务的提供者provider
的配置文件里的defaultZone
修改如下:
eureka: #设置eureka注册服务的地址
client:
service-url:
defaultZone: http://eureka7001:7001/eureka,http://eureka7003:7003/eureka,http://eureka7002:7002/eureka
四、修改服务的发现地址
同样需要修改microservice_product_consumer80
发现服务的Eureka地址,也就是加上另外两个注册中心的地址,
eureka:
client:
service-url:
#eureka发现服务的列表
defaultZone: http://eureka7001:7001/eureka,http://eureka7003:7003/eureka,http://eureka7002:7002/eureka
五、测试
这样三个Eureka注册中心,就可以达到高可用状态,其中某个Eureka因为延迟,或者网络故障,并不会使得整个微服务瘫痪,一个不行了,还有两个帮忙。
启动三个服务的提供者8001
8002
8003
和服务的消费者microservice_product_consumer80
。进入Eureka后台。
服务已经正常注册了,当我们访问http://localhost/consumer/product/list
时。也能得到我们的数据,我们开始尝试关掉某一个Eureka注册中心,看看请求是不是还能正常发送。再次发送请求http://localhost/consumer/product/list
,也是能够正常访问的,也就说明,整个微服务还是能够正常运转的,Eureka高可用,就的目的也就达到啦。
六、Eureka相对于Zookeeper的优势
Zookeeper遵守CP(一致性,分区容错性),但是不能保证高可用,因为当zookeeper集群某一台机器不可用之后,剩余节点会重新选举leader,但是leader选举的时候过长,会导致在选举这段时候30-120s期间,zookeeper集群是瘫痪的状态。
Eureka遵守AP(高可用,分区容错性),Eureka各个节点都是平等的,几个节点挂点,不会影响的剩余的节点提供服务。只要有Eureak服务还在工作,当Eureka-client向某个eureka节点注册或查询服务时如果发现连接失败,就会自动连接到其他eureka服务器,只不过查询到是数据可能不是最新的(因为eureka无法保证数据的一致性)
在应用启动后,将会向Eureka Server发送心跳,默认周期为30秒,如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。
如果在15分钟内,超过85%节点没哟正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障
自我保护机制:
1、Eureka不会从注册列表中移除长时间没有心跳的服务(好死不如赖活着)。
2、Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他的节点当中。
3、当网络稳定时候,当前新实例的注册信息会被同步到其他节点当中。
我们经常看到的下面这个警告,其实就是自我保护机制的 提示
所以:Eureka能很好的应对因为网络故障和部分节点失去联系的状况,不会像zookeeper一样,需要重新选举leader,然后导致在选举期间,整个注册中心系统都会瘫痪