Eureka注册中心原理

一、Eureka简介

　　Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。

　　1、Eureka组件

　　Eureka包含两个组件：Eureka Server和Eureka Client。

　　1.1 Eureka Server

　　Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
　　Eureka Server本身也是一个服务，默认情况下会自动注册到Eureka注册中心。
　　如果搭建单机版的Eureka Server注册中心，则需要配置取消Eureka Server的自动注册逻辑。毕竟当前服务注册到当前服务代表的注册中心中是一个说不通的逻辑。
　　Eureka Server通过Register、Get、Renew等接口提供服务的注册、发现和心跳检测等服务。

　　2.1 Eureka Client

　　Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。
　　Eureka Client分为两个角色，分别是：Application Service(Service Provider)和Application Client(Service Consumer)

　　2.1.1 Application Service

　　服务提供方，是注册到Eureka Server中的服务。

　　2.1.2 Application Client

　　服务消费方，通过Eureka Server发现服务，并消费。

　　在这里，Application Service和Application Client不是绝对上的定义，因为Provider在提供服务的同时，也可以消费其他Provider提供的服务；Consumer在消费服务的同时，也可以提供对外服务。

　2、Eureka Server架构原理简介

Register(服务注册)：把自己的IP和端口注册给Eureka。
Renew(服务续约)：发送心跳包，每30秒发送一次。告诉Eureka自己还活着。
Cancel(服务下线)：当provider关闭时会向Eureka发送消息，把自己从服务列表中删除。防止consumer调用到不存在的服务。
Get Registry(获取服务注册列表)：获取其他服务列表。
Replicate(集群中数据同步)：eureka集群中的数据复制与同步。
Make Remote Call(远程调用)：完成服务的远程调用。

三、集群版Eureka Server

　　注册中心作为微服务架构中的核心功能，其重要性不言而喻。所以单机版的Eureka Server在可靠性上并不符合现在的互联网开发环境。集群版的Eureka Server才是商业开发中的选择。

　　Eureka Server注册中心的集群和Dubbo的ZooKeeper注册中心集群在结构上有很大的不同。

　　ZooKeeper注册中心集群搭建后，集群中各节点呈现主从关系，集群中只有主节点对外提供服务的注册和发现功能，从节点相当于备份节点，只有主节点宕机时，从节点会选举出一个新的主节点，继续提供服务的注册和发现功能。　　而Eureka Server注册中心集群中每个节点都是平等的，集群中的所有节点同时对外提供服务的发现和注册等功能。同时集群中每个Eureka Server节点又是一个微服务，也就是说，每个节点都可以在集群中的其他节点上注册当前服务。又因为每个节点都是注册中心，所以节点之间又可以相互注册当前节点中已注册的服务，并发现其他节点中已注册的服务。所以Eureka Server注册中心集群版在搭建过程中有很多的方式，找到一个最合适最可靠的搭建方式才能称为一个称职的程序员。

四、Eureka Server安全认证

　　Eureka Server作为Spring Cloud中的服务注册中心，如果可以任意访问的话，那么其安全性太低。所以Spring Cloud中也有为Eureka Server提供安全认证的方式。可以使用spring-boot-starter-security组件来为Eureka Server增加安全认证。

　　POM依赖：

<!-- spring boot security安全认证启动器 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

　　修改全局配置文件，在全局配置文件中，开启基于http basic的安全认证。

eureka.instance.hostname=eurekaserver1
# 使用http basic安全认证语法，在集群通信中增加认证信息。  http://用户名:密码@地址:端口/eureka/
eureka.client.serviceUrl.defaultZone=http://test:123456@eurekaserver2:8761/eureka/

五、CAP定理

　　CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（数据一致性）、 Availability（服务可用性）、Partition tolerance（分区容错性），三者不可兼得。CAP由Eric Brewer在2000年PODC会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的CAP定理。

分布式系统CAP定理
数据一致性 (Consistency)	数据一致性(Consistency) 也叫做数据原子性系统在执行某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。 优点： 数据一致，没有数据错误可能。 缺点： 相对效率降低。
服务可用性 (Availablity)	每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。一定时间内指的是，在可以容忍的范围内返回结果，结果可以是成功或者是失败。
分区容错性 (Partition-torlerance)	在网络分区的情况下，被分隔的节点仍能正常对外提供服务(分布式集群，数据被分布存储在不同的服务器上，无论什么情况，服务器都能正常被访问)

