SpringCloud --- 常见面试题

1、常见面试题

（1）什么是微服务

1. 每个微服务可独立运行在自己的进程里；
2. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；
3. 微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

（2）微服务之间是如何独立通讯的

• REST：（JAX-RS，Spring Boot）

REST 请求在微服务中是最为常用的一种通讯方式, 它依赖于 HTTP\HTTPS 协议。RESTFUL 的特点是：

1. 每一个 URI 代表 1 种资源
2. 客户端使用 GET、POST、PUT、DELETE 4 个表示操作方式的动词对服务端资源进行操作: GET 用来获取资源, POST 用来新建资源(也可以用于更新资源), PUT 用来更新资源, DELETE 用来删除资源
3. 通过操作资源的表现形式来操作资源
4. 资源的表现形式是 XML 或者 HTML
5. 客户端与服务端之间的交互在请求之间是无状态的,从客户端到服务端的每个请求都必须包含理解请求所必需的信息

• RPC（Remote Procedure Call）远程过程调用：（Thrift, Dubbo）

也就是我们常说的服务的注册与发现；简单的理解是一个节点请求另一个节点提供的服务。

优点：

​ 简单，常见,因为没有中间件代理，系统更简单

缺点：

​ 只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应

​ 降低了可用性，因为客户端和服务端在请求过程中必须都是可用的

RPC和REST区别：

RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强，我们需要为每一个微服务进行接口的定义，需要严格的版本控制才不会出现服务提供和调用之间因为版本不同而产生的冲突。
而REST是轻量级的接口，服务的提供和调用不存在代码之间的耦合，只是通过一个约定进行规范，但也有可能出现文档和接口不一致而导致的服务集成问题，但可以通过swagger工具整合,是代码和文档一体化解决,所以REST在分布式环境下比RPC更加灵活

• 异步消息调用：使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。(Kafka, Notify)

优点:

​ 提高可用性，因为消息中间件缓存了消息，直到消费者可以消费

​ 支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应

缺点:

​ 消息中间件有额外的复杂

（3）SpringCloud和Dubbo有哪些区别

• SpringCloud：Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。
• Dubbo：阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断

• 服务的调用方式Dubbo使用的是RPC远程调用，而SpringCloud使用的是 Rest API

（4）SpringBoot和SpringCloud，谈谈你对他的理解

• SpringBoot不依赖于SpringCloud，可以和Dubbo进行优秀的整合开发；SpringCloud依赖于SpringBoot，属于依赖关系
• SpringBoot专注于快速，方便的开发单个的微服务个体，SpringCloud关注全局的服务治理框架

（5）什么是服务熔断？什么是服务降级？

• 服务熔断：相当于我们电闸的保险丝，一旦发生服务雪崩的，就会熔断整个服务，通过维护一个自己的线程池
• 服务降级：当线程达到阈值的时候就启动服务降级，如果其他请求继续访问就直接返回fallback的默认值

（6）微服务的优缺点分别是什么

优点：

• 易于开发和维护
  • 由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护
• 局部修改容易部署
  • 在开发中发现了一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间
• 启动较快
  • 这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的

缺点：

• 运维要求较高
  • 对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。
• 分布式的复杂性
  • 对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来

（7）你所知道的微服务技术栈有哪些？

1）Eureka或Nacos：服务注册发现。

• Eurake客户端：负责将这个服务的信息注册到Eureka服务端中
• Eureka服务端：相当于一个注册中心，里面有注册表，注册表中保存了各个服务所在的机器和端口号，可以通过Eureka服务端找到各个服务

2）Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。

• 首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
• 接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
• Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
• 最后针对这个地址，发起请求、解析响应

3）Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。

• 使用的负载均衡算法是轮询算法，Ribbon会从Eureka服务端中获取到对应的服务注册表，然后就知道相应服务的位置，然后Ribbon根据设计的负载均衡算法去选择一台机器

• ribbon有7种负载均衡策略可供选择：

4）Hystrix：熔断器；提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。

• 订单服务在一个业务流程里需要调用三个服务，现在假设订单服务自己最多只有100个线程可以处理请求，如果积分服务出错，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。
• 如果系统在高并发的情况下，大量请求涌过来的时候，订单服务的100个线程会卡在积分服务这块，导致订单服务没有一个多余的线程可以处理请求，这种问题就是微服务架构中恐怖的服务器雪崩问题

• 即使积分服务挂了，那订单服务也不应该挂掉啊，我们只要让存储服务和仓储服务正常工作就可以了。
• 积分服务挂了，那我们请求积分服务直接就返回了，不需要等待超时时间结束抛出异常，这就是所谓的熔断。
• 每次调用积分服务就在数据库里记录一条异常消息，这就是所谓的降级
• Hystrix隔离、熔断和降级的全流程如下：

5）Zuul或Gateway：网关管理，由 Zuul 网关转发请求给对应的服务。

• 如果前端调用后台系统，统一走zull网关进入，通过zull网关转发请求给对应的服务

（8）eureka和zookeeper都可以提供服务注册与发现的功能，请说说他们的区别

一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP

• Zookeeper保证CP

Zookeeper采用CP保证数据的一致性的问题，原理是采用ZAB原子广播协议。当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，整个选举的过程中为了保证数据一致性的问题，整个微服务无法实现通讯（本地有缓存除外）。还有可运行的节点必须满足过半机制，整个zk才可以使用，要不然会奔溃。

• Eureka保证AP

Eureka采用AP设计理念架构注册中心，相互注册（你中有我，我中有你），完全去中心化，也就是没有主从之分，只要有一台Eureka节点存在整个微服务就可以实现通讯。只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

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

• Nacos选择Ap和CP混合形式实现注册中心