SpringCloud之SpringCloud常见面试题, SOA和微服务关系, SpringCloud和Dubbo区别, Eureka和Zookeeper区别「建议收藏」

SpringCloud之SpringCloud常见面试题, SOA和微服务关系, SpringCloud和Dubbo区别, Eureka和Zookeeper区别「建议收藏」1.SpringCloud是什么SpringCloud是一系列框架的集合,集成SpringBoot,提供很多优秀服务:服务发现和注册,统一配置中心,负载均衡,网关,熔断器等。2.SpringCloud的优势因为SpringCloud源于Spring,所以它的质量,稳定性,持续性都是可以保证的。SpringCloiud天热支持SpringBoot框架,就可以提高开发效率,能够实现需求。SpringCloud更新很快,后期支持很给力。SpringCloud可以用来开发微服务。3.Sp

大家好,又见面了,我是你们的朋友全栈君。

1. SOA和微服务的区别?

谈到SOA和微服务的区别, 那咱们先谈谈架构的演变

1.1 集中式架构

项目功能简单, 一个项目只需一个应用, 将所有功能部署在一起, 这样的架构好处是减少了部署节点和成本.
在这里插入图片描述

缺点:

  • 代码耦合,开发维护困难
  • 无法针对
  • 无法水平扩展
  • 单点容错率低,并发能力差

1.2 垂直拆分架构

当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求,我们根据业务功能对系统进行拆分:
在这里插入图片描述

优点:

  • 系统拆分实现了流量分担,解决了并发问题
  • 可以针对不同模块进行优化
  • 方便水平扩展,负载均衡,容错率提高

缺点:

  • 系统间相互独立,会有很多重复开发工作,影响开发效率

1.3 分布式服务

当垂直应用越来越多, 随着项目业务功能越来越复杂, 并非垂直应用这一条线进行数据调用, 应用和应用之间也会互相调用, 也就是完成某一个功能,需要多个应用互相调用, 这就是将功能拆完来完成的分布式架构.
在这里插入图片描述

优点

  • 将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率

缺点

  • 系统间耦合度变高,调用关系错综复杂,难以维护.

1.4 服务治理架构SOA

SOA :面向服务的架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键, 而最初的服务治理基石是Dubbo服务治理
在这里插入图片描述

以前出现了什么问题?

  • 服务越来越多,需要管理每个服务的地址
  • 调用关系错综复杂,难以理清依赖关系
  • 服务过多,服务状态难以管理,无法根据服务情况动态管理

服务治理要做什么?

  • 服务注册中心,实现服务自动注册和发现,无需人为记录服务地址
  • 服务自动订阅,服务列表自动推送,服务调用透明化,无需关心依赖关系
  • 动态监控服务状态监控报告,人为控制服务状态

缺点:

  • 服务间会有依赖关系,一旦某个环节出错会影响较大(容错机制)
  • 服务关系复杂,运维、测试部署困难,不符合DevOps思想

1.5 微服务

前面说的SOA,英文翻译过来是面向服务。微服务,似乎也是服务,都是对系统进行拆分。因此两者非常容易混淆,但其实缺有一些差别:
微服务的特点:

  • 单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
  • 微:微服务的服务拆分粒度很小,例如一个用户管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。
  • 面向服务:面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现,做到与平台和语言无关,也不限定用什么技术实现,只要提供Rest的接口即可。
  • 自治:自治是说服务间互相独立,互不干扰
    • 团队独立:每个服务都是一个独立的开发团队,人数不能过多。
    • 技术独立:因为是面向服务,提供Rest接口,使用什么技术没有别人干涉
    • 前后端分离:采用前后端分离开发,提供统一Rest接口,后端不用再为PC、移动段开发不同接口
    • 数据库分离:每个服务都使用自己的数据源.
    • 部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护. 基于docker容器是开发.
      在这里插入图片描述

目前微服务微服务架构主流的是SpringBoot+Dubbo和SpringBoot+SpringCloud的架构模式.

综上, 无论是SOA还是微服务, 都需要进行服务调度, 目前主流的服务调度室RPC和HTTP两种协议, 而Dubbo基于RPC的远程调度机构, SpringCloud是基于Rest风格(基于http协议实现的)的Spring全家桶微服务服务治理框架. 说到这里也可以继续说下Dubbo和SpringCloud的区别.

2. SpringCloud是什么

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

3. SpringCloud的优势

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

4. SpringCloud有哪些核心组件

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

4.1 Eureka

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

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

原理
在这里插入图片描述

  • Eureka-Server:就是服务注册中心(可以是一个集群), 对外暴露自己的地址.
  • 提供者:启动后向Eureka注册自己信息(地址,服务名称等),并且定期进行服务续约.
  • 消费者:服务调用方,启动后一方面会向Eureka注册自己的信息(地址, 服务名称)并定期续约, 另一方面会定期去Eureka拉取服务列表,然后使用负载均衡算法选出一个服务进行调用。
  • 心跳(续约):服务提供者定期通过http方式向Eureka刷新自己的存活状态.

