springcloud学习笔记2：eureka

在以前，没有学习springcloud以前，学习了dubbo，dubbo是一个远程调用(RPC)框架，当时使用的是zookeeper注册中心，可是在springcloud2.x以前，springcloud是没有zookeeper的，那么是如何实现远程调用的呢？

1.eureka（springcloud1.x版本的注册中心）

　　springcloud在2019年也就是springcloud2以后才添加的zookeeper，在这以前，都是使用的springcloud自带的eureka注册中心实现的远程调用。

　　eureka是springcloud的核心，许多的服务都须要依赖eureka实现。

　　eureka与zookeeper的比较：

　　在以前使用的是zookeeper，如今学习eureka了解到，eureka也是一个注册中心，那么两个注册中心有什么区别呢？（若是都同样的话，为何要开发它）

　　首先回顾zookeeper：

　　zookeeper保证的是数据的一致性（CP特性），zookeeper是一主多从机制，也就是三台zookeeper只有一台是leader，其余的两台是follower，消费者请求进来后，不管是进入leader仍是follower，都会被移交给leader进行处理。

　　zookeeper的缺陷：由于保证了数据的一致性，那么若是leader宕机的话，就会读取到脏数据，以前zookeeper中有详细的介绍

　　Eureka：

　　eureka保证的是服务的可用性（AP特性），eureka集群中每一个节点都是平等的，所以在服务注册时，就须要在每一个节点都注册一份，三台节点中的数据都是同样的。这样就不会出现zookeeper中leader宕机读取脏数据的状况。解决了zookeeper的缺陷。

　　eureka的自我保护机制：

　　若是长时间不激活eureka的时候就会出现自我保护机制。

　　eureka在启动后，生产者每隔一段时间就会向eureka中发送心跳，eureka接收生产者的心跳，当网络延迟/服务器宕机等状况发生后，生产者不在向eureka发送心跳，eureka从接收不到心跳开始，默认90后，就会踢出这个生产者（Provider），可是若是出现大面积的生产者宕机——生产者的机房停电了，全部的服务器都没法发送心跳，这时eureka就不会踢出任何一个服务（会将全部的服务都保留下来，这就是AP性）

　　Eureka为何不会踢出大量的服务？

　　若是把eureka中的全部服务都踢出，当consumer进来后，发现没有可用的服务了，就会报错500，整个项目于就瘫痪了。

　　当大面积服务没有心跳，可是eureka不踢出的话，consumer进来后，仍然能够获取到服务，能够获取到数据，这个数据可能不是最新的数据（假如说由于网络延迟，致使eureka没有接收到心跳，这样eureka不会讲服务所有踢出，也就是说consumer仍然能够找到provider，provider仍然能够工做，只是由于网络延迟的缘由，可能如今获取的数据，其实已经被删除了，只不过删除的操做发生网络拥堵尚未到生产者中，这就会形成数据的不一致）

　　AP性：保证服务的可用性，不保证数据的一致性

　　CP性：保证数据的一致性，不保证服务的可用性

如何关闭eureka的自我保护机制

　　能够关，可是不能这么作

　　若是如今有一个服务就是不须要eureka的自我保护机制，那么能够想办法让eureka的自我保护失效。

　　方法：provider告诉eureka我每隔5秒给你发送一次心跳，若是你八秒后仍没有接受到个人心跳，那么你就将我踢出。

# 规定本身向eureka发送心跳的时间
# 单位是秒
eureka.instance.lease-renewal-interval-in-seconds=5
# 当eureka最后一次检测到心跳的时间间隔(单位是秒)
# eg:15:05:20是最后一次检测到心跳-->检测8秒以后仍是没法检测心跳的时候直接剔除
eureka.instance.lease-expiration-duration-in-seconds=8

　　　　　　eureka中设置，默认等待provider10秒，10秒后尚未接受到心跳，就将provider踢出

# eureka本身检测服务的心跳时间(90秒)
# 单位是毫秒，先把eureka检测心跳的时间缩短为10秒
# 也就是说每一个10秒就会检测一次服务的心跳
eureka.server.eviction-interval-timer-in-ms=10000

 具体使用：https://github.com/Zs-xiazhi/springcloud-parent