"Eureka 的基本架构： Eureka 使用的市 cs 架构，：包含两个组件：Eureka Server 和 Eureka Client 。 Eureka Server 提供服务注册服务，各个节点启动后，会在 EurekaServer 中进行注册，这样 Eureka Server 中的服务注册表中 ...."

someone1
AI专业者开发社区 1 号成员
AI开发者社区 • 0 回帖 • 2 浏览 • 4 个月前

eureka（自我保护机制）（集群）（对比zookeeper）

Eureka 的基本架构：

Eureka 使用的市 cs 架构，：包含两个组件：Eureka Server 和 Eureka Client 。

Eureka Server 提供服务注册服务，各个节点启动后，会在 EurekaServer 中进行注册，这样 Eureka Server 中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
Eureka Client 是一个 Java 客户端，用于简化 EurekaServer 的交互，在应用启动后，将会向 EurekaServer 发送心跳（默认周期为 30 秒）。如果 Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，EurekaServer 将会从服务注册表中把这个服务节点移除掉（默认周期为 90 秒）

三大角色 Eureka Server：提供服务的注册于发现。
Service Provider：将自身服务注册到 Eureka 中，从而使消费方能够找到。（图右下）
Service Consumer：服务消费方从 Eureka 中获取注册服务列表，从而找到消费服务。（图左下）

创建 springcloud-eureka-7001 模块

pom.xml

 <dependencies>
        <!-- eureka-server 服务端 -->
        <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-eureka-server -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka-server</artifactId>
            <version>1.4.7.RELEASE</version>
        </dependency>
<!--        热部署 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
</dependency>
</dependencies>

application.yml

server:
  port: 7001
#Eureka 配置
eureka:
  instance:
    hostname: localhost #eureka 服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到 Eureka 服务器中，本身是服务器，无需注册
    fetch-registry: false # false 表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
#      单机：
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      # 设置与 Eureka Server 交互的地址查询服务和注册服务都需要依赖这个 defaultZone 地址

主启动类

package com.xflsh.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 {
public static void main(String[] args) {
SpringApplication.run(EurekaServer7001.class,args);
}
}

访问：localhost:7001

在 springcloud-provider-dept-8001 的 pom.xml 添加

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
<version>1.4.7.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>

application.yml 添加 eureka 的支持

#eureka 配置
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

8001 的主启动类注解支持

@SpringBootApplication
@EnableEurekaClient // 本服务启动之后会自动注册进 Eureka 中！
public class DeptProvider8001 {
    public static void main(String[] args){
        SpringApplication.run(DeptProvider8001.class,args);}
}

启动 7001，再启动 8001　　访问：localhost:7001

配置他的信息

在 8001 中 application.yml 添加

#info 配置
info:
  app.name: xflsh-springcloud　　# 服务名称修改
  company.name: www.xflsh.com　　# 公司名称
  build.artifactId: ${project.artifactId}　　# 项目名（pom.xml 中的artifactId 看到） 
　build.version: ${project.version}　　# 项目版本（pom.xml 中的 parent 看到）

info 内容构建

　　点击 info，出现 ERROR 页面

8001 添加依赖

<!--actuator 监控信息完善 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<build>
<finalName>springcloud</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>
<version>3.0.2</version>
<configuration>
<delimiters>
<!-- 以 $ 开头的或者结尾的在 src/main/resources 路径下的就能读取 -->
<delimit>$</delimit>
</delimiters>
</configuration>
</plugin>
</plugins>
</build>

点击上图绿色字体就可以看到配置信息

Eureka 的自我保护机制: 好死不如赖活着

修改一个服务名，故意制造错误

一句话总结：某时刻某一个微服务不可以用了，eureka 不会立刻清理，依旧会对该微服务的信息进行保存！

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

在自我保护模式中，EurekaServer 会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该 EurekaServer 节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话：好死不如赖活着。

综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让 Eureka 集群更加的健壮和稳定。

在 SpringCloud 中，可以使用 eureka.server.enable-self-preservation = false 禁用自我保护模式 【不推荐关闭自我保护机制】

8001 服务发现 Discovery

对于注册进 eureka 里面的微服务，可以通过服务发现来获得该服务的信息。【对外暴露服务】

8001 工程中的 DeptController 添加

