SpringCloudNetflix---第一章---Eureka

Eureka

是什么？

• Eureka是Netflix的一个子模块，也是核心模块之一，Eureka是基于REST的服务，用于定位服务，实现云端中间层服务发现和故障转移，服务注册与发现对于微服务是非常重要的，有了服务注册与发现，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件，功能类似于Dubbo的注册中心，比如zookeeper

• Netflix在设计Eureka时，遵循AP原则

• 读作油瑞卡（这里粘贴不了音标 用谐音了）

Eureka原理讲解

Eureka的设计

Eureka的基本架构

• SpringCloud分装了Netflix公司开发的Eureka模块来实现服务的注册和发现（对比zookeeper）
• Eureka采用了C-S架构，EurekaServer作为服务注册功能的服务器，他就是服务注册中心
• 二系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接（每隔一段时间ping一下客户端，判断是否死亡），系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行（类似于DubboAdmin），SpringCloud的一些其他模块（比如zuul）就可以通过EurekaServer来发现系统中的其他微服务，并执行相关逻辑

Eureka包含两个组件：EurekaServer和EurekaClient。

• EurekaServer提供注册服务，各个节点启动后，会在
• EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会重组所有可用服务节点的信息，服务节点的信息可以在界面中直观的观察到。
• EurekaClient是一个java客户端，用于简化与EurekaServer的交互，客户端 同时也具备一个内置的，且使用轮询负载算法的负载均衡器，在应用启动后，将会对EurekaServer发送心跳（默认周期位30秒），如果EurekaServer在多个心跳周期没有接受到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期位90秒）

Eureka单机搭建

简单的单机搭建只有四步 导包----编写配置—配置注解—运行

导包

我们只需要保证pom文件有这个核心包就行了

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

当然也可以在创建SpringBoot项目勾选也可以实现自动导包

编写配置

application.yml

server:
  port: 6001

eureka:
  instance:
    hostname: localhost
  client:
    service-url:
      defaultZone: http://localhost:6001/eureka/    #默认地址，默认端口是8761
      register-with-eureka: false 				  #向其他eureka注册自己
    fetch-registry: false						#如果为false 那么自己就是注册中心

配置注解

我们在主启动类添加注解

@EnableEurekaServer

运行

浏览器输入地址就可以访问监控页面了

Eureka集群的搭建

集群的单间其实很简单 我们只需要更改配置文件就行了

为了方便区分，我们在此电脑添加路径映射

#C:\Windows\System32\drivers\etc\hosts
127.0.0.1 eureka1.com
127.0.0.1 eureka2.com
127.0.0.1 eureka2.com
#上面配置表示  所有的eureka都代表本机端口

我们来修改配置文件

server:
  port: 6002
eureka:
  instance:
    hostname: eureka2.com
  client:
    service-url:
      defaultZone: http://eureka1.com:6001/eureka/,http://eureka3.com:6003/eureka/ #地址关联
    register-with-eureka: true              
    fetch-registry: true  					

我们重点只需要更改端口号和地址的关联就行了

直接启动每个启动类就行了

我们观察一下监控面板

Eureka自我保护机制

当集群搭建完毕后，可能会出现集群中有些Eureka服务断掉，这个时候监控面板会出现以下警告，并自动开启自动保护机制

出现情况：

1. Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；
2. Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；
3. 当网络稳定时，当前实例新注册的信息会被同步到其它节点中

详解：

• 默认情况下，如果EurekaServer在一定时间没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例，但是当网络分区故障发生时（如服务器断电…），微服务与Eureka之间无法正常通信，那么注销服务这种行为就很危险了，因为微服务本身其实是健康的，此时本不应该注销这个服务，Eureka就会通过自我保护机制来解决这个问题，也就是当EurekaServer节点在短时间丢失过多客户端时（服务器断电，网络崩溃等等），那么这个节点就会进入自我保护模式，一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（不会注销任何微服务），当故障修复后（微服务重新注册进来），该EurekaServer节点会自动推出自我保护模式

• 在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例，当他收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式，他的设计哲学就是宁可保修错误的服务注册信息，也不盲目的注销任何可能健康的服务实例，

  综上，自我保护模式是一种应对网络异常的安全保护措施，使用该模式，可以让Eureka集群更加的健壮和稳定

  我们可以通过 eureka.server.anable-self.preservation=false 禁用自我保护模式，但是并不推荐

Eureka对比Zookeeper

同样的时注册与发现，eureka对比zookeeper又有什么区别呢？

CAP理论

CAP时分布式中重要的架构理论

• 一致性(Consistency) (所有节点在同一时间具有相同的数据)
• 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
• 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

当然CAP不能同时满足所有，最多只能满足两个，我们来推导一下

​ 当分布式以C为第一需求时，那么就必定会影响A的性能，因为数据需要同步，不然请求结果就会有差异，所以数据同步就需要时间，可用性就会降低。

​ 当分布式以A为第一需求时。那么只需要有一个服务在，他就能正常的接受请求，但是对于返回的结果将不会得到保证，因为在分布式部署过程中，数据一致的过程不可能像切线路那样快

​ 当然，如果要同时满足C和A的话，P将很难得到保证了，也就是单点，也就是分布式的基本核心

Zookeeper

​ Zookeeper在设计时就谨遵了CP原则，即任何时候访问Zookeeper的请求都能得到一致性的结果，同时系统对网络分割具备容错性，所以Zookeeper并不能保证每次请求的结果都是可达的

​ 从Zookeeper的实际应用情况来看，在使用Zookeeper获取服务列表是，如果此时的Zookeeper集群中的Leader（主服务器）宕机了，该集群就要进行Leader的选举，又或者Zookeeper集群中半数以上的服务器节点不可用（比如集群中有三个节点，节点以检测到节点三挂了，节点二也检测到节点三挂了，那么节点三是真的挂掉了），那么将无法处理该请求，所以说，Zookeeper不能保证服务的可用性

​ 在Zookeeper中，当master节点因为网络故障与其他节点失去联系时，剩余接待你就会重新进行Leader选举。问题就在这里，选举过程的时间太长了（大约30~120s），并且在选举期间整个zk集群都是不可用的，这就导致在选举期间整个注册服务的瘫痪

​ 当然，在云部署的环境下，因为网络问题使得zk集群失去master节点是大概率事件，虽然服务会最终恢复，但是漫长的选举时间当值注册长期不可有是不能容忍的

Eureka

​ Eureka设计师谨遵AP原则，即只要有一台Eureka还在，他就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证一致性）。在前面还提到过Eureka的自我保护机制，通过它，Eureka可以很好的应对因网络故障导致部分接待你失去练习的情况，而不会像zk那样使得整个注册服务瘫痪

​ 当一个新的Eureka Server节点启动后，会首先尝试从临近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过getEurekaServiceUrls（）方法获取所有的节点，并且通过心跳契约的方式定期更新

​ Eureka Server 也可以运行多个实列来构建集群，解决单点问题，但不同于Zookeeper的选举Leader的过程，Eureka Server采用的是peer to peer (p2p)来对等通信。通过这种去中心化的架构，就没有了master/slave之分。每个Peer都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

参考博文

本文地址：https://blog.csdn.net/VisionLau/article/details/110521709