一、使用方法:
1、添加maven依赖
org.springframework.cloud
spring-cloud-starter-netflix-eureka-server
版本一般交由spring-cloud-dependencies管理。注意这个依赖的artifactId在Edgware以前是spring-cloud-starter-eureka-server，而在之后变成了spring-cloud-starter-netflix-eureka-server。其他组件也是类似。
2、在启动类中加入注解@EnableEurekaServer
@SpringBootApplication
@EnableEurekaServer
public class EurekaCenter {
public static void main(String[] args) {
SpringApplication.run(EurekaCenter.class, args);
}
}
二、属性优化：
1. 关于eureka的配置
大致分为eureka.instance, eureka.clinet,eureka.server三大类。大部分的参数都可以不管，有默认值。需要时查一下就可以了。下面列出几个比较有用的参数
eureka.client.registerWithEureka
表示是否将自己注册到Eureka Server，默认为true。由于当前应用就是Eureka Server，所以不需要注册，修改为false。
eureka.client.fetchRegistry
表示是否从Eureak Server获取注册信息，默认为true。由于示例中是单点的Eureka Server，不需要同步其他的Eureka Server节点的数据，所以修改为false。
eureka.client.serviceUrl.defaultZone
设置与Eureka Server交互的地址，查询服务和注册服务都需要依赖这个地址。
另外，可以给eureka的监控页面增加简单的权限验证security.basic.enabled=true
security.user.name=admin
security.user.password=123
Eureka的其他配置属性可在spring-cloud-netflix-eureka-client的jar包中META-INF目录下寻找spring-configuration-metadata.json文件中有详细描述。这是starter组件的开发流程，其他组件的配置信息也有类似的描述文件。
2. 关于eureka注册中心的自我保护模式
关于自我保护模式，最直观的体现是进入eureka的监控页面时，页面上出现红色的警告信息
默认情况下，Eureka Server在一定时间内没有接收到某个微服务的心跳，Eureka Server就会注销该实例(默认90秒，可以通过参数自行配置)。这本是正常的微服务治理机制，但是如果问题的原因只是因为网络分区故障而发生时，就会出现比较不好的结果。即服务本身其实是健康的，但是Eureka Server却把他注销掉了。
为了防止这种情况，Eureka Server采用了自我保护模式。即当服务失联后，会继续保存该服务的注册信息-不会分配请求。而当网络故障恢复后，该服务就会退出自我保护模式，重新分配请求。
而在SpringCloud中，可以通过配置参数
eureka.server.enable-self-preservation= false
来禁用自我保护模式
另外，对于自我保护模式下的服务，可以通过手动访问接口方式进行管理，即手动下线已经失效的微服务。具体方式可以访问Eureka Server的REST接口，例如下线服务只需要给如下地址发送DELETE请求(可以用POSTMAN等工具发送)
http://${Eureka_URL}:${Eureka_port}/eureka/apps/${AppName}/${instance}
其中，AppName和{AppName}和AppName和{instance}就是在页面上看到的服务节点。
3. Eureka的高可用配置
Eureka通过多个节点相互注册的方式来实现集群高可用。
为了在单机模拟HA配置方式，可以采用在单机监听两个不同端口的方式启动更多个实例。
使用yml文件配置方式如下：
---
server:
port: 8001
spring:
profiles: server1
application:
name: eureka-ha
eureka:
instance:
hostname: server1
client:
serviceUrl:
defaultZone: http://server2:8002/eureka/
---
server:
port: 8002
spring:
profiles: server2
application:
name: eureka-ha
eureka:
instance:
hostname: server2
client:
serviceUrl:
defaultZone: http://server1:8001/eureka/
然后使用指令启动两个实例：
java -jar ./eurekaCenter-0.0.1-SNAPSHOT.jar --spring.profiles.active=server1
java -jar ./eurekaCenter-0.0.1-SNAPSHOT.jar --spring.profiles.active=server2
启动两个实例后可以访问server1:8001和server2:8002页面，可以看到两个实例完成了相互注册。
4.Eureka跨机房灾备
Eureka通过增加region和zone的定义可以快速时间跨机房灾备(region和zone的概念均来自于亚马逊的AWS)
一般region概念指代区域，如亚洲地区、华北地区、北京等。而zone概念指代具体机房。
灾备原则是一个机房内的Consumer优先调用同机房的Service，当同一机房的service或者eureka不可用时，再去调用其他机房的服务。
1、Eureka分区服务配置
eureka.client.prefer-same-zone-eureka=true
eureka.client.region=beijing
eureka.client.availability-zones.beijing=zone1,zone2
eureka.client.serviceUrl.zone1=http://localhost:9002/eureka
eureka.client.serviceUrl.zone2=http://localhost:9003/eureka
注册中心选择逻辑：
如果prefer-same-zone-eureka为false，按照service-url下的 list取第一个注册中心来注册，并和其维持心跳检测。不会再向list内的其它的注册中心注册和维持心跳。只有在第一个注册失败的情况下，才会依次向其它的注册中心注册，总共重试3次，如果3个service-url都没有注册成功，则注册失败。每隔一个心跳时间，会再次尝试。
如果prefer-same-zone-eureka为true，先通过region取availability-zones内的第一个zone，然后通过这个zone取service-url下的list，并向list内的第一个注册中心进行注册和维持心跳，不会再向list内的其它的注册中心注册和维持心跳。只有在第一个注册失败的情况下，才会依次向其它的注册中心注册，总共重试3次，如果3个service-url都没有注册成功，则注册失败。每隔一个心跳时间，会再次尝试。
所以说，为了保证服务注册到同一个zone的注册中心，一定要注意availability-zones的顺序，必须把同一zone写在前面
2、对于服务调用者和服务提供者，都是通过eureka.instance.metadata-map.zone来设置属于哪个zone
服务消费者会先通过ribbon去注册中心拉取一份服务提供者的列表，然后通过eureka.instance.metadata-map.zone指定的zone进行过滤，过滤之后如果同一个zone内的服务提供者有多个实例，则会轮流调用。
只有在同一个zone内的所有服务提供者都不可用时，才会调用其它zone内的服务提供者。
3、扩展配置
eureka.instance.lease-renewal-interval-in-seconds: 30
服务和注册中心的心跳间隔时间，默认为30s
eureka.instance.lease-expiration-duration-in-seconds: 90
服务和注册中心的心跳超时时间，默认为90s
三、Eureka与Zookeeper
Dubbo使用Zookeeper作为注册中心，而SpringCloud使用Eureka作为注册中心。两者作为服务中心，在单点使用时差别不大，但是在作为集群服务时有些区别。
1、以CAP理论，zookeeper是保证CP的，而Eureka是保证AP的。即在集群面临各种宕机、网络波动等分布式问题时，前者更偏向保证数据一致，而后者更偏向保证服务可用。
2、集群方式：zookeeper集群需要以选举算法保证集群中有一个唯一的leader，这样，集群在选举过程中，容易导致短暂服务不可用。而Eureka集群的方式则是简单的互相注册，即把当前Eureka节点也作为一个服务，向其他Eureka节点进行注册。这样当有节点宕机后，直接用另外一些节点提供服务即可。但是这时，就存在节点之间数据同步没有完成的问题。这个集群方式也是两者CP与AP之争的根本。
3、Eureka的自我保护机制也是别人说Eureka更适合做服务中心的特点之一。
个人观点，如果不是云环境，用哪个随缘把。
![[noip2010]关押罪犯 并查集](http://pic.xiahunao.cn/[noip2010]关押罪犯 并查集)
抱怨形状.为什么？)
