任意的关键词或网站做引流广告视频

SpringCloud 有哪些核心组件?(必会)

 Eureka: 注册中心, 服务注册和发现

 Ribbon: 负载均衡, 实现服务调用的负载均衡

 Hystrix: 熔断器  Feign: 远程调用

 Zuul: 网关

 Spring Cloud Config: 配置中心

(1)Eureka 提供服务注册和发现, 是注册中心. 有两个组件: Eureka 服务端和 Eureka 客户端  Eureka 服务端: 作为服务的注册中心, 用来提供服务注册, 支持集群部署.

 Eureka 客户端: 是一个 java 客户端, 将服务注册到服务端, 同事将服务端的信息缓存 到本地, 客户端和服务端定时交互.

1. 原理

 Eureka-Server：就是服务注册中心（可以是一个集群），对外暴露自己的地址。

 提供者：启动后向 Eureka 注册自己信息（地址，服务名称等），并且定期进行服务续 约  消费者：服务调用方，会定期去 Eureka 拉取服务列表，然后使用负载均衡算法选出一 个服务进行调用。

 心跳(续约)：提供者定期通过 http 方式向 Eureka 刷新自己的状态

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

 服务的注册和发现都是可控制的，可以关闭也可以开启。默认都是开启

 注册后需要心跳，心跳周期默认 30 秒一次，超过 90 秒没发心跳认为宕机

 服务拉取默认 30 秒拉取一次.

 Eureka 每个 60 秒会剔除标记为宕机的服务

 Eureka 会有自我保护，当心跳失败比例超过阈值(默认 85%)，那么开启自我保护，不 再剔除服务。  Eureka 高可用就是多台 Eureka 互相注册在对方上.

(2)Ribbon

 Ribbon 是 Netflix 发布的云中服务开源项目. 给客户端提供负载均衡, 也就是说 Ribbon 是作用在消费者方的.

 简单来说, 它是一个客户端负责均衡器, 它会自动通过某种算法去分配你要连接的机 器.  SpringCloud 认为 Ribbon 这种功能很好, 就对它进行了封装, 从而完成负载均衡.  Ribbon 默认负责均衡策略是轮询策略.

(3)Hystrix 熔断器

 有时候可能是网络问题, 一些其它问题, 导致代码无法正常运行, 这是服务就挂了, 崩 溃了. 熔断器就是为了解决无法正常访问服务的时, 提供的一种解决方案.

 解决因为一个服务崩溃而引起的一系列问题, 使问题只局限于这个服务中,不会影响其 他服务.

 Hystrix 提供了两种功能, 一种是服务降级, 一种是服务熔断.

1. 服务降级原理

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

2. 服务熔断原理 状态机有 3 个状态：

 Closed：关闭状态（断路器关闭），所有请求都正常访问。

 Open：打开状态（断路器打开），所有请求都会被降级。Hystix 会对请求情况计数， 当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全关闭。默认失败比 例的阈值是 50%，请求次数最少不低于 20 次。

 Half Open：半开状态，open 状态不是永久的，打开后会进入休眠时间（默认是 5S）。 随后断路器会自动进入半开状态。此时会释放 1 次请求通过，若这个请求是健康的， 则会关闭断路器，否则继续保持打开，再次进行 5 秒休眠计时。

(4)Feign: 远程调用组件

 后台系统中, 微服务和微服务之间的调用可以通过 Feign 组件来完成.

 Feign 组件集成了 Ribbon 负载均衡策略(默认开启的, 使用轮询机制), Hystrix 熔断器 (默认关闭的, 需要通过配置文件进行设置开启)

 被调用的微服务需要提供一个接口, 加上@@FeignClient("url")注解  调用方需要在启动类上加上@EnableFeignClients, 开启 Feign 组件功能.

