SpringCloud如何实现服务的注册和发现

服务在发布时 指定对应的服务名（服务名包括了IP地址和端口） 将服务注册到注册中心
这一过程是springcloud自动实现 只需要在main方法添加@EnableDisscoveryClient 同一个服务修改端口就可以启动多个实例。
调用方法：传递服务名称通过注册中心获取所有的可用实例 通过负载均衡策略调用（ribbon和feign）对应的服务。

eureka简介

主要用于分布式框架的应用注册和服务发现，就类似于房屋中介，服务调用者相当于租房的人，服务提供者相当于房东，如果没有eureka这个中介，大家很难互相发现，租房子变得很难，但有了中介就相当于提供了平台，大家可以很方便地互相认识，高效地完成租房，也就是服务发现和调用。
同时，eureka还有服务续约机制，eureka要求他的客户端没过30秒发来一次心跳信号，通知一下我还要续约，这样有服务调用过来的时候，他才会给他转发，当90s还没有收到客户端的续约请求心跳信号，他就会将他移除注册中心，也就是服务剔除，以保证高可用，因为90s还没收到信号，说明这个服务有可能挂掉了。
注册列表信息：eureka客户端可以定期获取eureka的客户注册信息形成一个列表，所以能够从容地发起服务调用。客户端也可以选择主动把自己从注册表删除，即服务下线。
Eureka还带有一个基于 Java 的客户端组件 Eureka Client，它使与服务的交互变得更加容易。在 Netflix，更复杂的负载均衡器将 Eureka 包装起来，以基于流量，资源使用，错误条件等多种因素提供加权负载均衡，以提供出色的弹性。
eureka和gateway搭配实现负载均衡：服务注册进入eureka之后，配置gateway路由时，可以直接通过lb+服务名就可以实现负载均衡地对注册服务集群路由。

什么是服务熔断和服务降级？


熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。
服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然会出现局部的错误，但可以避免因为一个服务挂机，而影响到整个架构的稳定性。
Hystrix相关注解：
@EnableHystrix：开启熔断
@HystrixCommand(fallbackMethod=”XXX”)：声明一个失败回滚处理函数XXX，当被注解的方法执行超时（默认是1000毫秒），就会执行fallback函数，返回错误提示。

什么是Hystrix？它如何实现容错？

Hystrix是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。
比如商城分布式系统，我使用canal监控广告在mysql数据库的变化，并将变化数据查出来存到redis缓存中，这时就要用canal微服务远程调用canal把广告数据查出来
如果这时候，广告微服务突然挂了，网络连不上了，如果没有熔断和降级，canal就会一直在那等，redis也拿不到数据，redis也是干着急。从广告微服务到canal微服务到redis都在那等，谁也不动了。再卡一会，请求都集中起来了，如果请求很多，都挤在这大家一块阻塞，没准过一会就服务雪崩了。
这时候就到了Hystrix表现了，它看canal等的时间太长了，就判断说广告微服务挂了，你不要等他了，他这个服务我先给他停止了，我给你一个他原来设定过的默认的返回类型和你调用方法类型相同的fallback方法，你先拿回去凑合用，等他恢复了我再把这个服务开启，你就可以正常调用了。
不让用了就是熔断，返回fallback默认方法凑合用就是降级。
Hystrix怎么判断服务是不是需要熔断：

  1. 默认机制：5s内20次请求都失败了
  2. 请求时间超过了设定的时间（默认1000ms）

这个熔断和降级是非常有必要的，如果某个服务是因为请求太多被整挂了，这时候不熔断，其他请求还是蜂拥而至，那他更是应接不暇，甚至直接摆烂，但是熔断后就会给他喘息的机会，让他有更大的概率自我修复。

Eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。也就是说，服务注册功能对高可用性要求比较高，但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。
Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：

Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。

Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）。

当网络稳定时，当前实例新的注册信息会被同步到其他节点。

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪。

什么是OpenFeign

一开始服务间远程调用使用的是restTemplate，但是非常麻烦，每次都要 url、请求、返回类型的。openfeign出现后，可以直接将被调用服务代码映射到消费者端，就像调用本地方法一样进行远程调用了。
首先在服务提供者构建一个feign接口比如goodsFeign，里面提供类似于controller层的接口方法，并在接口上加上FeignClient注解，标识当前feign属于哪个微服务。
在服务调用方主方法上加上EnableFeignClients注解，并在后面加上远程feign接口所在的包，然后在代码中就可以像访问本地方法一样访问远程微服务的方法了。总结来说就是将被调用的服务代码映射到了消费者端。