SpringCloud面试题

以下为关于SringCloud常见的面试题：持续更新中

1、 什么是微服务？

微服务是近几年流行的一种架构思想，就目前而言，对于微服务没有一个统一的，标准的定义。微服务架构是一种架构模式，或者说是一种架构风格，他将单一的应用程序划分为一组小的服务（模块化），每个服务运行在其独立的进程内，服务之间相互协调，相互配置，为用户提供最终价值，服务之间采用轻量级的通信机制（HTTP）相互沟通，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中。

微服务的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，彻底的去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或者销毁，拥有自己独立的数据库。

2、 微服务的优缺点？

优点：

• 单一职责原则
• 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求
• 开发简单，开发效率高，一个服务可能就是专一的干一件事
• 微服务能够被小团队单独开发，只需要2-5个人组成
• 微服务是去耦合的，是有功能意义的服务，无论是在开发阶段或者部署阶段都是独立的
• 能使用不同的语言开发
• 容易和第三方集成
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值
• 微服务允许利用和融合最新技术
• 微服务只是业务逻辑的代码，不会和前端html,css或者其他的界面混合
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库

缺点：

• 开发人员要处理分布式系统的复杂性
• 多服务运维难度大，随着服务的增加，运维的压力也在增大
• 系统部署依赖问题
• 服务间通信成本问题
• 数据一致性问题
• 系统集成测试问题
• 性能和监控问题

3、 微服务之间是如何独立通讯的？

远程过程度调用(Remove Procedure Invocation): 就是服务的注册与发现，直接通过远程过程调用来访问别的service

优点：简单常见，因为没有中间件代理，系统更简单

缺点：只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应 ，这就降低了可用性

消息：使用异步消息来做服务间通信，服务间通过消息管道来交换消息，从而通信

优点：

• 把客户端和服务端解耦，更松耦合
• 提高可用性，因为消息中间件缓存了消息，直到消费者可以消费
• 支持很多通信机制，比如通知、请求/异步响应、发布/订阅、发布/异步响应

缺点：消息中间件有额外的复杂

4、 你所知道的微服务技术栈有哪些？列举一二

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

微服务技术条目	落地技术
服务开发	SpringBoot、Spring、SpringMVC等
服务配置与管理	Netfix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zookeeper等
服务调用	Rest、PRC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用(客户端调用服务的简化工具)	Fegin等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	SpringCloudConfig、Chef等
服务路由(API网关)	Zuul等
服务监控	Zabbix、Nagios、Metrics、Specatator等
全链路追踪	Zipkin、Brave、Dapper等
数据流操作开发包	SpringCloud Stream(封装与Redis，Rabbit，Kafka等发送接收消息)
时间消息总栈	SpringCloud Bus
服务部署	Docker、OpenStack、Kubernetes等

5、 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抛弃了Dubbb的RPC通信，采用的是Http的REST方式

Rest和RPC对比：严格来说，这两种方式各有优劣，虽然从一定程度上说，Rest牺牲了服务调用的性能，但也避免了原生RPC带来的问题，而且REST相比RPC更为灵活，服务提供方和调用方只依靠一纸契约，不存在代码级别的强依赖，这个有点在当下强调快速演化的微服务环境下，显得更为合适。

文档质量和社区活跃度对比：SpringCloud社区活跃度远高于Dubbo,毕竟由于梁飞团队的原因导致Dubbo停止更新迭代五年,而中小型公司无法承担技术开发的成本导致Dubbo社区严重低落,而SpringCloud异军突起,迅速占领了微服务的市场,背靠Spring混的风生水起
Dubbo经过多年的积累文档相当成熟,对于微服务的架构体系各个公司也有稳定的现状

品牌机和组装机的区别：Dubbo是组装机，SpringCloud是品牌机

总结：二者解决的问题领域不一样，Dubbo的定位是一款RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案。

6、 SpringBoot 和 SpringCloud，请谈谈你对他们的理解

