Eureka 服务注册与发现
什么是 Eureka
Eureka 是 Netfix 的一个子模块, 也是核心模块之一. Eureka 是一个基于 REST 的服务, 用于定位服务, 以实现云端中间层服务发现和故障转移, 服务注册与发现对于微服务来说是非常重要的, 有了服务注册与发现, 只需要使用服务的标识符, 就可以访问到服务, 而不需要修改服务调用的配置文件了, 功能类似于 Dubbo 的注册中心, 比如 Zookeeper.
原理
Eureka 的基本架构
SpringCloud 封装了 NetFilx 公司开发的 Eureka 模块来实现服务注册和发现.
Eureka 采用了 C-S 的架构涉及. EurekaServer 作为服务注册功能的服务器, 它是服务注册中心.
而系统中的其他微服务, 使用 Eureka 的客户端连接到 EurekaServer 并维持心跳连接. 这样系统的维护人员就可以通过 EurekaServer 来监控系统中各个微服务是否正常运行, SpringCloud 的一些其他模块 (比如 Zuul) 就可以通过 EurekaServer 来发现系统中的其他微服务, 并执行相关的逻辑.
Eureka 包含两个组件: Eureka Server 和 Eureka Client
Eureka Server 提供服务注册服务, 各个节点启动后, 会在 EurekaServer 中进行注册, 这样 Eureka Server 中的服务注册表中将会存储所有可用服务节点的信息, 服务节点的信息可以在界面中直观的看到.
Eureka Client 是一个 Java 客户端, 用于简化 Eureka Server 的交互, 客户端同时也具备一个内置的, 使用轮询负载算法的负载均衡器. 在应用启动后, 将会向 Eureka 发送心跳(默认周期为 30s). 如果 Eureka Server 在多个心跳周期内没有接收到某个节点的挑衅, Eureka Server 将会从服务注册表中把这个服务节点移除掉(默认周期为 90s).
三大角色
Eureka Server: 提供服务的注册与发现.
Service Provider: 将自身服务注册到 Eureka 中, 从而使消费方能够找到
Service Consumer: 服务消费方从 Eureka 中获取注册服务列表, 从而找到消费服务
Eureka 配置
注册中心配置
- server:
- port: 7001
- eureka:
- instance:
- hostname: localhost #Eureka 服务端的实例名
- client:
- register-with-eureka: false #表示是否向 Eureka 注册中心注册自己
- fetch-registry: false #fetch-registry 如果为 false, 则表示为注册中心
- service-url: #控制页面
- defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
客户端配置
- #Eureka 配置: 服务注册到配置中心
- eureka:
- client:
- service-url:
- defaultZone: http://localhost:7001/eureka/
- instance:
- instance-id: SpringCloud #修改 Eureka 中默认描述信息
自我保护机制:
某时刻某一个服务不可以用了, Eureka 不会立即清理, 依旧会在对该微服务的信息进行保存
默认情况下, 如果 RurekaServer 在一定事件内没有接收到某个微服务实例的心跳. RurekaServer 将会注销该实例(默认 90s). 但是当网络分区故障发生时, 微服务与 Eureka 之间无法正常通行, 以上行为可能变得非常危险了, 因为服务本身其实是健康的. 此时本不应该注销这个服务. Eureka 通过自我保护机制来解决这个问题, 当 EurekaServer 节点在短时间内丢失过多客户端时(可能发生了网络分区故障), 那么这个节点就会进入自我保护模式. 一旦进入该模式, EurekaServer 就会保护服务注册表中的信息, 不再删除服务注册表中的数据(也就是不会注销任何微服务). 当落网故障恢复后, 该 Eureka 节点会自动退出自我保护模式.
在自我保护模式中, EurekaServer 会保护服务注册表中的信息, 不再注销任务服务实例. 当它接收的心跳数重新会 u 发到阙值以上时, 该 EurekaServer 节点就会自动退出自我保护模式. 它的设计哲学就是宁可保留错误的注册信息, 也不盲目销毁任何可能健康的服务实例.
综上, 自我保护模式时一种对应网络异常的安全保护措施. 它的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留), 也不盲注注销任何健康的微服务. 使用自我保护模式, 可以让 Eureka 集群更加的健壮和稳定
在 SpringCloud 中, 可以使用 eureka.server.enable-self-preservation = false 禁用自我保护模式[不推荐关闭自我保护机制]
Eureka 对比 Zookeeper
CAP 原则
- RDBMS(MySQL,Oracle,sqlServer) ACID
- NoSQL(Redis,mongDB) CAP
ACID 是什么?
A(Atomicity)原子性
C(Consistency)一致性
I(Isolation)隔离性
D(Durablity)之就行
CAP 是什么?
C(Consistency)强一致性
A(Availablity)可用性
P(Parittion tolerance)分区容错性
CAP 只能选择其中两种(三进二):CA,AP,CP
作为服务注册中心: Eureka 和 Zookeeper 号在哪里?
著名的 CAP 理论指出, 一个分布式系统不可能同时满足 C(一致性),A(可用性),P(容错性)
由于分区容错性 P 在分布式系统中是必须要保证的, 因为我们只能在 A 和 C 之间进行权衡.
Zookpeeper 保证的是 CP
Eureka 保证的是 AP
Zookeeper 保证的是 CP
当向注册中心查询服务列表时, 我们可以容忍注册中心返回的是几分钟以前的注册信息, 但不能接受服务直接挂掉不可能. 也就是说, 服务注册功能对可用性的要求高于一致性. 但是 Zookeeper 会出现这样一种情况, 当 master 节点因为网络故障与其他节点实去联系时, 剩余节点会重新进行 leader 选举. 问题在于, 选举 leader 的时间太长, 30-120s, 且选举期间整个 zk 集群都是不可用的, 这就导致在选举期间注册服务瘫痪. 在云部署的环境下, 因为网络问题使得 zk 集群实去 master 节点是大概率会发生的事件, 虽然服务最终能够恢复, 但是漫长的选举事件导致的注册长期不可用是不能容忍的.
Eureka 保证的是 AP
Eureka 看明白了这一点, 因此在设计时就优先保证可用 i 选哪个. Eureka 各个节点都是平等的. 几个节点挂掉不会影响正常节点的工作, 剩余的节点依然可以提供注册查询服务. 而 Eureka 的客户端在向某个 Eureka 注册时, 如果发现连接失效, 则会自动切换至其他节点. 只要有一台 Eureka 还在, 就能保证注册服务的可用性. 只不过查到的信息可能不是最新的. 除此之外, Rureka 还有一致自我保护机制, 如果在 15 分钟内超过 85% 的节点都没有正常的心跳, 那么 Eureka 就认为客户端与注册中心出现了网络故障, 此时会出现以下几种情况:
Eureka 不再从注册列表中移出因为长时间没收到心跳而应该过期的服务
Eureka 仍然能够接受新服务的注册和查询请求, 但是不会被同步到其他节点上(即保证当前节点依然可用)
当网络稳定时, 当前节点新的注册信息会被同步到其他节点中
因此, Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况, 而不会像 Zookeeper 那样使整个注册服务瘫痪
来源: http://www.bubuko.com/infodetail-3361310.html