Spring Cloud Eureka的基础架构

基础架构

• 服务注册中心：Eureka提供的服务端，提供服务注册于发现的功能，也就是在上一节中咱们实现的eureka-server

• 服务提供者：提供服务的应用，能够是springBoot应用，也能够是其余技术平台且遵循Eureka通讯机制的应用。它将
  

　　　　　　　　本身提供的服务注册到Eureka，以供其余应用发现，也就是上一节中咱们实现的HELLO-SERVICE应用。

• 服务消费者：消费者应用从服务注册中心获取服务列表，从而使消费者能够知道从何处调用其所须要的服务，在上一节

　　　　　　　　使用了Ribbon来实现服务消费，另外后续还需介绍是哦那个Feign的消费方式。

不少时候客户端既是服务提供者也是服务消费者。

 

服务治理机制

 

　　根据上面的结构，咱们来详细了解一下，从服务注册开始到服务调用，及各个元素涉及的一些重要通讯行为

服务提供者

　　1.服务注册

　　　　　　“服务提供者”在启动的时候会经过发送REST请求的方式将本身注册到EurekaServer上，同时带了自身服务的一些元

数据信息。Eureka Server接收到这个REST请求以后，将元素据信息存储在一个双层结构的MAP中，其中，第一层的key是服务名，

第二层的key是具体服务的实例名。一个服务有多个实例的状况下，这些内容就是以这样的双层Map形式存储的。

　　　　在服务注册时，须要确认下eureka.client.register-with-eureka=true 参数是否正确，该值默认为true。若设置为false将不会启动注册操做。

　　2.服务同步。

　　　　　　两个服务提供者分别注册到了两个不一样的服务注册中心上，也就是说，他们的信息分别被两个服务注册中心所维护。

此时，因为服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将请求转发给集群中

相连的其余注册中心，从而实现注册中心之间的服务同步。经过服务同步，两个服务提供者的服务信息就能够经过这两台服务注册中心的任意一台获取。

　　3.服务续约

　　　　　　在注册完服务以后，服务提供者会维护一个心跳用来持续告诉EurekaServer:"我还活着，"以防止Eureka Server的”剔除任务“将该服务实例从服务列表中排除出去。

咱们称该操做为服务续约。（Renew）

　　

服务消费者

　　1.获取服务

　　　　　　到这里，在服务注册中心已经注册了一个服务，而且该服务有两个实例。当咱们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取

上面的服务清单，为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30s更新一次。

　　　　　　

 

 　　2.服务调用

　　　　　　服务消费者在获取服务清单后，经过服务名能够得到具体提供服务的实例名和该实例的元数据信息。由于有这些服务实例

的详细信息，因此客户端能够根据本身的须要决定具体调用哪一个实例，在Ribbon中会默认采用轮询的方式进行调用，从而使客户端负载均衡。

　　　　　　对于访问实例的选择，Eureka中有Region和Zone的概念，一个Region中能够包含多个Zone，每一个服务客户端须要被注册到一个

Zone中，因此每一个客户端对应一个Region和一个Zone。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。

　　3.服务下线

 　　　　　　在系统运行过程当中必然会面临关闭或重启服务的某个实例的状况，在服务关闭期间，咱们天然不但愿客户端会继续调用关闭了的实例。因此在客户端

程序中，当服务实例进行正常的关闭操做时，它会出发一个服务下线的REST请求给EurekaServer，告诉服务注册中心：”我要下线了“。服务端接收到请求以后，将

该服务状态置为down。并把下线事件传播出去。

 

服务注册中心

　　1.失效剔除　

　　　　　　有些时候，咱们的服务实例并不必定会正常下线，可能因为内存溢出，网络故障等缘由使服务不能正常工做，而服务注册中心未

收到”服务下线“的请求。为了从服务列表中将这些没法提供服务的实例剔除。Eureka Server在启动的时候会建立一个定时任务，默认每隔一段时间

（默认60s）将当前清单中超时（默认为90s）没有续约的服务剔除出去。

　　2.自我保护

　　　　　　当咱们在本地调试基于Eureka的程序时，基本上都会碰到一个这样的问题，在服务注册宗信的信息面板出现类下面

的警告信息：

实际上，该警告就出发了Eureka Server的自我保护机制。服务注册到Eureka Server以后，会维护一个心跳链接，告诉Eureka Server本身还活着。

Eureka Server在运行期间，会统计心跳失败的比例在15分钟以内是否低于80%，若是出现低于的状况，Eureka Server会将当前的实例注册信息保护起来

让这些实例不会过时，尽量保护这些注册信息。可是，这段保护期间内实例出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的状况，

因此客户端必需要有容错机制，好比可使用请求重试，断路器机制等。