一、Eureka 简介
1、Eureka 与服务注册与发现
Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心，比如Zookeeper。
2、Eureka 原理讲解
Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。
Eureka 包含两个组件：Eureka Server 和 Eureka Client。Eureka Server 提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。Eureka Client是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）。
3、Eureka 三大角色
（1）Eureka Server 提供服务注册和发现（提供注册与发现）
（2）Service Provider 服务提供方将自身服务注册到 Eureka，从而使服务消费方能够找到（服务提供方）
（3）Service Consumer 服务消费方从 Eureka 获取注册服务列表，从而能够消费（服务消费方）
二、构建步骤
1、构建 microservicecloud-eureka-7001
pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.atguigu.springcloud</groupId>
<artifactId>microservicecloud</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<artifactId>microservicecloud-eureka-7001</artifactId>
<dependencies>
<!--eureka-server服务端 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>
<!-- 修改后立即生效，热部署 -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>springloaded</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
</dependency>
</dependencies>
</project>
application.yml
server: port: 7001 eureka: instance: hostname: localhost #eureka服务端的实例名称 client: register-with-eureka: false #false表示不向注册中心注册自己。 fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务 service-url: defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址。
EurekaServer7001_App
package com.atguigu.springcloud; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer; @SpringBootApplication @EnableEurekaServer //EurekaServer服务器端启动类,接受其它微服务注册进来 public class EurekaServer7001_App { public static void main(String[] args) { SpringApplication.run(EurekaServer7001_App.class, args); } }
测试：启动该微服务，浏览器输入：http://localhost:7001/ 展示如下：
No instances available：因为没有注册服务进来当然不可能有服务被发现。
2、将已有的部门微服务（microservicecloud-provider-dept-8001）注册进eureka服务中心
修改microservicecloud-provider-dept-8001
（1）pom.xml新增 eureka 客户端依赖
<!-- 将微服务provider侧注册进eureka -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
（2）application.yml 新增 eureka 服务
eureka: client: #客户端注册进eureka服务列表内 service-url: defaultZone: http://localhost:7001/eureka
（3）启动类 DeptProvider8001_App.java 添加 EnableEurekaClient 注解
@EnableEurekaClient //本服务启动后会自动注册进eureka服务中
测试：依次启动 7001、8001 微服务，输入eureka 地址：http://localhost:7001/
MICROSERVICECLOUD-DEPT 是 8001中配置文件定义的应用名（spring.application.name: microservicecloud-dept）
（4）actuator与注册微服务信息完善
从上图中可以看到，微服务 MICROSERVICECLOUD-DEPT 对应的 Status 是 UP (1) - 192.168.7.101:microservicecloud-dept:8001，如果希望把它改为指定的显示，可以在microservicecloud-provider-dept-8001 的 application.yml 中做如下修改：
eureka: client: #客户端注册进eureka服务列表内 service-url: defaultZone: http://localhost:7001/eureka instance: instance-id: microservicecloud-dept8001
新增了instance.instance-id:microservicecloud-dept8001。修改之后，重新访问 http://localhost:7001/ 发现Status 改为了修改后的
有时用鼠标指向上图红色框起来的部分，右下角会出现 localhost:8001/info，为了让 localhost 变成 ip 地址，需要继续修改 application.yml
eureka: client: #客户端注册进eureka服务列表内 service-url: defaultZone: http://localhost:7001/eureka instance: instance-id: microservicecloud-dept8001 prefer-ip-address: true #访问路径可以显示IP地址
新增了 prefer-ip-address: true，修改之后重新指向上图红色框起来的部分，左下角已变成 ip（不知道为什么未加该属性，也显示的ip ？？？）
这时点击上图的 microservicecloud-dept8001 报错404
现在通过配置的方式，使点击上述部分展示出指定信息
a、给8001微服务添加依赖，pom.xml 文件新增
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
b、给父工程添加构建build信息，pom.xml 文件新增
<build>
<finalName>microservicecloud</finalName>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<delimiters>
<delimit>$</delimit>
</delimiters>
</configuration>
</plugin>
</plugins>
</build>
说明：finalName 是工程名，src/main/resources 路径下的所有资源文件可以通过 maven-resources-plugin 插件读取，读取的可以是常量或者以$开头结尾。
c、修改8001微服务的 application.yml ，添加如下配置
info: app.name: atguigu-microservicecloud company.name: www.atguigu.com build.artifactId: $project.artifactId$ build.version: $project.version$
info 对应鼠标移到 microservicecloud-dept8001 上时展示的 192.168.7.101:8001/info 中的info。重新启动，点击如下：
3、eureka 的自我保护机制
如果长时间不访问微服务（默认），访问 eureka 监控界面会出现一段红色字提示：
默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。
在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着。
综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。
在Spring Cloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式。不建议禁用。
4、服务的发现
a、修改8001微服务的 DeptController.java，添加如下内容
@Autowired private DiscoveryClient client; @RequestMapping(value = "/dept/discovery", method = RequestMethod.GET) public Object discovery() { List<String> list = client.getServices(); System.out.println("**********" + list); List<ServiceInstance> srvList = client.getInstances("MICROSERVICECLOUD-DEPT"); for (ServiceInstance element : srvList) { System.out.println(element.getServiceId() + " " + element.getHost() + " " + element.getPort() + " " + element.getUri()); } return this.client; }
b、修改8001微服务的主启动类 DeptController.java，添加如下注解
@EnableDiscoveryClient //服务发现
启动 eureka 和8001，输入 http://localhost:8001/dept/discovery 测试。入驻 eureka 的微服务已经打印出了
c、测试消费端是否能从 eureka 发现服务
在消费端微服务 microservicecloud-consumer-dept-80 的 DeptController_Consumer.java 中添加如下代码：
@RequestMapping(value = "/consumer/dept/discovery") public Object discovery()
{ return restTemplate.getForObject(REST_URL_PREFIX + "/dept/discovery", Object.class); }
启动该微服务，输入：http://localhost/consumer/dept/discovery 测试。入驻 eureka 的微服务已经打印出了
三、eureka 集群
1、新建 microservicecloud-eureka-7002 和 microservicecloud-eureka-7003
pom.xml 依赖一样、启动类分别为 EurekaServer7002_App.java、EurekaServer7003_App.java 内容一样
2、修改host文件映射配置：C:WindowsSystem32driversetc
添加如下配置：
127.0.0.1 eureka7001.com 127.0.0.1 eureka7002.com 127.0.0.1 eureka7003.com
3、分别设置7001、7002、7003的 application.yml 为如下配置
1 server: 2 port: 7001 3 4 eureka: 5 instance: 6 hostname: eureka7001.com #eureka服务端的实例名称 7 client: 8 register-with-eureka: false #false表示不向注册中心注册自己。 9 fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务 10 service-url: 11 defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
1 server: 2 port: 7002 3 4 eureka: 5 instance: 6 hostname: eureka7002.com #eureka服务端的实例名称 7 client: 8 register-with-eureka: false #false表示不向注册中心注册自己。 9 fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务 10 service-url: 11 defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
1 server: 2 port: 7003 3 4 eureka: 5 instance: 6 hostname: eureka7003.com #eureka服务端的实例名称 7 client: 8 register-with-eureka: false #false表示不向注册中心注册自己。 9 fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务 10 service-url: 11 defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/
其中较单个 eureka 微服务相比，修改的是第6行和第11行
4、microservicecloud-provider-dept-8001 微服务发布到上面3台eureka集群配置中
修改8001微服务的 application.yml，注册地址（defaultZone）由一个改为三个，如下
1 eureka: 2 client: #客户端注册进eureka服务列表内 3 service-url: 4 defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
依次启动 7001、7002、7003、8001 微服务，测试结果可以看到集群已经生效
输入：http://eureka7001.com:7001/
输入：http://eureka7002.com:7002/
输入：http://eureka7003.com:7003/
四、CAP原则及Eureka与Zookeeper的比较
1、CAP原则
RDBMS：（mysql/oracle/sqlServer）===>遵循ACID
A（Atomicity）原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1、从A账户取100元；2、存入B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C（Consistency）一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
I （Isolation）独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易未完成的情况下，如果此时B查询自己的账户，是看不到新增的100元的。
D（Durability）持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
NOSQL：（redis/mongdb）===>遵循CAP
C（Consistency）强一致性
A（Availability）可用性
P（Partition tolerance）分区容错性
CAP的3进2：任何一个系统无法同时满足CAP，只能从这3个里面满足两个
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性、可用性、分区容错性这三个需求，因此，根据CAP原理将NOSQL数据库分成了满足CP原则、CP原则和AP原则三大类：
CA-单点集群，满足一致性、可用性的系统，通常在可扩展性上不太强大。
CP-满足一致性、分区容忍性的系统，通常性能不是特别高。
AP-满足可用性、分区容忍性的系统，通常可能对一致性要求低一些。
由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以只能在一致性和可用性之间进行权衡。双11选择AP
2、Eureka与Zookeeper的比较
（1）Zookeper遵循CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其它节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30·120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
（2）Eureka遵循 AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发生连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与服务中心出现了网络故障，此时会出现以下几种情况：
a、Eureka不在从注册列表中移除因为长时间没收到心跳而过期的服务
b、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）
c、当网络稳定时，当前实例新的注册信息会被同步到其他节点中
因此：Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。