SpringCloud 经典面试问题

一.SpringCloud和Dubbo

SpringCloud和Dubbo都是现在主流的微服务架构
SpringCloud是Apache旗下的Spring体系下的微服务解决方案
Dubbo是阿里系的分布式服务治理框架
从技术维度上,其实SpringCloud远远的超过Dubbo,Dubbo本身只是实现了服务治理,而SpringCloud现在以及有21个子项目以后还会更多
所以其实很多人都会说Dubbo和SpringCloud是不公平的
但是由于RPC以及注册中心元数据等原因,在技术选型的时候我们只能二者选其一,所以我们常常为用他俩来对比
服务的调用方式Dubbo使用的是RPC远程调用,而SpringCloud使用的是 Rest API,其实更符合微服务官方的定义
服务的注册中心来看,Dubbo使用了第三方的ZooKeeper作为其底层的注册中心,实现服务的注册和发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,当然SpringCloud也可以使用ZooKeeper实现,但一般我们不会这样做
服务网关,Dubbo并没有本身的实现,只能通过其他第三方技术的整合,而SpringCloud有Zuul路由网关,作为路由服务器,进行消费者的请求分发,SpringCloud还支持断路器,与git完美集成分布式配置文件支持版本控制,事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素

二.技术选型

目前国内的分布式系统选型主要还是Dubbo毕竟国产,而且国内工程师的技术熟练程度高,并且Dubbo在其他维度上的缺陷可以由其他第三方框架进行集成进行弥补
而SpringCloud目前是国外比较流行,当然我觉得国内的市场也会慢慢的偏向SpringCloud,就连刘军作为Dubbo重启的负责人也发表过观点,Dubbo的发展方向是积极适应SpringCloud生态,并不是起冲突

三.Rest和RPC对比

其实如果仔细阅读过微服务提出者马丁福勒的论文的话可以发现其定义的服务间通信机制就是Http Rest
RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强,我们需要为每一个微服务进行接口的定义,并通过持续继承发布,需要严格的版本控制才不会出现服务提供和调用之间因为版本不同而产生的冲突
而REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,只是通过一个约定进行规范,但也有可能出现文档和接口不一致而导致的服务集成问题,但可以通过swagger工具整合,是代码和文档一体化解决,所以REST在分布式环境下比RPC更加灵活
这也是为什么当当网的DubboX在对Dubbo的增强中增加了对REST的支持的原因

四.文档质量和社区活跃度

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

五.SpringBoot和SpringCloud

SpringBoot是Spring推出用于解决传统框架配置文件冗余,装配组件繁杂的基于Maven的解决方案,旨在快速搭建单个微服务
而SpringCloud专注于解决各个微服务之间的协调与配置,服务之间的通信,熔断,负载均衡等,技术维度并相同,并且SpringCloud是依赖于SpringBoot的,而SpringBoot并不是依赖与SpringCloud,甚至还可以和Dubbo进行优秀的整合开发

总结:

SpringBoot专注于快速方便的开发单个个体的微服务
SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,
配置管理,服务发现,断路器,路由,事件总线等集成服务
SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系
SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架

六.Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别

1.ZooKeeper保证的是CP,Eureka保证的是AP

ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的
Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的

自我保护机制会导致：

Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)
当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统瘫痪

2.ZooKeeper有Leader和Follower角色,Eureka各个节点平等
3.ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
4.Eureka本质上是一个工程,而ZooKeeper只是一个进程

七.微服务之间是如何独立通讯的

微服务通信机制
系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。
围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的去集中化控制。

将组件定义为可被独立替换和升级的软件单元。
以业务能力为出发点组织服务的策略。
倡导谁开发，谁运营的开发运维一体化方法。
RESTful HTTP协议是微服务架构中最常用的通讯机制。
每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。
允许不同微服务采用不同的数据持久化技术。
微服务非常重视建立架构及业务相关指标的实时监控和日志机制，必须考虑每个服务的失败容错机制。
注重快速更新，因此系统会随时间不断变化及演进。可替代性模块化设计。

微服务通信方式：

同步：RPC，REST等

异步：消息队列。要考虑消息可靠传输、高性能，以及编程模型的变化等。

消息队列中间件如何选型

    1.协议：AMQP、STOMP、MQTT、私有协议等。
    2.消息是否需要持久化。
    3.吞吐量。
    4.高可用支持，是否单点。
    5.分布式扩展能力。
    6.消息堆积能力和重放能力。
    7.开发便捷，易于维护。
    8.社区成熟度。

RabbitMQ是一个实现了AMQP(高级消息队列协议)协议的消息队列中间件。RabbitMQ支持其中的最多一次和最少一次两种。网易蜂巢平台的服务架构，服务间通过RabbitMQ实现通信。

