springcloud的相关面试题

官方解释：
Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等托管平台。

一、微服务的有缺点：

首先是优点：
第一：每个微服务都有足够的内聚，代码相对来说容易理解
第二：开发的效率高，一个服务只做一件事，适合小团队开发
第三：松耦合，有功能意义的服务
第四：就是它可以运用不同语言进行开发，面向接口编程
第五：易于第三方集成
第六：微服务只是业务逻辑代码，不会与HTML和CSS或者其他界面结合
第七：可以灵活搭配，连接公共库或者独立库

然后是缺点：
第一：微服务过多，治理成本高，不利于维护系统
第二：分布式系统开发的成本高（容错，分布式事务等）对团队挑战大
总的来说优点大过于缺点，目前看来SpringCloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud 的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习 Spring Cloud 是一个不错的选择。

二、什么是springcloud：

springcloud流应用程序启动器是基于springboot的spring集成医用程序，提供与外部系统的集成。spring cloud task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序

三、springcloud和dubbo的区别：

1、服务调用的方式：
dubbo是RPC
springcloud Rest API

2、注册中心：
dubbo 是zookeeper
springclod 是eureka 也可以是zookeeper

3、服务网关：

dubbo本身没有实现，只能通过其他第三方技术整合，而springcloud它有一个zuul路由网关，作为路由服务器，进行消费者的请求分发，springcloud支持断路器，与git完美集成配置文件支持版本控制，事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

四、REST和RPC对比：

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

五、所知道的微服务技术栈：

维度（springcloud）
服务开发：spring boot、spring、springmvc
服务配置与管理：Netfix公司的Archaiusm，阿里的Diamond
服务注册与发现：Eureka,Zookeeper
服务调用:Rest RPC gRpc
服务熔断器:Hystrix
服务负载均衡:Ribbon Nginx
服务接口调用:Fegin
消息队列:Kafka Rabbitmq activemq
服务配置中心管理:SpringCloudConfig
服务路由（API网关）Zuul
事件消息总线:SpringCloud Bus

六、负载均衡的意义是什么：

在计算中，负载均衡可以改善跨计算机，计算机集群，网络连接，中央处理单元或者磁盘驱动器等多种计算资源的工作负载分布。负载均衡旨在优化资源使用，最大吞吐量，最小相应时间并避免任何单一资源的过载。使用多个组件进行负载均衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或者域名系统服务进程。

七、服务之间是如何独立通讯的：

1、远程调用，比如feign调用，直接通过远程调用来访问别的service
2、消息中间键。

八、springcloud如何实现服务的注册

1、服务发布时，指定对应的服务名，将服务注册到注册中心（eureka、zookeeper）
2、注册中心加@EnableEurekaServer，服务调用@EnableDiscoveryClient，然后用ribbon或者feign进行服务直接的调用发现

九、eureka和zookeeper的区别：

1、eureka取CAP的AP，注重可用性。zookeeper取CAP的CP注重一致性
2、zookeeper在选举期间注册服务瘫痪，虽然服务最终会恢复，但选举期间不可用。
3、eureka的自我保护机制，会导致一个结果就是不会再从注册列表移除因长时间没收到心跳而过期的服务。依然能接受新服务的注册和查询请求，但不会被同步到其他的节点。不会服务瘫痪。
4、zookeeper有leader和follower角色，eureka各个节点平等。
5、zookeeper采用过半数存活原则，eureka采用自我保护机制解决分区问题。
6、eureka本质是一个工程，zookeeper只是一个进程。

十、eureka的自我保护机制是什么：

当eureka server节点在短时间内丢失了过多实例的连接时（比如网络故障或频繁启动关闭客户端）节点会进入自我保护模式，保护注册信息，不再删除注册数据，故障恢复时，自动退出自我保护模式。

十一、什么是服务熔断，什么是服务降级：

服务熔断：就是说服务直接的调用，比如在高并发的情况下出现进程堵塞，导致当前线程不可用，慢慢的全部线程阻塞，导致服务雪崩
服务降级：相当于保险丝，出现某个异常，直接熔断整个服务，而不是一直等到服务超时。通过维护自己的线程池，当线程到达阈值的时候就启动服务降级，如果其他的请求继续访问就直接返回fallback的默认值。

