SpringCloud Netflix---Eureka服务注册

没有不酸的柠檬

已于 2022-04-24 01:47:02 修改

阅读量476

点赞数

分类专栏： SpringCloud篇文章标签： springcloud eureka 微服务服务发现

于 2022-04-19 00:54:01 首次发布

本文链接：https://blog.csdn.net/I_am_fine_/article/details/124263100

版权

本文介绍了Eureka作为SpringCloud的服务注册中心，阐述了Eureka的基本原理、架构设计、服务注册与发现的机制，以及如何进行非集群和集群搭建。Eureka采用AP原则，保障服务在部分节点故障时仍能正常工作，对比了与Zookeeper的CP原则的差异。

摘要由CSDN通过智能技术生成

在这里插入图片描述
如上图所示，常见的微服务应用包括以上各个方面：网关控制，服务配置中心，服务注册中心，服务熔断降级，负载均衡，消息队列等，而SpringCloud Netflix针对以上问题，都有一个相对应的组件来处理相关问题，如：Eureka，Zuul等等。

Eureka注册中心介绍与使用

练习代码gitee地址： https://gitee.com/longjiamou/spring-cloud-netflix.git

1. 什么是Eureka

Eureka是NetFilx的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，实现服务的发现和故障转移，服务注册与发现对于微服务来说是非常重要的，它可以使我们通过服务的标识符（如：服务名等）来访问其他的服务，不需要修改服务调用的相关配置文件。总之，Eureka就是一个服务统一管理的中心，我们可以将我们开发的服务都注册到里面，然后就可以通过相关的标识符来访问其他服务。

2. Eureka原理

在这里插入图片描述

基本架构： Eureka采用了CS的架构设计，EurekaServer作为服务注册功能的服务器，可以设置为注册中心，其实他本身也是一个我们自己搭建的服务，我们也可以将它注册，就是自己注册自己，但普遍不这么用。而系统中的其他微服务，我们可以将它看为EurekaClient，将其他微服务注册到EurekaServer（也就是注册中心）并维持心跳连接。这样子我们就可以监控系统的各个服务状况。

CS架构： Eureka包含俩个组件，分别是Eureka Server和Eureka Client。

Eureka Server：Eureka Server提供服务注册，各个节点（服务）启动后，会在Eureka Server中进行注册，我们可以在注册中心中查看所有启动节点的相关信息。
Eureka Client：Eureka Client是一个java客户端，用于简化EurekaServer的交互，客户端同时具备一个内置的轮询负载均衡器，可以简单的实现一下负载均衡。在应用启动后，Eureka Client将想Eureka Server发送心跳（默认30秒一周期）。如果server在多个心跳周期中没有接收到某个节点的心跳，那么注册中心将会将这个节点移除掉（默认90秒）。所以，当我们的服务宕机后，注册中心并不会立刻将我们的服务节点删除，而是在等心跳机制，心跳机制后，如果服务还没有重新启动，注册中心才会将相关节点移除。

角色： Eureka Server：提供服务的注册与发现，Eureka Provider：将自身服务注册到Eureka中，方便消费者能够找到，Eureka Consumer：服务消费，从注册中心中找到相关的服务提供者。

3. Eureka原则

原则信息： Eureka遵循原则信息和我们的数据库的原则信息类似，都是：ACID，CPA等等

ACID： ACID泛指原子性，一致性，隔离性和持久性。

A（Atomicity）：原子性是指事务中的所有操作都是一个整体，里面的操作要么都成功，要么都失败。
C（Consistency）：执行前后的数据必须保持一致
I（Isolation）：隔离性是针对多个事务而言的，事务之间不能相互干扰，要隔离开来
D（Durability）：提交之后，对数据库中的数据的改变时永久性的，接下来即使数据库发生故障也不会影响

CAP： CAP泛指强一致性，可用性和分区容错性，在分布式系统中，不可能同时很好的满足以上三个条件，普遍采取三进二的原则，如：CP，CA，AP，在目前大多数的分布式系统中，因为要保证分区容错性，所以大多数都是在A和C之间选择，但在传统的一些服务来看，如：银行，就必须要保证一致性。

C（Consistency）：更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致
A（Availability）：服务一直可用，而且是正常响应时间
P（Partition Tolerance）：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，就是说，当一个服务挂掉之后，系统的其他服务还能使用，而不是整个系统不可用。

Eureka采用原则：Eureka采用的是AP原则，优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉都不会影响其他节点的正常工作，没有挂掉的节点依然可用提供注册和服务查询。在Eureka Client在向某个Eureka注册时，如果发现连接失败，客户端会自动切换到另一个节点注册，只要还有一个服务端的存在，客户端都可以完成注册，只不过查到的信息可能不是最新的。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有心跳的话，那么Eureka则会认为客户端和注册中心出现了网络故障，此时Eureka会做出以下行为：

Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然会接收新服务的注册，但是不会同步到其他节点上
当网络稳定时，当前实例新的注册信息（新服务）重新同步到其他节点上

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

zookeeper采用原则：zookeeper采用的是CP原则，优先保证强一致性。在zookeeper中，当master主节点因为网络故障与其他的节点失去联系时，剩余节点会重新进行leader选举。在选举的过程中，由于所需的时间过长，大概是30~120秒，在这个时间段zookeeper集群是不可用的，所以会导致整个分布式