1.什么是Spring Cloud

这个可以从我们服务的一个演变过程来说起：单体->集群->soa->微服务，而微服务它只是一种架构思想，我们为了实现这种思想，就需要技术落地，而springcloud就应运而生，他是一个用来治理微服务的框架，单个服务的实现就要用到SpringBoot。SpringCloud里面有几个比较重要的组件 Eureka 注册中心 、zuul网关、config配置中心、feign服务与服务之间的调用、ribbon负载均衡

2.什么是微服务

微服务是一种架构思想，随着单体项目的不断更新迭代，包含的业务功能代码越来越多，导致编译部署困难等问题，因此以业务功能作为边界将一个完整服务拆分成多个可以独立开发运维部署的子服务。

优点:
1.每个服务直接足够内聚，代码容易理解
2.开发效率高，一个服务只做一件事，适合小团队开发
3.松耦合，有功能意义的服务。
4.可以用不同语言开发，面向接口编程。
5.易于第三方集成
6.微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面结合.
7.可以灵活搭配，连接公共库/连接独立库
缺点:
1.分布式系统的责任性
2.多服务运维难度加大。
3.系统部署依赖，服务间通信成本，数据一致性，系统集成测试，性能监控。

3.服务注册和发现

随着我们服务的增多，为了方便统一管理微服务的通信地址，就有了服务的注册和发现；
微服务在启动的时候会向注册中心提交自己的通信地址清单如:服务名,ip,端口，在注册中心会形成一个微服务的通信地址列表 --- 这叫服务注册
微服务会定期的从注册中心拉取一份微服务通信地址列表缓存到本地。一个微服务在向另一个微服务发起调用的时候会根据目标服务的服务名找到其通信地址清单，然后基于HTTP协议向目标服务发起请求。---这叫服务发现

4.SpringBoot和SpringCloud的区别

SpringBoot专注于快速方便的开发单个个体微服务。SpringCloud关注的是服务与服务之间的一个协调，它将SpringBoot开发的一个个单体微服务整合并管理起来。
SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系.

5.Spring Cloud 和dubbo区别

服务调用方式 dubbo是RPC springcloud Rest Api
注册中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper
服务网关,dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。
模型定义：dubbo将一个接口定义为一个服务，SpringCloud将一个应用定义为一个服务

6.REST和RPC对比

1.RPC主要的缺陷是服务提供方和调用方式之间的依赖太强，需要对每一个微服务进行接口的定义，并通过持续继承发布，严格版本控制才不会出现冲突。
2.REST是轻量级的接口，服务的提供和调用不存在代码之间的耦合，只需要一个约定进行规范。

说说Eureka的自我保护机制？

当一个服务未按时进行心跳续约时，在生产环境下，因为网络延迟等原因，此时就把服务剔除列表并不妥当，因为服务可能没有宕机。 Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。但是有可能会造成一些挂掉的服务被剔除有延迟。

Eureka和ZooKeeper的区别？

1、ZooKeeper中的节点服务挂了就要选举，在选举期间注册服务瘫痪，虽然服务最终会恢复，但是选举期间不可用的， 选举就是该微服务做了集群，必须有一台主其他的都是从。
2、Eureka各个节点是平等关系，服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。 如果查询到的数据并不是最新的，就是因为Eureka的自我保护模式导致的。
3、Eureka本质上是一个工程，而ZooKeeper只是一个进程。
4、Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像ZooKeeper 一样使得整个注册系统瘫痪。
5、ZooKeeper保证的是CP，Eureka保证的是AP

CAP解释：
C：一致性Consistency （取舍:强一致性、单调一致性、会话一致性、最终一致性、弱一致性）
A：可用性 Availability
P：分区容错性Partition tolerance

7.负载均衡的意义

通俗易懂的理解：
集群：是把一个的事情交给多个人去做，假如要做1000个产品给一个人做要10天，叫10个人做就是一天；
负载均衡：用来控制集群，优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载，可以使多个组件达到负载平衡。
在SpringCloud里面可以使用ribbon来实现负载均衡（feign默认集成了ribbon）。

常见的几种Ribbon的负载均衡策略

轮询 :将所有的请求均匀分配
权重 :对性能较好的后端服务器设置较高的权重，承担更多的链接负载。
随机Random:将请求随机分配
hash:通过ip url等信息计算hash值，相同的请求会请求到同一个后端服务器中

8.什么是Hystrix

在分布式系统，我们一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪崩，Hystrix就是这样一个保证服务健壮性的工具，防雪崩利器，它具有服务降级，服务熔断，服务隔离，监控等一些防止雪崩的技术。
Hystrix有四种防雪崩方式：
服务降级：接口调用失败就调用本地的方法返回一个空
服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息
服务隔离：隔离服务之间相互影响
服务监控：在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。

9.什么是服务熔断和服务降级

服务熔断：
熔断机制是应对雪崩效应的一种微服务链路保护机制。
当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。
在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。
服务降级：
服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。

10.什么是服务雪崩效应?

雪崩效应是在大型互联网项目中，当某个服务发生宕机时，调用这个服务的其他服务也会发生宕机，大型项目的微服务之间的调用是互通的，这样就会将服务的不可用逐步扩大到各个其他服务中，从而使整个项目的服务宕机崩溃。

11.什么是feigin

feign是用来处理我们服务与服务之间调用的，它整合了ribbon，具有负载均衡的能力，同时也整合了Hystrix，具有熔断的能力

12.Ribbon和Feign的区别

1.Ribbon都是调用其他服务的，但方式不同。
2.启动类注解不同，Ribbon是@RibbonClient，feign的是@EnableFeignClients
3.服务指定的位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
4.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。Feign需要将调用的方法定义成抽象方法即可。

13.什么是SpringCloud Bus

spring cloud bus 将分布式的节点用轻量的消息代理连接起来，它可以用于广播配置文件的更改或者服务直接的通讯，也可用于监控。
如果修改了配置文件，发送一次请求，所有的客户端便会重新读取配置文件。

14.springcloud断路器

当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应 当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）。底层服务出现故障可能导致用户级联故障。当调用特定服务达到一定阈值时（Hystrix中的默认值为5秒内的20次故障），电路打开，不进行通话。在开路的情况下，可以使用备用的方法进行处理。

断路器有完全打开状态:一段时间内 达到一定的次数无法调用 并且多次监测没有恢复的迹象 断路器完全打开 那么下次请求就不会请求到该服务
半开:短时间内 有恢复迹象 断路器会将部分请求发给该服务，正常调用时 断路器关闭
关闭：当服务一直处于正常状态 能正常调用

15.什么是SpringCloud Config

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。

16.什么是zuul?

zuul是SpringCloud提供的路由方案，他会根据请求的路径不同，网关会定位到指定的微服务，并代理请求到不同的微服务接口，他对外隐蔽了微服务的真正接口地址。

zuul的工作流程?

在Spring Cloud Netflix中，Zuul巧妙的整合了Eureka来实现面向服务的路由。
实际上，API网关将自己注册到Eureka服务注册中心上，也会从注册中心获取所有服务以及它们的实例清单。在Eureka的帮助下，API网关已经维护了系统中所有serviceId与实例地址的映射关系。当有外部请求到达API网关的时候，根据请求的URL找到最匹配的path，API网关就可以知道要将该请求"路由"到哪个具体的serviceId上去。 最终通过Ribbon的负载均衡策略实现请求的路由。

17.什么是SpringCloud Gateway
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。