服务下线、失效剔除和自我保护

  • 服务的注册和发现都是可控制的,可以关闭也可以开启。默认都是开启
  • 注册后需要心跳,心跳周期默认30秒一次,超过90秒没发心跳认为宕机
  • 服务拉取默认30秒拉取一次.
  • Eureka每个60秒会剔除标记为宕机的服务
  • Eureka会有自我保护,当心跳失败比例超过阈值(默认85%),那么开启自我保护,不再剔除服务。
  • Eureka高可用就是多台Eureka互相注册在对方上.

4.2 Ribbon

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

4.3 Hystrix熔断器

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

服务降级原理

  • Hystrix为每个服务分配了小的线程池, 当用户发请求过来, 会通过线程池创建线程来执行任务, 当创建的线程池已满或者请求超时(这里和多线程线程池不一样,不存在任务队列), 则启动服务降级功能.
  • 降级指的请求故障时, 不会阻塞, 会返回一个友好提示(可以自定义, 例如网站维护中请稍后重试), 也就是说不会影响其他服务的运行.

在这里插入图片描述
状态机有3个状态:

  • Closed:关闭状态(断路器关闭),所有请求都正常访问。
  • Open:打开状态(断路器打开),所有请求都会被降级。Hystix会对请求情况计数,当一定时间内失败请求百分比达到阈值,则触发熔断,断路器会完全关闭。默认失败比例的阈值是50%,请求次数最少不低于20次。
  • Half Open:半开状态,open状态不是永久的,打开后会进入休眠时间(默认是5S)。随后断路器会自动进入半开状态。此时会释放1次请求通过,若这个请求是健康的,则会关闭断路器,否则继续保持打开,再次进行5秒休眠计时。

4.4 Feign: 远程调用组件

  • 后台系统中, 微服务和微服务之间的调用可以通过Feign组件来完成.
  • Feign组件集成了Ribbon负载均衡策略(默认开启的, 使用轮询机制), Hystrix熔断器(默认关闭的, 需要通过配置文件进行设置开启)
  • 被调用的微服务需要提供一个接口, 加上@FeignClient(“url”)注解
    调用方需要在启动类上加上@EnableFeignClients, 开启Feign组件功能.

4.5 Zuul: 路由/网关

  • 对于项目后台的微服务系统, 每一个微服务都不会直接暴露给用户来调用的, 但是如果用户知道了某一个服务的ip:端口号:url:访问参数, 就能直接访问你. 如果再是恶意访问,恶意攻击, 就会击垮后台微服务系统.因此, 需要一个看大门的大boss, 来保护我们的后台系统.
  • Zuul类似Nginx, 反向代理功能. 用户访问服务, 首先会到Zuul中心, Zuul去Eureka中拉取服务, 获取服务列表, 获取具体的地址, 再通过具体的地址去访问目标微服务.
  • Zuul提供了过滤和路由两个功能, 过滤可以分配权限, 允许谁可以访问谁不可以访问, 路由则是去Eureka拉取服务提访问地址.
  • Zuul网关也继承了Ribbon负载均衡和Hystix熔断机制.

4.6 Spring Cloud Config

  • 在分布式系统中,由于服务数量巨多,为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件spring Cloud Config ,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中.
  • 那我们如果想在不重启微服务的情况下更新配置如何来实现呢? 我们使用SpringCloudBus来实现配置的自动更新.
    • 创建Config Server微服务, 用于存放配置文件, 默认使用git存储此项目.
    • 创建Config Client微服务, 用于拉取git上的配置文件, 项目中集成SpringCloudBus对应的消息中间件jar包.
  • 更新配置文件的流程
    • 手动向Mq队列中发送消息,http://127.0.0.1:12000/actuator/bus-refresh(固定地址)
    • Config Client中的MQ监听到消息, 去git服务器上加载新的配置文件, 并向mq中生产一条配置文件变更的消息.
    • 其他被集中管理的微服务也集成了mq,监听到消息, 向Config Client中重新获取最新的配置文件.

5. SpringBoot和SpringCloud的关系

  • SpringBoot是为了解决Spring配置文件冗余问题, 简化开发的框架.
  • SpringCloud是为了解决微服务之间的协调和配置问题, 还有服务之间的通信, 熔断, 负载均衡远程调度任务框架.
  • SpringCloud需要依赖SpringBoot搭建微服务, SpringBoot使用了默认大于配置的理念,很多集成方案已经帮你选择好了,能不配置就不配置,SpringCloud很大的一部分是基于SpringBoot来实现。
  • SpringBoot不需要依赖SpringCloud就可以独立开发. SpringBoot也可以集成Dubbo进行开发.

6. 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有什么区别? 我们继续往下说~

7. 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则是监听节点信息变化, 当服务节点信息变化时, 客户端立即就得到通知.
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/135803.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)
blank

相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号