SpringCloud之SpringCloud常见面试题, SpringCloud和Dubbo区别, Eureka和Zookeeper区别

1. SpringCloud是什么

SpringCloud是一系列框架的集合，集成SpringBoot，提供很多优秀服务：服务发现和注册，统一配置中心, 负载均衡，网关, 熔断器等。

2. SpringCloud的优势

• 因为SpringCloud源于Spring，所以它的质量，稳定性，持续性都是可以保证的。
• SpringCloiud天热支持SpringBoot框架，就可以提高开发效率，能够实现需求。
• SpringCloud更新很快，后期支持很给力。
• SpringCloud可以用来开发微服务。

3. SpringCloud有哪些核心组件

• Eureka: 注册中心, 服务注册和发现
• Ribbon: 负载均衡, 实现服务调用的负载均衡
• Hystrix: 熔断器
• Zuul: 网关
• Feign: 远程调用
• spring cloud config: 配置中心

Eureka

提供服务注册和发现, 是注册中心. 有两个组件: Eureka服务端和Eureka客户端

• Eureka服务端: 作为服务的注册中心, 用来提供服务注册, 支持集群部署.
• Eureka客户端: 是一个java客户端, 将服务注册到服务端, 同事将服务端的信息缓存到本地, 客户端和服务端定时交互.

Ribbon

• Ribbon是Netflix发布的云中服务开源项目. 给客户端提供负载均衡, 也就是说Ribbon是作用在消费者方的.
• 简单来说, 它是一个客户端负责均衡器, 它会自动通过某种算法去分配你要连接的机器.对
• SpringCloud认为Ribbon这种功能很好, 就对它进行了封装, 从而完成负载均衡.

Hystrix熔断器

• 有时候可能是网络问题, 一些其它问题, 导致代码无法正常运行, 这是服务就挂了, 崩溃了.熔断器就是为了解决无法正常访问服务的时, 提供的一种解决方案.
• 解决因为一个服务崩溃而引起的一系列问题, 使问题只局限于这个服务中,不会影响其他服务.

Zuul: 路由/网关

• 类似Nginx, 反向代理功能. 访问服务, 首先会到Zuul中心, Zuul去Eureka中拉取服务, 获取服务列表, 获取具体的地址, 再通过具体的地址去访问目标微服务.
• 在这个过程中可以做负载均衡, 减轻服务的压力, 提供更好的服务.

4. SpringBoot和SpringCloud的关系

• SpringBoot是为了解决Spring配置文件冗余问题, 简化开发.
• SpringCloud是为了解决微服务之间的协调和配置问题, 还有服务之间的通信, 熔断, 负载均衡.
• SpringCloud需要依赖SpringBoot搭建微服务, 而SpringBoot不需要依赖SpringCloud就可以独立开发. SpringBoot也可以集成Dubbo进行开发.

5. SpringCloud和Dubbo的区别

• SpringCloud和Dubbo都是主流的微服务架构.
  1. SpringCloud是Apache下的Spring体系下的微服务解决方案.
  2. Dubbo是阿里系统中分布式微服务治理框架.
• 技术方面对比
  1. SpringCloud功能远远超过Dubbo, Dubbo只实现了服务治理(注册和发现). 但是SpringCloud提供了很多功能, 有21个子项目
  2. Dubbo可以使用Zookeeper作为注册中心, 实现服务的注册和发现, SpringCloud不仅可以使用Eureka作为注册中心, 也可以使用Zookeeper作为注册中心.
  3. Dubbo没有实现网关功能, 只能通过第三方技术去整合. 但是SpringCloud有zuul路由网关, 对请求进行负载均衡和分发. 提供熔断器, 而且和git能完美集成.
• 性能方面对比
  1. 由于Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC。
  2. 而SpringCloud是基于Http协议+Rest接口调用远程过程的，相对来说，Http请求会有更大的报文，占的带宽也会更多。
  3. 使用Dubbo时, 需要给每个实体类实现序列化接口, 将实体类转化为二进制进行RPC通信调用.而使用SpringCloud时, 实体类就不需要进行序列化.

刚才有提到注册中心不一样,那么Eureka和Zookeeper有什么区别? 我们继续往下说~

6. Eureka和Zookeeper的区别

在谈这个问题前我们先看下CAP原则: C-数据一致性; A-服务可用性; P-服务对网络分区故障的容错性, 这三个特性在任何分布式系统中不能同时满足, 最多通知满足两个, 而且P(分区容错性)是一定要满足的.

• Eureka满足AP(服务可用性和容错性), Zookeeper满足CP(数据一致性和容错性)
• Zookeeper满足CP,数据一致性, 服务的容错性. 数据在各个服务间同步完成后才返回用户结果, 而且如果服务出现网络波动, 会立即从服务列表中提出, 服务不可用.
• Eureka满足AP, 可用性, 容错性. 当因网络故障时, Eureka的自我保护机制不会立即剔除服务, 虽然用户获取到的服务不一定是可用的, 但至少能够获取到服务列表. 用户访问服务列表时还可以利用重试机制, 找到正确的服务. 更服务分布式服务的高可用需求
• Eureka集群各节点平等, Zookeeper集群有主从之分.

1. 如果Zk集群中有服务宕机,会重新进行选举机制,选择出主节点, 因此可能会导致整个集群因为选主而阻塞, 服务不可用.
2. Eureka集群中有服务宕机,因为是平等的各个服务器,所以其他服务器不受影响.

• Eureka的服务发现者会主动拉取服务, ZK服务发现者是监听机制

1. Eureka中获取服务列表后会缓存起来, 每隔30秒重新拉取服务列表
2. Zk则是监听节点信息变化, 当服务节点信息变化时, 客户端立即就得到通知.