springcloud之微服务Eureka组件原理实现

springcloud常用组件
1、服务注册与发现：Eureka      ---由nacos替换
2、服务网关: Zuul         -- ---版本不更新，由 GateWay替换
3、服务负载均衡：Ribbon
4、服务之间调用：Feign     ----Feign是在2019就已经不再更新了，随之取代的是OpenFeign，从名字上就可以知道，它是Feign的升级版
5、服务熔断：Hystrix   ---因官网不继续维护，可以使用阿里提供的Alibaba Sentinel 轻量级的流量控制、熔断降级 Java 库
6、配置中心：config     ---如果不想自己维护，可以使用阿里云nacos作为配置中心
7、服务链路追踪：Sleuth     
8、链路日志服务：Zipkin      ---Sleuth和Zipkin一起组合使用
9、分布式事务：Seata 


1、服务注册与发现：Eureka
Eureka分客户端client和服务端server。各微服务为客户端client（Eureka客户端，注解@EnableEurekaClient），将自己的信息注册到server。
微服务启动后(默认每隔30秒)，client做2件事：1. 从服务端server拉取最新注册服务信息。2. 向server发送心跳，告诉server自己没有挂（这就是所谓的续约）。

Eureka服务端server：在一定时间（默认90秒）内没有收到某个微服务节点的心跳，server将会注销该微服务节点。如果非正常下线比如shutdown等命令就会Zureka导致几十秒内服务不可用。
每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的方式完成服务注册表的同步。
Eureka server存储客户端端口号，IP地址等。

定义服务续约任务的调用间隔时间，
客户端默认30秒    eureka.instance.lease-renewal-interval-in-seconds=30# 
定义服务端失效的时间默认90秒       eureka.instance.lease-expiration-duration-in-seconds=90

Eureka客户端从服务端Server拉去实例信息间隔时间
缓存清单的更新时间，默认30秒    eureka.client.registry-fetch-interval-seconds=30

Eureka服务端自我保护机制
EurekaServer会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况，EurekaServer会将这些实例保护起来，让其不过期，但是这样会让客户端拿到已经挂掉的服务实例，这就要求客户端必须要有容错机制（请求重试、断路器等） eureka.server.enable-self-preservation=false ： 关闭保护机制

自我保护机制原因解释：
如果开启了自我保护，主要是进一步判断是Eureka Server出了问题，还是Eureka Client出了问题
Eureka自我保护机制是为了防止误杀服务而提供的一个机制。Eureka服务端的自我保护机制“谦虚”的认为如果大量服务都续约失败，则认为是自己出问题了（如自己断网了），也就不剔除了。

注册列表存储（用ConcurrentHashMap实现并存储在内存中）
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
第一层hash map的key是app name，也就是应用名字,就是那个服务
第二层hash map的key是instance name，也就是实例名字，就是唯一主机id一样的唯一标识，value 存放着主机ip,端口等相关服务详情和服务治理相关的属性

Eureka实现了二级缓存来保存即将要对外传输的服务信息，数据结构完全相同。
一级缓存：ConcurrentHashMap<Key,Value> readOnlyCacheMap，本质上是HashMap，无过期时间，保存服务信息的对外输出数据结构。
二级缓存：Loading<Key,Value> readWriteCacheMap，本质上是guava的缓存，包含失效机制，保存服务信息的对外输出数据结构。
既然是缓存，那必然要有更新机制，来保证数据的一致性。下面是缓存的更新机制：

具体步骤可参考如下地址：SpringCloud-Eureka原理解析_谈少华的博客-CSDN博客_eureka原理

Eureka Server 如何实现高可用？
机制：将自己作为注册中心向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心。


Eureka和Zookeeper区别？
1、以CAP理论，zookeeper是保证CP的，而Eureka是保证AP的。即在集群面临各种宕机、网络波动等分布式问题时，前者更偏向保证数据一致，而后者更偏向保证服务可用。
2、集群方式：zookeeper集群需要以选举算法保证集群中有一个唯一的leader，这样，集群在选举过程中，容易导致短暂服务不可用。而Eureka集群的方式则是简单的互相注册，即把当前Eureka节点也作为一个服务，向其他Eureka节点进行注册。这样当有节点宕机后，直接用另外一些节点提供服务即可。但是这时，就存在节点之间数据同步没有完成的问题。这个集群方式也是两者CP与AP之争的根本。
3、Eureka的自我保护机制也是别人说Eureka更适合做服务中心的特点之一。

这里不具体写代码实例。目前我已经实践过