(5)Zuul: 路由/网关

  对于项目后台的微服务系统, 每一个微服务都不会直接暴露给用户来调用的, 但是如果 用户知道了某一个服务的 ip:端口号:url:访问参数, 就能直接访问你. 如果再是恶意访问, 恶意攻击, 就会击垮后台微服务系统.因此, 需要一个看大门的大 boss, 来保护我们的 后台系统.

 Zuul 类似 Nginx, 反向代理功能. 用户访问服务, 首先会到 Zuul 中心, Zuul 去 Eureka 中拉取服务, 获取服务列表, 获取具体的地址, 再通过具体的地址去访问目标微服务.

 Zuul 提供了过滤和路由两个功能, 过滤可以分配权限, 允许谁可以访问谁不可以访问, 路由则是去 Eureka 拉取服务提访问地址.

 Zuul 网关也继承了 Ribbon 负载均衡和 Hystix 熔断机制.

(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 中重新获取 最新的配置文件. 、

SpringBoot 和 SpringCloud 的关系(必会)

 SpringBoot 是为了解决 Spring 配置文件冗余问题, 简化开发的框架.

 SpringCloud 是为了解决微服务之间的协调和配置问题, 还有服务之间的通信, 熔断, 负载均衡远程调度任务框架.

 SpringCloud 需要依赖 SpringBoot 搭建微服务, SpringBoot 使用了默认大于配 置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，SpringCloud 很大的一部分是基于 SpringBoot 来实现。

 SpringBoot 不需要依赖 SpringCloud 就可以独立开发. SpringBoot 也可以集成 Dubbo 进行开发.

SpringCloud 和 Dubbo 的区别(高薪常问)

 SpringCloud 和 Dubbo 都是主流的微服务架构.

 SpringCloud 是 Apache 下的 Spring 体系下的微服务解决方案.

 Dubbo 是阿里系统中分布式微服务治理框架.

 技术方面对比  SpringCloud 功能远远超过 Dubbo, Dubbo 只实现了服务治理(注册和发现). 但 是 SpringCloud 提供了很多功能, 有 21 个子项目

 Dubbo 可 以 使 用 Zookeeper 作 为 注 册 中 心 , 实 现 服 务 的 注 册 和 发 现 , SpringCloud 不仅可以使用 Eureka 作为注册中心, 也可以使用 Zookeeper 作为 注册中心.

 Dubbo 没有实现网关功能, 只能通过第三方技术去整合. 但是 SpringCloud 有 zuul 路由网关, 对请求进行负载均衡和分发. 提供熔断器, 而且和 git 能完美集成.

 性能方面对比

 由于 Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合 以 Hession 序列化完成 RPC。

 而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的，相对来说，Http 请求会有更大的报文，占的带宽也会更多。

 使用 Dubbo 时, 需要给每个实体类实现序列化接口, 将实体类转化为二进制进行 RPC 通信调用.而使用 SpringCloud 时, 实体类就不需要进行序列化. 刚才有提到注册中心不一样,那么 Eureka 和 Zookeeper 有什么区别? 我们继续往 下说~

Eureka 和 Zookeeper 的区别(高薪常问)

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

 Eureka 满足 AP(服务可用性和容错性), Zookeeper 满足 CP(数据一致性和容错性)

 Zookeeper 满足 CP, 数据一致性, 服务的容错性. 数据在各个服务间同步完成后才返 回用户结果, 而且如果服务出现网络波动导致监听不到服务心跳, 会立即从服务列表中 剔除, 服务不可用.

 Eureka 满足 AP, 可用性, 容错性. 当因网络故障时, Eureka 的自我保护机制不会立即 剔除服务, 虽然用户获取到的服务不一定是可用的, 但至少能够获取到服务列表. 用户 访问服务列表时还可以利用重试机制, 找到正确的服务. 更服务分布式服务的高可用需 求.

 Eureka 集群各节点平等, Zookeeper 集群有主从之分.

1. 如果 Zk 集群中有服务宕机,会重新进行选举机制,选择出主节点, 因此可 能会导致整个集群因为选主而阻塞, 服务不可用.

2. Eureka 集群中有服务宕机,因为是平等的各个服务器,所以其他服务器不 受影响.

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

1. Eureka 中获取服务列表后会缓存起来, 每隔 30 秒重新拉取服务列表.

2. Zk 则是监听节点信息变化, 当服务节点信息变化时, 客户端立即就得到 通知.