Eureka的作用
消费者该如何获取服务提供者具体信息？
*服务提供者启动时向eureka注册自己的信息，eureka保存这些信息
*消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者，消费者该如何选择？
*服务消费者利用负载均衡算法，从服务列表中挑选一个
消费者如何感知服务提供者健康状态？
*服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
*Eureka会更新记录服务列表信息，心跳不正常会被剔除
*消费者就可以拉取到最新的信息
Eureka架构
EurekaServer：服务端，注册中心
*记录服务信息
*心跳监控
EurekaClient：客户端，包括Provider和Consumer
Provider：服务提供者
*注册自己的信息到EruekaServer
*每隔30s向EurekaServer发送自己的心跳
Consumer:服务消费者
*根据服务名称从EureKaServer拉取服务列表
*基于服务列表做负载均衡，选中一个微服务后发起远程调用
Erueka构建及使用步骤
1.搭建EurekaServer
*引入eureka-server依赖
*添加@EnableEurekaServer注解
*在application.yml中配置eureka地址
2.服务注册
*引入eureka-client依赖
*在application.yml中配置eureka地址
3.服务发现
*引入eureka-client依赖
*在application.yml中配置eureka地址
*给RestTemplate添加@LoadBalanced注解（实现负载均衡）
*用服务提供者的服务名称远程调用
Ribbon负载均衡
Ribbon负载均衡策略
*Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则
详细说明
RoundRobinRule简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的
定义IRule有两种方式
*在启动类中，定义一个新IRule并返回
@Bean
public IRule randomRule() {
return new RandomRule();
}
*在application.yml配置文件中定义
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
饥饿加载
Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：
ribbon:
eager-load:
enabled: true # 开启饥饿加载
clients: userservice # 指定对userservice这个服务饥饿加载
Eureka常见面试问题（转载）
1、客户端启动时如何注册到服务端？
Eureka客户端在启动时，首先会创建一个心跳的定时任务，定时向服务端发送心跳信息，服务端会对客户端心跳做出响应，如果响应状态码为404时，表示服务端没有该客户端的服务信息，那么客户端则会向服务端发送注册请求，注册信息包括服务名、ip、端口、唯一实例ID等信息。
2、服务端如何保存客户端服务信息？
客户端通过Jersey框架（亚马逊的一个http框架）将服务实例信息发送到服务端，服务端将客户端信息放在一个ConcurrentHashMap对象中。
3、客户端如何拉取服务端已保存的服务信息（是需要使用的时候再去拉取，还是先拉取保存本地，使用的时候直接从本地获取）？
客户端拉取服务端服务信息是通过一个定时任务定时拉取的，每次拉取后刷新本地已保存的信息，需要使用时直接从本地直接获取。
4、如何构建高可用的Eureka集群？
搭建高可用的Eureka集群，只需要在注册中心的配置文件中配置其他注册中心的地址
在eureka的高可用状态下，这些注册中心是对等的，他们会互相将注册在自己的实例同步给其他的注册中心，同样是通过问题1的方式将注册在自己上的实例注册到其他注册中心去。
那么问题来了，一旦 其中一个eureka收到一个客户端注册实例时，既然eureka注册中心将注册在自己的实例同步到其他注册中心中的方式和客户端注册的方式相同，那么在接收的eureka注册中心一端，会不会再同步回给注册中心（或者其他注册中心），从而导致死循环。
注册中心收到注册信息后会判断是否是其他注册中心同步的信息还是客户端注册的信息，如果是客户端注册的信息，那么他将会将该客户端信息同步到其他注册中心去；否则收到信息后不作任何操作。通过此机制避免集群中信息同步的死循环。
5、什么是服务续约
在注册服务完成以后,服务提供者会维持一个心跳(每30s定时向EurekaServer 分发起请求)告诉EurekaServer "我还活着"
6、什么是失效剔除
有时候,我们的服务提供方并不一定是正常下线,可能是内存溢出,网络故障等原因导致服务无法正常工作.EurekaServer会将这些失效的服务剔除服务列表.因此它会开启一个定时任务.每隔60秒会对失效的服务进行一次剔除
7、什么是自我保护
当服务未按时进行心跳续约时,在生产环境下,因为网络原因,此时就把服务从服务列表中剔除并不妥当发,因为服务也有可能未宕机.Eureka就会把当前实例的注册信息保护起来,不允剔除.这种方式在生产环境下很有效,保证了大多数服务依然可用
8、简述什么是CAP,并说明Eureka包含CAP中的哪些?
CAP理论:一个分布式系统不可能同时满足C (一致性),A(可用性),P(分区容错性).由于分区容错性P在分布式系统中是必须要保证的,因此我们只能从A和C中进行权衡.
Eureka 遵守 AP
Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,神域的节点依然可以提供注册和查询服务.而Eureka的客户端在向某个Eureka 注册或查询是如果发现连接失败,则会自动切换至其他节点只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查的信息可能不最新的不保证强一致性).
在分布式系统的CAP理论中，Eureka采用的AP，也就是Eureak保证了服务的可用性（A），而舍弃了数据的一致性（C）。当网络发生分区时，客户端和服务端的通讯将会终止，那么服务端在一定的时间内将收不到大部分的客户端的一个心跳，如果这个时候将这些收不到心跳的服务剔除，那可能会将可用的客户端剔除了，这就不符合AP理论。
9、Eureka默认的负载均衡策略
默认为轮询
（1）随机策略 RandomRule
就像是抽签，闭眼睛随便抓一个。
（2）轮询策略 RoundRobinRule
按顺序循环选择每个实例。
（3）重试策略 RetryRule
在轮询策略的基础上增加了重试机制，如果当前选择的实例不可用，就继续按照轮询策略选择下一个实例，直到找到可用的实例。
但注意重试是有时间限制的，不能不停的重试。
（4）最低并发策略 BestAvailableRule
选择并发最小的那个实例，也就是看谁清闲就找谁，哈哈。
（5）可用过滤策略 AvailabilityFilteringRule
过滤掉那些故障率高、压力大的实例。
（6）加权轮询策略 WeightedResponseTimeRule
加权就是为每个实例打个分，处理性能好的分值就越高，然后按照分值从高到低的顺序来轮询。
（7）区域权衡策略 ZoneAvoidanceRule
在大型系统中，可能会在多个区域进行部署，那么就可以根据各个区域的服务处理能力来选择实例。
精彩文章
发表评论