SpringCloud之Eureka

随意写写，预备做成一个随时参考的详细文档把。
Demo参见。https://gitee.com/tearwind/SpringCloud.git

一、使用方法:

1、添加maven依赖

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

版本一般交由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和${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

注册中心选择逻辑：

1. 如果prefer-same-zone-eureka为false，按照service-url下的 list取第一个注册中心来注册，并和其维持心跳检测。不会再向list内的其它的注册中心注册和维持心跳。只有在第一个注册失败的情况下，才会依次向其它的注册中心注册，总共重试3次，如果3个service-url都没有注册成功，则注册失败。每隔一个心跳时间，会再次尝试。
2. 如果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更适合做服务中心的特点之一。
个人观点，如果不是云环境，用哪个随缘把。