接着前面说，我们谈到服务可以注册到Eureka注册中心，通过Ribbon来消费调用我们注册中心注册的服务，那么现在考虑的就是假如注册中心出现故障的时候我们怎么保证我们的服务任然可以继续被发现调用。
一、Eureka高可用集群
那么第一篇springcloud介绍springcloud的框架时候我们说，springcloud的微服务架构也可以说是一个分布式架构，那么所有的分布式架构都满足我们经典的CAP原则。我们说springcloud在这一点上是保证AP，也就是高可用和分区容错性。
因此对于Springcloud的高可用集群的实现就显得尤为的重要了，回顾一下dubbo的zookeeper注册中心的集群。我们说多个子节点是注册到一个master节点下，形成一带多的架构模式。并且当master节点出现故障的时候可以在一定时间内经过服务之间的选举重新产生一个master节点。这个也就是dubbo在保证数据强一致性的情况下的设计思想。
而springcloud的Eureka注册中心在这一点上就不一样了。springcloud的Eureka注册中心集群是没有master节点的，每一个服务注册中心的地位都是相等的。我们搭建集群的时候保证 eureka 服务注册中心它本身也是一个服务，它也可以看做是一个提供者，又可以看做是一个消费者
这样就形成了多组相互注册的服务中心，进而实现服务清单的互相同步，从而达到高可用的效果。
二、Eureka服务注册中心自我保护机制
Eureka自我保护机制其实是优缺点都有的，不能片面的理解，需要从项目的实际场景出发。应该来讲优点是大于缺点的。
1、Eureka自我保护机制的优点
当我们启动项目之后，进入到Eureka注册中心的管理页面，可以看到管理页面上会出现一行红色的警告。这个就是Eureka的自我保护机制。
在没有Eureka自我保护的情况下，或者你不需要这个自我保护机制把它关闭的情况下，如果Eureka Server 在一定时间内没有接受到某个微服务的心跳。Eureka Server 将会注销该实例，但是发生网络故障时，微服务与Eureka server之间将无法正常通信，所以这个时候就很危险了，感觉就像错杀了一个好人一样，那么Eureka自我保护机制其实是让我们的Eureka 集群更加的健壮、稳定。
## 禁用自我保护模式
eureka.server.enable-self-preservation = false
2、Eureka自我保护机制的缺点
那么Eureka假如一直带着这种自我保护机制，我们不能将为了不错杀一个好人，就放着坏人也置之不理吧。如果在保护期间某个微服务刚好非正常下线了，此时服务消费者就会拿到一个无效的服务实例，此时就会发生调用失败的情况，对于这个问题springcloud也是给我们提供了一下解决方案，后面会有负载均衡的重试机制、hystrix的服务熔断啊。