----------------------------------------------------------------------------------nacos-------------------------------------------------------------------------------------------------------

1、Nacos功能特性
(1)、服务发现与健康监测
(2)、动态配置管理
(3)、动态DNS服务
(4)、服务和元数据管理（管理平台的角度，nacos也有一个ui页面，可以看到注册的服务以及实例信息（元数据信息等），动态的服务权重调整，动态服务优雅下线，都可以去做）

2、注册中心原理
在使用注册中心时，一共有三种角色：服务提供者（Service Provider）、服务消费者（Service Consumer）、注册中心（Registry）。

一般服务提供者被称为Server，服务消费者被称为Client。
比如：order-server调用user-server，那么user-server就是服务提供者，order-server就是服务消费者

三个角色交互图：

Nacos注册中心架构：

 

注册中心的原理图2

 

服务注册表结构：

1）服务提供者Provider:

启动时，向 Registry 注册自己为一个服务（Service）的实例（Instance）
同时，定期向 Registry 发送心跳，告诉自己还存活。
关闭时，向 Registry 取消注册。

2）服务消费者Consumer:

启动时，向Registry订阅使用到的服务，并缓存服务的实例列表在内存中。
后续，Consumer 向对应服务的 Provider 发起调用时，从内存中的该服务的实例列表选择一个，进行远程调用。
关闭时，向 Registry 取消订阅。

3）注册中心Registry

服务提供者Provider超过一定时间未发送心跳时，将从注册中心的服务列表移除。
服务的实例列表发生变化（新增或者移除）时，通知订阅该服务的消费者Consumer，从而让 Consumer 能够刷新本地缓存。
另外，Provider 和 Consumer 是角色上的定义，**一个服务同时即可以是 Provider 也可以作为 Consumer。**例如说，优惠劵服务可以给订单服务提供接口，同时又调用用户服务提供的接口

Spring Cloud服务协作流程
Spring Cloud常见的集成方式是使用Feign+Ribbon技术来完成服务间远程调用及负载均衡的，如下图:

(1)   在微服务启动时，会向服务发现中心上报自身实例信息，这里ServiceB包含多个实例。

   每个实例包括:   IP地址+端口号

(2)  微服务会定期从Nacos Server(服务发现中心获取服务实例列表。

(3)  当ServiceA调用ServiceB时，ribbon组件从本地服务实例列表中查找ServiceB的实例，如获取了多个实例如Instance1、Instance2。这时ribbon会通过用户所配置的负载均衡策略从中选择一个实例。

(4)  最终，Feign组件会通过ribbon选取的实例发送http请求。

    采用Feign+Ribbon的整合方式，是由Feign完成远程调用的整个流程。而Feign集成了Ribbon,Feign使用Ribbon完成调用实例的负载均衡。
 

服务发现和服务健康监测

Nacos支持基于DNS和RPC的服务发现，即服务消费者可以使用DNS或者HTTP的方式来查找和发现服务。
Nacos提供对服务的实时的健康检查，阻止向不健康的主机或者服务实例发送请求。Nacos支持传输层（Ping/TCP）、应用层（HTTP、Mysql）的健康检查。

Nacos 配置中心介绍

Nacos 配置中心支持 namespace(命名空间)、group(分组)、dataId(数据id) 三个属性确定一个配置

• namespace：即命名空间，可以配置成 dev、test、pro 用于切换不用环境的配置，默认 public
• group：即分组，可以将同一个项目下的不用服务配置命名同一个分组统一管理，默认 DEFAULT_GROUP
• dataId: 即数据id，通常 dataId = ${spring.application.name}.${file-extension:properties} 或者dataId =${spring.application.name}-${profile}.${file-extension:properties}两种情况组成
• 三者都可以在配置文件中自定义配置

Nacos 配置动态刷新

• nacos 支持配置动态刷新
• nacos 配置动态刷新是默认开启的
• 如果想要关闭动态刷新功能，修改配置为spring.cloud.nacos.config.refresh.enabled=false 即可关闭动态刷新
• 如果需要在SpringBoot 配置类中动态读取 Nacos 配置有两种方式
  • 配置类上加注解 @RefreshScope(springcloud 提供) ，配置属性上依然使用 @Value 注解
  • 或者直接将配置属性上的@Value注解替换为@NacosValue(nacos 提供)注解，并设置autoRefreshed=true

nacos实战：SpringCloud 项目整合Nacos详细步骤_QTWWlhh的博客-CSDN博客_springcloud整合nacos