八.什么是服务熔断?什么是服务降级

   在复杂的分布式系统中,微服务之间的相互调用,有可能出现各种各样的原因导致服务的阻塞,在高并发场景下,服务的
   阻塞意味着线程的阻塞,导致当前线程不可用,服务器的线程全部阻塞,导致服务器崩溃,由于服务之间的调用关系是同
   步的,会对整个微服务系统造成服务雪崩，为了解决某个微服务的调用响应时间过长或者不可用进而占用越来越多的
   系统资源引起雪崩效应就需要进行服务熔断和服务降级处理。
  

  所谓的服务熔断指的是某个服务故障或异常一起类似显示世界中的“保险丝"当某个异常条件被触发就直接
  熔断整个服务，而不是一直等到此服务超时。

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

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

**优点**
    每一个服务足够内聚,代码容易理解
    开发效率提高,一个服务只做一件事
    微服务能够被小团队单独开发
    微服务是松耦合的,是有功能意义的服务
    可以用不同的语言开发,面向接口编程
    易于与第三方集成
    微服务只是业务逻辑的代码,不会和HTML,CSS或者其他界面组合
        开发中,两种开发模式
            前后端分离
            全栈工程师
    可以灵活搭配,连接公共库/连接独立库
    
**缺点**
    分布式系统的负责性
    多服务运维难度,随着服务的增加,运维的压力也在增大
    系统部署依赖
    服务间通信成本
    数据一致性
    系统集成测试
    性能监控

十.你所知道的微服务技术栈有哪些?请列举一二

多种技术的集合体
我们在讨论一个分布式的微服务架构的话,需要哪些维度

维度(SpringCloud)
    服务开发
        SpringBoot
        Spring
        SpringMVC
    服务配置与管理
        Netfilx公司的Archaiusm,阿里的Diamond
    服务注册与发现
        Eureka,ZooKeeper
    服务调用
        Rest,RPC,gRPC
    服务熔断器
        Hystrix
    服务负载均衡
        Ribbon,Nginx
    服务接口调用
        Feign
    消息队列
        Kafka,RabbitMq,ActiveMq
    服务配置中心管理
        SpringCloudConfing
    服务路由(API网关)
        Zuul
    事件消息总线
        SpringCloud Bus

十一、Eureka自我保护机制

接着以上篇文章建立的三个工程为基础（eureka-server,uerreg,myweb）,默认Eureka是开启自我保护的。我们来做个测试，我们先启动三个工程，我们访问注册中心http://localhost:8761/,

可以看到，实例是成功注册到中心的。此时我们将uerreg服务关闭，刷新注册中心，我们会发现如下界面

我们除了看到了一行红色的警告信息，还发现了一件神奇的事情，就是我们的服务实例虽然被kill了，但是在服务注册中心他还是存在的。这就是Eureka自我保护机制，他不会剔除已经挂掉的服务，他会认为这个服务是在尝试重新连接的。
我们在开发过程中肯定是不希望这样的，不利于开发。我们可以关闭Eureka的自我保护机制（实际生产环境不建议关闭）。

eureka-server服务端
配置文件中我们添加如下配置

#关闭保护机制，以确保注册中心将不可用的实例正确剔除
eureka.server.enable-self-preservation=false
#（代表是5秒，单位是毫秒,清理失效服务的间隔 ）
eureka.server.eviction-interval-timer-in-ms=5000

userreg客户端
配置文件中我们添加如下配置

# 心跳检测检测与续约时间
# 测试时将值设置设置小些，保证服务关闭后注册中心能及时踢出服务
# 配置说明
#　　lease-renewal-interval-in-seconds 每间隔10s，向服务端发送一次心跳，证明自己依然”存活“
#　　lease-expiration-duration-in-seconds  告诉服务端，如果我20s之内没有给你发心跳，就代表我“死”了，
将我踢出掉。
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.instance.lease-expiration-duration-in-seconds=20

我们重新启动服务，然后关闭userreg客户端进行测试。

此时我们发现，红色警告变成了自我保护被关闭的警告，且实例被注册中心剔除，表明此时自我保护机制被关闭。

十二、Eureka健康检查

健康检查在实际应用场景中有哪些呢？举个例子，我们配置userreg工程数据源
在pom文件中引入以下依赖

...
 <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>
...

然后建立一个配置类，配置数据源DataSource

@Configuration
public class Myconfig {
   @Bean
   public DataSource dataSource()
   {
       org.apache.tomcat.jdbc.pool.DataSource dataSource=new org.apache.tomcat.jdbc.pool.DataSource();
       dataSource.setUrl("jdbc:mysql://localhost/test?characterEncoding=UTF-8");
       dataSource.setUsername("root");
       dataSource.setPassword("mysql");
       dataSource.setDriverClassName("com.mysql.jdbc.Driver");
       return dataSource;
   }
}

这个在springboot中已经学习过，后续我会把springboot学习过程以博客的方式记录下来，配置完成数据源之后，我们启动服务，访问http://localhost:9001/admin/health 查看健康情况

我们可以看到db的健康情况。假如此时我们的mysql服务挂掉，会怎样呢？

我们手动停止mysql服务，然后再看健康情况

原文链接：https://blog.csdn.net/jerryDzan/article/details/89137818