@Autowired
    DiscoveryClient client;
@GetMapping("/discovery")
public Object discovery(){
//获得微服务列表清单
List<String> list = client.getServices();
System.out.println("client.getServices()==>"+list);
//得到一个具体的微服务！
List<ServiceInstance> serviceInstanceList =
client.getInstances("springcloud-provider-dept");
for (ServiceInstance serviceInstance : serviceInstanceList) {
System.out.println(
serviceInstance.getServiceId()+"\t"+
serviceInstance.getHost()+"\t"+
serviceInstance.getPort()+"\t"+
serviceInstance.getUri()
);
}
return this.client;
}

主启动类增加一个注解

@EnableDiscoveryClient //服务发现

访问测试 http://localhost:8001/dept/discovery

集群配置

集群就是：多个服务，一个服务提供者，服务和服务之间可以绑定多个服务，当其中一个服务挂掉了，其他也可继续操作。

1. 新建工程 springcloud-eureka-7002、springcloud-eureka-7003 按照 7001 为模板粘贴 POM

2. 修改 7002 和 7003 的主启动类

3. 修改映射配置

4.windows 域名映射

修改不了 host 因为权限不够

(17 条消息) 26- 在保存 hosts 文件时，报错 unable to save C:\windows\system32\drivers\etc\hosts error: 拒绝访问 ---- 文件权限修改 _ 汐小旅 Shiory 的博客 -CSDN 博客

就可以修改了。

7001 的 application.yml

server:
  port: 7001
#Eureka 配置
eureka:
  instance:
    hostname: eureka7001.com #eureka 服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到 Eureka 服务器中，本身是服务器，无需注册
    fetch-registry: false # false 表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
#      单机：
#      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #      集群：
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
      # 设置与 Eureka Server 交互的地址查询服务和注册服务都需要依赖这个 defaultZone 地址

7002 的 application.yml

server:
  port: 7002
#Eureka 配置
eureka:
  instance:
    hostname: eureka7002.com #eureka 服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到 Eureka 服务器中，本身是服务器，无需注册
    fetch-registry: false # false 表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
      #      单机：
      #      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #      集群：
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/

7003 的 application.yml

server:
  port: 7003
#Eureka 配置
eureka:
  instance:
    hostname: eureka7003.com #eureka 服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到 Eureka 服务器中，本身是服务器，无需注册
    fetch-registry: false # false 表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
      #      单机：
      #      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
#      集群：
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/

8080 的 application.yml 修改 eureka 配置

#eureka 配置
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
#      http://localhost:7001/eureka
#  http://eureka7001:7001/,http://eureka7002:7002/,http://eureka7003:7003/
  instance:
    instance-id: springcloud-provider-dept-8001 # 重点，和 client 平级
    prefer-ip-address: true

对比 zookeeper

CAP 原则 RDBMS

（Mysql、Oracle、sqlServer）===>ACID NoSQL（redis、mongdb）===> CAP ACID 是什么？

A（Atomicity）原子性

C（Consistency）一致性

I （Isolation）隔离性

D（Durability）持久性

CAP 是什么？

C（Consistency）

强一致性 A（Availability）

可用性 P（Partition tolerance）

分区容错性 CAP 的三进二：CA、AP、CP

CAP 理论的核心

一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求

根据 CAP 原理，将 NoSQL 数据库分成了满足 CA 原则，满足 CP 原则和满足 AP 原则三大类：

CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP：满足一致性，分区容错性的系统，通常性能不是特别高
AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

Zookeeper保证的是 CP 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30~120s，且选举期间整个 zk 集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得 zk 集群失去 master 节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

简单来说：Zookeeper 如果 leader 坏掉了，选举 leader 的时间太长且选举期间整个 zk 集群都是不可用的，会导致在选举期间注册服务瘫痪

Eureka保证的是 AP Eureka 看明白了这一点，因此在设计时就优先保证可用性。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka 的客户端在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台 Eureka 还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka 还有一种自我保护机制，如果在 15 分钟内超过 85% 的节点都没有正常的心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况： 1. Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 2. Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用） 3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中。

因此，Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪

eureka（自我保护机制）（集群）（对比zookeeper）

相关帖子

随便看看

eureka（自我保护机制）（集群）（对比zookeeper）