让人做网站需要准备什么条件,当当网网站建设,wordpress用户中心制作,淘宝指数官网的网址SpringCloud 有哪些核心组件?(必会)
Eureka: 注册中心, 服务注册和发现
Ribbon: 负载均衡, 实现服务调用的负载均衡
Hystrix: 熔断器 Feign: 远程调用
Zuul: 网关
Spring Cloud Config: 配置中心
(1)Eureka 提供服务注册和发现, 是注册中心. 有两个组…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 则是监听节点信息变化, 当服务节点信息变化时, 客户端立即就得到 通知.
