1.Spring Cloud 外围性能是什么？
Spring Cloud 次要提供了如下外围的性能：
- Distributed/versioned configuration 分布式 / 版本化的配置管理
- Service registration and discovery 服务注册与服务发现
- Routing 路由
- Service-to-service calls 端到端的调用
- Load balancing 负载平衡
- Circuit Breakers 断路器
- Global locks 全局锁
- Leadership election and cluster state 选举与集群状态治理
- Distributed messaging 分布式音讯
2.Spring Cloud 有哪些组件？
因为 Spring Cloud Netflix 要进入保护模式，上面是一些能够代替组件
| Netflix | 阿里 | 其它 | |
|---|---|---|---|
| 注册核心 | Eureka | Nacos | Zookeeper、Consul、Etcd |
| 熔断器 | Hystrix | Sentinel | Resilience4j |
| 网关 | Zuul | 暂无 | Spring Cloud Gateway |
| 负载平衡 | Ribbon | Dubbo | spring-cloud-loadbalancer |
3.Spring Cloud 和 Spring Boot 的区别和关系？
- Spring Boot 专一于疾速不便的开发 单个个体微服务。
- Spring Cloud 是 关注全局的微服务协调整顿治理框架以及一整套的落地解决方案，它将 Spring Boot 开发的一个个单体微服务整合并治理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，微代理，事件总线等的集成服务。
- Spring Boot 能够来到 Spring Cloud 独立应用，然而 Spring Cloud 离不开 Spring Boot，属于依赖的关系。
总结：
- Spring Boot，专一于疾速，不便的开发单个微服务个体。
- Spring Cloud，关注全局的服务治理框架。
4. 有哪些能够作为 Spring Cloud 的注册核心
在 Spring Cloud 中，可能应用的注册核心，还是比拟多的，如下：
spring-cloud-netflix-eureka-server和spring-cloud-netflix-eureka-client，基于 Eureka 实现。spring-cloud-alibaba-nacos-discovery，基于 Nacos 实现。spring-cloud-zookeeper-discovery，基于 Zookeeper 实现。
5.SpringCloud 的注册和发现流程，以 Eureka 为注册核心
- 服务 启动时会生成服务的根本信息对象 InstanceInfo，而后 再启动时注册到服务治理核心
- 服务注册实现后，会 从服务治理核心拉取所有的服务信息，缓存在本地
- 之后服务会依据配置的 指定间隔时间发送一个心跳信息，续约服务
- 如果服务治理核心在 90s 内没有收到一个服务的续约，就会认为服务曾经挂了，会把 服务注册信息删除
- 服务 进行前，会被动发送一个进行申请，服务治理核心会删除这个服务的信息
- 如果 Eureka收到的心跳包有余正常值的 85%（可配置）就会 进入自我保护模式 ，这种模式，Eureka 不会删除任何服务信息
6. 说说 Spring Cloud 的负载平衡, 为什么要负载平衡
简略来说，随着业务的倒退，单台服务无奈撑持拜访的须要 ，于是 搭建多个服务造成集群 。那么随之要解决的是， 每次申请，调用哪个服务，也就是须要进行负载平衡。
目前负载平衡有两种模式：
- 客户端模式
- 服务端模式
在 Spring Cloud 中，咱们应用前者，即客户端模式。
在计算中，负载平衡能够改善跨计算机，计算机集群，网络链接，地方处理单元或磁盘驱动器等 多种计算资源的工作负载散布 。负载平衡旨在 优化资源应用，最大化吞吐量，最小化响应工夫并防止任何繁多资源的过载。应用多个组件进行负载平衡而不是单个组件可能会通过冗余来进步可靠性和可用性。负载平衡通常波及专用软件或硬件，例如多层交换机或域名零碎服务器过程。
7.Ribbon 有哪些负载平衡算法？
RoundRobinRule：默认轮询的形式
RandomRule：随机形式
WeightedResponseTimeRule：依据响应工夫来调配权重的形式，响应的越快，调配的值越大。
BestAvailableRule：抉择并发量最小的形式
RetryRule：在一个配置时间段内当抉择 server 不胜利，则始终尝试应用 subRule 的形式抉择一个可用的 server
ZoneAvoidanceRule：依据性能和可用性来抉择。
AvailabilityFilteringRule：过滤掉那些因为始终连贯失败的被标记为 circuit tripped 的后端 server，并过滤掉那些高并发的的后端 server（active connections 超过配置的阈值）
8.Ribbon 是怎么和 Eureka 整合的？
- 首先，Ribbon 会从 Eureka Client 里获取到对应的服务列表。
- 而后，Ribbon 应用负载平衡算法取得应用的服务。
- 最初，Ribbon 调用对应的服务。
9.Feign 实现原理
Feign 的一个要害机制就是应用了动静代理。咱们一起来看看上面的图，联合图来剖析：
- 首先，如果你对某个接口定义了
@FeignClient注解，Feign 就会针对这个接口创立一个动静代理。 - 接着你要是调用那个接口，实质就是会调用 Feign 创立的动静代理，这是外围中的外围。
- Feig n 的动静代理会依据你在接口上的
@RequestMapping等注解，来动静结构出你要申请的服务的地址。 - 最初针对这个地址，发动申请、解析响应。
10.Feign 和 Ribbon 的区别
-
启动类用的注解不同。
- Ribbon 应用的是
@RibbonClient。 - Feign 应用的是
@EnableFeignClients。
- Ribbon 应用的是
-
服务的指定地位不同。
- Ribbon 是在
@RibbonClient注解上设置。 - Feign 则是在定义申明办法的接口中用
@FeignClient注解上设置。
- Ribbon 是在
-
调应用形式不同。
- Ribbon 须要本人构建 Http 申请，模仿 Http 申请而后用 RestTemplate 发送给其余服务，步骤相当繁琐。
- Feign 采应用接口的形式，将须要调应用的其余服务的办法定义成申明办法就可，不须要本人构建 Http 申请。不过要留神的是申明办法的注解、办法签名要和提供服务的办法完全一致。
11.Hystrix 隔离策略？
Hystrix 有两种隔离策略：
- 线程池隔离
- 信号量隔离
理论场景下，应用线程池隔离居多，因为反对超时性能。
12. 什么是 Hystrix 断路器？
Hystrix 断路器通过 HystrixCircuitBreaker 实现。
HystrixCircuitBreaker 有三种状态：
CLOSED：敞开OPEN：关上HALF_OPEN：半开
其中，断路器处于 OPEN 状态时，链路处于 非衰弱 状态，命令执行时，间接调用 回退 逻辑，跳过 失常 逻辑。
HystrixCircuitBreaker 状态变迁如下图：
-
红线 ：初始时，断路器处于
CLOSED状态，链路处于衰弱状态。当满足如下条件，断路器从CLOSED变成OPEN状态：
- 周期 (可配，
HystrixCommandProperties.default_metricsRollingStatisticalWindow = 10000 ms) 内，总申请数超过肯定 量(可配，HystrixCommandProperties.circuitBreakerRequestVolumeThreshold = 20)。
- 周期 (可配，
- 谬误 申请占总申请数超过肯定 比例(可配，
HystrixCommandProperties.circuitBreakerErrorThresholdPercentage = 50%)。 - 绿线 ：断路器处于
OPEN状态，命令执行时，若以后工夫超过断路器 开启 工夫肯定工夫 (HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds = 5000 ms)，断路器变成HALF_OPEN状态， 尝试 调用 失常 逻辑，依据执行是否胜利，关上或敞开 熔断器【蓝线】。
13. 为什么要网关服务？
应用网关服务，咱们实现对立的性能：
- 动静路由
- 灰度公布
- 健康检查
- 限流
- 熔断
- 认证: 如数反对 HMAC, JWT, Basic, OAuth 2.0 等罕用协定
- 鉴权: 权限管制，IP 黑白名单，同样是 OpenResty 的个性
- 可用性
- 高性能
14. 熔断和降级区别
熔断是上层服务一旦产生故障就断掉；降级须要对服务进行分级，把产生故障的服务丢掉，换一个轻量级的计划。
15.springcloud 跟 dubbo 的区别
| Dubbo | SpringCloud | |
|---|---|---|
| 服务注册核心 | Zookeeper | Spring Cloud Netfilx Eureka |
| 服务调用形式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不欠缺 | Spring Cloud Netfilx Hystrix |
| 服务网关 | 无 | Spring Cloud Netfilx Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 音讯总栈 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量工作 | 无 | Spring Cloud Task |
最大区别：SpringCloud 摈弃了 Dubbo 的 RPC 通信，采纳的是基于 HTTP 的 REST 形式。
严格来说，这两种形式各有优劣。尽管从肯定水平上来说，后者就义了服务调用的性能，但也防止了下面提到的原生 RPC 带来的问题。而且 REST 相比 RPC 更为灵便，服务提供方和调用方的依赖只依附一纸契约，不存在代码级别的强依赖，这在强调疾速演变的微服务环境下，显得更加适合。
解决的问题域不一样：Dubbo 的定位是一款 RPC 框架，Spring Cloud 的指标是微服务架构下的一站式解决方案
4.Dubbo 和 SpringCloud 比照
Distributed/versioned configuration（分布式 / 版本控制配置）
Service registration and discovery（服务注册与发现）
Routing（路由）
Service-to-service calls（服务到服务的调用）
Load balancing（负载平衡配置）
Circuit Breakers（断路器）
Distributed messaging（分布式音讯治理）