十二、什么是ribbon：

ribbon是一个负载均衡客户端，可以很好的控制htt和tcp的一些行为。feign默认集成ribbon。

十三、什么是feign，它的优点是什么：

1、feign采用的是基于接口的注解
2、feign整合了ribbon，具有负载均衡的能力
3、整合了hystrix，具有熔断的能力

使用:
1、添加pom依赖
2、启动类添加@EnableFeignClients
3、定义一个接口@FeignClient(name=“xxx”)指定调用哪个服务

十四、ribbon和feign的区别：

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

十五、什么是spring cloud Bus：

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

十六、spring cloud断路器的作用：

当一个服务调用另一个服务由于网络原因或者自身原因出现问题， 调用者就会等待被调用者的相应当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）
断路器有完全打开状态:一段时间内 达到一定的次数无法调用 并且多次监测没有恢复的迹象 断路器完全打开 那么下次请求就不会请求到该服务
半开:短时间内 有恢复迹象 断路器会将部分请求发给该服务，正常调用时 断路器关闭
关闭：当服务一直处于正常状态 能正常调用

十七、什么是springcloudconfig：

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。
使用：
1、添加pom依赖
2、配置文件添加相关配置
3、启动类添加注解@EnableConfigServer

十八.Spring Cloud Gateway：

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。
使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各种过滤器，用来对请求做各种判断和修改。

十九.架构：

在微服务架构中，需要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等，由这几个基础组件相互协作，共同组建了一个简单的微服务系统
在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先经过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），然后再到具体的服。，服务统一注册到高可用的服务注册中心集群，服务的所有的配置文件由配置服务管理，配置服务的配置文件放在git仓库，方便开发人员随时改配置。

二十.什么是Hystrix

防雪崩利器，具备服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）
服务降级:
双十一 提示 哎哟喂，被挤爆了。 app秒杀 网络开小差了，请稍后再试。
优先核心服务，非核心服务不可用或弱可用。通过HystrixCommand注解指定。
fallbackMethod(回退函数)中具体实现降级逻辑。

二十一.为什么要使用微服务：

1.随着互联网的快速发展，各行各业都在用互联网。互联网已经离不开人们的形形色色。随着越来越多的用户，业务场景也愈来愈复杂。
2.传统的单体架构已经很难满足互联网技术发展的要求，代码可维护性扩展性和可读性降低，维护成本的提高都是驱动微服务的发展趋势。

二十二.作为服务注册中心，Eureka比Zookeeper好在哪里：

1.Eureka保证的是可用性和分区容错性，Zookeeper 保证的是一致性和分区容错性 。
2.Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障。而不会像zookeeper那样使整个注册服务瘫痪。

二十三.什么是 Ribbon负载均衡：

1.Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。
2. Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

二十四.Ribbon负载均衡能干什么？

1.将用户的请求平摊的分配到多个服务上
2.集中式LB即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件，如F5, 也可以是软件，如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方；
3.进程内LB将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。

注意： Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

二十五.什么是 zuul路由网关：

1.Zuul 包含了对请求的路由和过滤两个最主要的功能:其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础、
2.Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。
注意： Zuul服务最终还是会注册进Eureka 提供=代理+路由+过滤 三大功能。

二十六.分布式配置中心能干嘛？

1.集中管理配置文件不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release
2.运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
3.当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置将配置信息以REST接口的形式暴露

二十七.微服务的优缺点分别是什么？说下你在项目开发中碰到的坑？

这个问题感觉比较容易问到~~~~

优点:
1.每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求
2.开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
3.微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
4.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
5.微服务能使用不同的语言开发。
6.易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
7.微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
8.微服务允许你利用融合最新技术。
9.微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
10.每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。
缺点:
1.多服务运维难度，随着服务的增加，运维的压力也在增大
2.系统部署依赖
3.服务间通信成本
4.数据一致性
5.系统集成测试
6.性能监控

二十八.什么是微服务？

1.微服务是一种架构模式或是一种架构风格，它提倡的是将单一的应用程序划分成若干个小的服务，每个服务都有独立的进程，服务之间相互协调，相互配合，最终完成目的。
2.服务之间采用轻量级的通信机制，通常是基于HTTP的TESTful API。
3.每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等
4.应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储~
5.微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。