SpringCloud注册中心之Eureka基本原理

　　在上一篇文章中，我们讲了互联网架构的演变过程，我们可以想一个问题：随着我们的架构越来越复杂，我们需要的服务节点（实例）越来越多，我们对这些实例的管理就是不是越来越复杂？比如我们又n个服务相互之间有存在调用，而每个服务之间又有m个节点，这时候我们如何选择一个服务的一台实例进行调用？我们的服务上线或下线又如何进行管理？随着互联网架构的不断发展，这些东西全靠人工来维护，越来越不现实。所以就出现了注册中心，注册中心来帮我们管理这些内容。

　　下面我们一起来看看注册中心的原理

 通过上图我们可以看出，服务提供者在启动的时候需要向注册中心注册自己的信息，而注册中心把向自己注册的服务提供者都保存下来，以便服务消费者获取用来发起请求，而服务消费者需要从注册中心获取服务提供者列表，然后向服务提供者发起调用。

而服务消费者向注册中心获取服务提供者列表有两种方式：

　　1、消费者主动向注册中心拉取；

　　2、注册中心主动给服务消费者推送。

其实，服务提供者注册完自己之后还会和注册中心保持心跳，以此来证明自己还能正常提供服务。这样上面说到的那些情况无论动态感知上下线还是负载均衡，都不需要人为的去操作了，这些都交给服务自己去完成。这样就达到了服务解耦的作用。

下面我们来对比一下目前相对比较主流的一些注册中心

1、Zookeeper它是⼀个分布式服务框架，是Apache Hadoop 的⼀个⼦项⽬，它主要是⽤来解决分布式应 ⽤中经常遇到的⼀些数据管理问题，如：统⼀命名服务、状态同步服务、集群管理、分布式应⽤配置项的管理等。他的本质就是存储+监听

2、Nacos是⼀个更易于构建云原⽣应⽤的动态服务发现、配置管理和服务管理平台。简单来说 Nacos就是 注册中⼼ + 配置中⼼的组合，帮助我们解决微服务开发必会涉及到的服务注册 与发现，服务配置，服务管理等问题。Nacos 是 Spring Cloud Alibaba 核⼼组件之⼀，负责服务注册与发现，还有配置。

3、Eureka由Netflflix开源，并被Pivatal集成到SpringCloud体系中，它是基于 RestfulAPI ⻛格开发的服务注册与发现组件。

4、Consul是由HashiCorp基于Go语⾔开发的⽀持多数据中⼼分布式⾼可⽤的服务发布和注册服务软件， 采⽤Raft算法保证服务的⼀致性，且⽀持健康检查。

接下来我们重点来看一下本文的重点eureka。我们先来看一下他的整体架构图

 从图中我们可以发现：

　　1、eureka的主要角色分为服务端（server）和客户端（client）；

　　2、服务提供者会向server注册、注销、续约（默认30s，超过90s不续约将被注册中心剔除）、以及获取服务列表（客户端会缓存获取下来的列表）；

　　3、服务消费者会向注册中心获取服务列表，然后向服务提供者发起远程调用；

　　4、图中us-east-1c、us-east-1d，us-east-1e代表不同的区也就是不同的机房；

　　5、图中每⼀个Eureka Server都是⼀个集群；

　　6、每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的⽅式完成服务注册列表的同步；

 

eureka server 管理后台页面介绍

 

 eureka 的自我保护机制

当服务提供者向注册中心注册完自己的信息之后，服务提供者会定期的续约（服务提供者和注册中⼼通信），假如服务提供者和注册中⼼之间的⽹络有点问题，不代表服务提供者不可⽤，不代表服务消费者⽆法访问服务提供者。如果在15分钟内超过85%的客户端节点都没有正常的⼼跳，那么Eureka就认为客户端与注册中⼼出现了⽹络故障，Eureka Server⾃动进⼊⾃我保护机制。

当处于⾃我保护模式时eureka server不会剔除任何服务实例（可能是服务提供者和EurekaServer之间⽹络问题），保证了⼤多数服务依然可⽤；Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可⽤，当⽹络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中；

当然了，自我保护机制是可以通过参数eureka.server.enable-self-preservation进行关闭的，不过也没必要，毕竟这个机制也挺好的，保证你的服务的可用性。