1、什么是 spring cloud？
spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。
2、spring cloud 的核心组件有哪些？
- Eureka：服务注册于发现
- Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。
- Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。
- Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。
- Zuul：网关管理，由 Zuul 网关转发请求给对应的服务。
3、什么是feigin？它的优点是什么？
- feign采用的是基于接口的注解
- feign整合了ribbon，具有负载均衡的能力
- 整合了Hystrix，具有熔断的能力
4、Ribbon和Feign的区别？
- Ribbon都是调用其他服务的，但方式不同
- 启动类注解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients
- 服务指定的位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明
- 调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。Feign需要将调用的方法定义成抽象方法即可
5、什么是Spring Cloud Bus?
spring cloud bus 将分布式的节点用轻量的消息代理连接起来，它可以用于广播配置文件的更改或者服务直接的通讯，也可用于监控。
如果修改了配置文件，发送一次请求，所有的客户端便会重新读取配置文件。
6、Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别
- ZooKeeper保证的是CP，Eureka保证的是AP
- ZooKeeper有Leader和Follower角色，Eureka各个节点平等（Eureka各个节点是平等关系，只要有一台Eureka就可以保证服务可用，而查询到的数据并不是最新的）
- ZooKeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题
- Eureka本质上是一个工程，而ZooKeeper只是一个进程
- Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像ZooKeeper一样使得整个注册系统瘫痪（ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的）
- Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)
7、什么是Hystrix?我们需要它吗？
防雪崩利器，具备服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）
由于某些原因，user-service 公开的服务引发异常，在这种情况下使用Hystrix ，定义一个回退方法。如果发生异常，就会返回一些默认值。（断路器的目的是为了给发生异常的方法或者这个方法可能调用其他方法留出时间，最终导致异常恢复）
服务降级：双十一 提示 哎哟喂，被挤爆了
优先核心服务，非核心服务不可用或弱可用。通过HystrixCommand注解指定。
fallbackMethod(回退函数)中具体实现降级逻辑。
zookeeper原理
zookeeper也可以作为注册中心，用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等）。
每启动一个微服务，就会去zookeeper中注册一个临时子节点，例如：5台订单服务，4台商品服务（5台订单服务在zk中的订单目录下创建的5个临时节点）、（4台商品服务在zk中的商品目录下创建的4个临时接点）。
每当有一个服务down机，由于是临时接点，此节点会立即被删除，并通知订阅该服务的微服务更新服务列表（zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）。
每当有一个新的微服务注册进来，就会在对应的目录下创建临时子节点，并通知订阅该服务的微服务更新服务列表。
每个微服务30s向zk获取新的服务列表。
CAP
分布式有三个指标：Consistency（一致性），Availability（可用性），Partition tolerance（分区容错性） 简称即为CAP。Eric 提出 CAP 不能全部达到，这就是CAP定理。
由于作为注册中心可用性的需求要高于一致性，所以eureka貌似要比zookeeper更合理一些
Consistency（一致性）
一致性就是说，我们读写数据必须是一模一样的。比如一条数据，分别存在两个服务器中，user—server1和user—server2。
我们此时将数据a通过server1修改为数据b。此时如果我们访问server1访问的应该是b。
但当我们访问server2的时候，如果返回的还是未修改的a，那么则不符合一致性，如果返回的是b，则符合数据的一致性。
Availability（可用性）
这个比较好理解，就是说，只要我对服务器，发送请求，服务器必须对我进行相应，保证服务器一直是可用的。
Partition tolerance（分区容错性）
一般来说，分布式系统是分布在多个位置的。比如我们的一台服务器在北京，一台在上海。可能由于天气等原因的影响，造成了两条服务器直接不能互相通信，数据不能进行同步。这就是分区容错。我们认为，分区容错是不可避免的。也就是说 P 是必然存在的。
eureka保证ap
**eureka优先保证可用性：**在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。
Eureka甚至被设计用来应付范围更广 的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中，新发布的服务仍然可以被发现与访问。
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。
除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
- Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
- 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
Eureka还有客户端缓存功能（注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。 所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解 决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息。
zookeeper保证cp
作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了；因为对于Service发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好；再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的。
因为zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的