定律：任何分布式系统只可同时满足二点，没法三者兼顾。
CA，放弃P	如果想避免分区容错性问题的发生，一种做法是将所有的数据(与事务相关的)/服务都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果。当然这个选择会严重的影响系统的扩展性。
CP，放弃A	相对于放弃"分区容错性"来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待一定时间，因此在等待时间内系统无法对外提供服务。
AP，放弃C	这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩下一件库存的商品，如果同时接受了两个订单，那么较晚的订单将被告知商品告罄。

　　Eureka和ZooKeeper的特性

 

六、服务保护

　　1 服务保护模式

　　服务保护模式（自我保护模式）：一般情况下，微服务在Eureka上注册后，会每30秒发送心跳包，Eureka通过心跳来判断服务时候健康，同时会定期删除超过90秒没有发送心跳服务。

　　导致Eureka Server接收不到心跳包的可能：一是微服务自身的原因，二是微服务与Eureka之间的网络故障。通常微服务的自身的故障只会导致个别服务出现故障，一般不会出现大面积故障，而网络故障通常会导致Eureka Server在短时间内无法收到大批心跳。虑到这个区别，Eureka设置了一个阀值，当判断挂掉的服务的数量超过阀值时，Eureka Server认为很大程度上出现了网络故障，将不再删除心跳过期的服务。

　　那么这个阀值是多少呢？Eureka Server在运行期间，会统计心跳失败的比例在15分钟内是否低于85%，如果低于85%，Eureka Server则任务是网络故障，不会删除心跳过期服务。

　　这种服务保护算法叫做Eureka Server的服务保护模式。

　　这种不删除的，90秒没有心跳的服务，称为无效服务，但是还是保存在服务列表中。如果Consumer到注册中心发现服务，则Eureka Server会将所有好的数据（有效服务数据）和坏的数据（无效服务数据）都返回给Consumer。

　　2 服务保护模式的存在必要性

　　因为同时保留"好数据"与"坏数据"总比丢掉任何数据要更好，当网络故障恢复后，Eureka Server会退出"自我保护模式"。

　　Eureka还有客户端缓存功能(也就是微服务的缓存功能)。即便Eureka Server集群中所有节点都宕机失效，微服务的Provider和Consumer都能正常通信。

　　微服务的负载均衡策略会自动剔除死亡的微服务节点（Robbin）。

　　只要Consumer不关闭，缓存始终有效，直到一个应用下的所有Provider访问都无效的时候，才会访问Eureka Server重新获取服务列表。

　　3 关闭服务保护模式

　　可以通过全局配置文件来关闭服务保护模式，商业项目中不推荐关闭服务保护，因为网络不可靠很容易造成网络波动、延迟、断线的可能。如果关闭了服务保护，可能导致大量的服务反复注册、删除、再注册。导致效率降低。在商业项目中，服务的数量一般都是几十个，大型的商业项目中服务的数量可能上百、数百，甚至上千：

# 关闭自我保护:true为开启自我保护，false为关闭自我保护
eureka.server.enableSelfPreservation=false
# 清理间隔(单位:毫秒，默认是60*1000)，当服务心跳失效后多久，删除服务。
eureka.server.eviction.interval-timer-in-ms=60000

　　4 优雅关闭服务（优雅停服）

　　在Spring Cloud中，可以通过HTTP请求的方式，通知Eureka Client优雅停服，这个请求一旦发送到Eureka Client，那么Eureka Client会发送一个shutdown请求到Eureka Server，Eureka Server接收到这个shutdown请求后，会在服务列表中标记这个服务的状态为down，同时Eureka Client应用自动关闭。这个过程就是优雅停服。

　　如果使用了优雅停服，则不需要再关闭Eureka Server的服务保护模式。

　　POM依赖：
　　优雅停服是通过Eureka Client发起的，所以需要在Eureka Client中增加新的依赖，这个依赖是autuator组件，添加下述依赖即可。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-actuator</artifactId>
</dependency>

　　修改全局配置文件：

　　Eureka Client默认不开启优雅停服功能，需要在全局配置文件中新增如下内容：

# 启用shutdown，优雅停服功能
endpoints.shutdown.enabled=true
# 禁用密码验证
endpoints.shutdown.sensitive=false

　　发起shutdown请求：

　　必须通过POST请求向Eureka Client发起一个shutdown请求。请求路径为：http://ip:port/shutdown。可以通过任意技术实现，如：HTTPClient、form表单，AJAX等。

　　建议使用优雅停服方式来关闭Application Service/Application Client服务。