• SpringBoot专注于快速方便的开发单个个体微服务（打jar包）
• SpringCloud是关注去全局的微服务协调整理治理框架，他将SpringBoot开发的一个个单体微服务，整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，为代理，事件总栈，全局锁，决策竞选，分布式会话等等集成服务。
• SpringBoot可以离开SpringCloud独立使用，开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系
• SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注全局的微服务治理框架

7、 什么是服务熔断？什么是服务降级？

（1）服务熔断：

（保险丝）熔断机制是对应雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息，检测到该节点微服务调用响应下正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是：@HystrixCommand

服务熔断解决如下问题：

• 当所依赖的对象不稳定时，能够起到快速失败的目的；
• 快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复。

（2）服务降级：

服务降级是指 当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理，或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。说白了，就是尽可能的把系统资源让给优先级高的服务。

资源有限，而请求是无限的。如果在并发高峰期，不做服务降级处理，一方面肯定会影响整体服务的性能，严重的话可能会导致宕机某些重要的服务不可用。所以，一般在高峰期，为了保证核心功能服务的可用性，都要对某些服务降级处理。比如当双11活动时，把交易无关的服务统统降级，如查看蚂蚁森林，查看历史订单等等。

服务降级需要考虑的问题

• 1）哪些服务是核心服务，哪些服务是非核心服务
• 2）哪些服务可以支持降级，哪些服务不能支持降级，降级策略是什么
• 3）除服务降级之外是否存在更复杂的业务放通场景，策略是什么

（3）服务熔断和降级的区别(重要)

• 服务熔断—>服务端：某个服务超时或异常，引起熔断~，类似于保险丝(自我熔断)
• 服务降级—>客户端：从整体网站请求负载考虑，当某个服务熔断或者关闭之后，服务将不再被调用，此时在客户端，我们可以准备一个 FallBackFactory ，返回一个默认的值(缺省值)。会导致整体的服务下降，但是好歹能用，比直接挂掉强。
• 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
• 实现方式不太一样，服务降级具有代码侵入性(由控制器完成/或自动降级)，熔断一般称为自我熔断。

熔断，降级，限流：

限流：限制并发的请求访问量，超过阈值则拒绝；

降级：服务分优先级，牺牲非核心服务（不可用），保证核心服务稳定；从整体负荷考虑；

熔断：依赖的下游服务故障触发熔断，避免引发本系统崩溃；系统自动执行和恢复

8、 Eureka和Zookeeper都可以提供服务注册与发现的功能，请说说两者的区别

 回顾CAP原则

RDBMS (MySQL\Oracle\sqlServer) ===> ACID

NoSQL (Redis\MongoDB) ===> CAP

ACID是什么？（orcal mysql等数据库的性质）

• A (Atomicity) 原子性
• C (Consistency) 一致性
• I (Isolation) 隔离性
• D (Durability) 持久性

CAP是什么?

• C (Consistency) 强一致性（保证数据的一致性）
• A (Availability) 可用性
• P (Partition tolerance) 分区容错性

CAP的三进二：要么CA、要么AP、要么CP（无法保证该三个性质都满足）

CAP原则的核心

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
• 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类
  • CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
  • CP：满足一致性，分区容错的系统，通常性能不是特别高
  • AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些

 

作为分布式服务注册中心，Eureka比Zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)，由于分区容错性P在分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。

• Zookeeper 保证的是 CP —> 满足一致性，分区容错的系统，通常性能不是特别高
• Eureka 保证的是 AP —> 满足可用性，分区容错的系统，通常可能对一致性要求低一些

Zookeeper保证的是CP（一致性，容错性，可用性差）

​ 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接收服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30-120s，且选举期间整个zookeeper集群是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件，虽然服务最终能够恢复，但是，漫长的选举时间导致注册长期不可用，是不可容忍的。

Eureka保证的是AP（可用性，容错性，一致性差）

​ Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有之中自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

• Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
• Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)
• 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

9、什么是Zull？Zull能干嘛?

Zull是路由网关，Zull包含了对请求的路由和过滤两个主要功能。