知识背景:
SpringBoot采用默认配置,帮助我们快速的构建和运行Spring项目:
面试话术:
SpringBoot是一个快速构建项目并简化项目配置的工具,内部集成了Tomcat及大多数第三方应用和Spring框架的默认配置。与我们学习的SpringMVC和SpringCloud并无冲突,SpringBoot提供的这些默认配置,大大简化了SpringMVC、SpringCloud等基于Spring的Web应用的开发。
**问题1:**那你说说SpringBoot的自动配置是如何实现的?
面试话术:
一般我们的SpringBoot项目启动类都会添加@SpringBootApplication
注解,而这个注解的其中一个二级注解是@EnableAutoConfiguration
注解。而@EnableAutoConfiguration
注解通过@Import
注解,以ImportSelector
接口的方法来导入classpath下的META-INF/spring.factories
文件,这些文件中会指定需要加载的一些类名称。
这些类一般都加了@Configuration
注解,并且完成了对某框架(例如Redis、SpringMVC)的默认配置,当这些类符合条件时,就会被实例化,其中的配置生效,那么自动配置自然生效了。
问题2:满足怎样的条件配置才会生效?
面试话术:
一般提供默认配置的类都会添加@ConditionalOnXxx
这样的注解,例如:@ConditionalOnClass
,@ConditionalOnProperties
等。@ConditionalOnClass
表示只有classpath中存在某些指定的类时,条件满足,此时该配置类才会生效。例如Redis的默认配置其实早就有了,但是只有你引入redis的starter依赖,才满足了条件,触发自动配置。
问题3:那如果我需要覆盖这些默认配置呢?
有两种方式可以覆盖默认配置:
面试话术:
有,项目中某些中间件的客户端(如Redis、ElasticSearch)会进行二次封装,并通过starter方式提供jar包,供大家使用。
一般定义starter包括下面几个子工程:
我以elasticsearch为例来说说autoconfigure中包含哪些
话术:
SpringBoot项目启动第一步就是创建SpringApplication的实例,并且调用SpringApplication.run()这个方法。
创建SpringApplication实例主要完成三件事情:
而后的run()方法则会创建spring容器,流程如下:
prepareContext()
:初始化ApplicationContext,准备运行环境refreshContext(context)
:准备Bean工厂,调用一个BeanDefinition和BeanFactory的后处理器,初始化各种Bean,初始化tomcatafterRefresh()
:拓展功能,目前为空面试话术:
SpringBoot参数配置方式很多,比较常用参数配置方式按照优先级从高到低分别是:
在命令行中传入的参数
java 的系统属性,可以通过System.getProperties()获得的内容
操作系统的环境变量
针对不同{profile}环境的配置文件内容,例如 applicaiton-{profile}.yaml
application.yml或application.proerties文件
在@Configration注解修改的类中,通过@PropertySource注解定义的属性
聊聊看SpringCloud和Dubbo有什么区别?
面试话术:
两者都是现在主流的微服务框架,但却存在不少差异:
SpringCloud生态丰富,功能完善,更像是品牌机,Dubbo则相对灵活,可定制性强,更像是组装机。
相关资料:
SpringCloud:Spring公司开源的微服务框架,SpirngCloud 定位为微服务架构下的一站式解决方案,生态丰富,功能完善。
Dubbo:阿里巴巴开源的RPC框架,Dubbo 是 SOA 时代的产物,它的关注点主要在于服务的调用,流量分发、流量监控和熔断。
SpringCloudAlibaba
两者的生态对比:
功能 | Dubbo | SpringCloud |
---|---|---|
服务注册中心 | Zookeeper | Eureka(主流)、Consul、zookeeper |
服务调用方式 | RPC基于Dubbo协议 | REST API 基于Http协议 |
服务监控 | Dubbo-Monitor | Spring Boot Admin |
熔断器 | 不完善 | Spring Cloud Netflix Hystrix |
服务网关 | 无 | Spring Cloud Netflix Zuul、Gateway |
分布式配置 | 无 | Spring Cloud Config |
服务跟踪 | 无 | Spring Cloud Sleuth+Zipkin(一般) |
数据流 | 无 | Spring Cloud Stream |
批量任务 | 无 | Spring Cloud Task |
信息总线 | 无 | Spring Cloud Bus |
Spring Cloud 的功能很明显比 Dubbo 更加强大,涵盖面更广,而且作为 Spring 的旗舰项目,它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合,这些对于微服务而言是至关重要的。
使用 Dubbo 构建的微服务架构就像组装电脑,各环节选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果使用者是一名高手,那这些都不是问题。
而 Spring Cloud 就像品牌机,在 Spring Source 的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础原理有足够的了解。
面试话术:
Feign是SpringCloud中的远程调用方式,基于成熟Http协议,所有接口都采用Rest风格。因此接口规范更统一,而且只要符合规范,实现接口的微服务可以采用任意语言或技术开发。但受限于http协议本身的特点,请求和响应格式臃肿,其通信效率相对会差一些。
Dubbo框架默认采用Dubbo自定义通信协议,与Http协议一样底层都是TCP通信。但是Dubbo协议自定义了Java数据序列化和反序列化方式、数据传输格式,因此Dubbo在数据传输性能上会比Http协议要好一些。
不过这种性能差异除非是达极高的并发量级,否则无需过多考虑。
相关资料:
Dubbo采用自定义的Dubbo协议实现远程通信,是一种典型的RPC调用方案,而SpringCloud中使用的Feign是基于Rest风格的调用方式。
1)Rest风格
REST是一种架构风格,指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
Rest的风格可以完全通过HTTP协议实现,使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
因此请求和想要过程只要遵循http协议即可,更加灵活
SpringCloud中的Feign就是Rest风格的调用方式。
2)RPC
Remote Procedure Call,远程过程调用,就是像调用本地方法一样调用远程方法。RPC架构图:
RPC一般要确定下面几件事情:
因为有序列化和反序列化的需求,因此对数据传输格式有严格要求,不如Http灵活
Dubbo协议就是RPC的典型代表。
我们看看Dubbo协议和Feign的调用区别:
Dubbo | Feign(Http调用) | |
---|---|---|
传输协议 | TCP | TCP |
开发语言 | java | 不限 |
性能 | 好 | 一般 |
灵活性 | 一般 | 好 |
面试话术:
SpringCloud和Dubbo都支持多种注册中心,不过目前主流来看SpringCloud用Eureka较多,Dubbo则以Zookeeper为主。两者存在较大的差异:
相关资料:
首先,Eureka和Zookeeper都是服务治理框架,但是设计上有一定的差别。
先看下CAP原则:C-数据一致性;A-服务可用性;P-服务对网络分区故障的容错性,这三个特性在任何分布式系统中不能同时满足,最多同时满足两个。
Eureka满足AP,Zookeeper满足CP
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是Zookeeper和Eureka在一致性与可用性间做出了不同的选择。
Zookeeper
:Zookeeper的设计追求数据的一致性,不保证服务的可用性。当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka
:Eureka追求的是服务的可用性,从而牺牲了数据的一致性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况。
因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。
Eureka集群各节点平等,Zookeeper中有主从之分
Eureka的服务发现需要主动去拉取,Zookeeper服务发现是监听机制
Spring Cloud的子项目很多,比较常见的都是Netflix开源的组件:
Spring Cloud Config
集中配置管理工具,分布式系统中统一的外部配置管理,默认使用Git来存储配置,可以支持客户端配置的刷新及加密、解密操作。
Spring Cloud Netflix
Netflix OSS 开源组件集成,包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。
Spring Cloud Bus
用于传播集群状态变化的消息总线,使用轻量级消息代理链接分布式系统中的节点,可以用来动态刷新集群中的服务配置。
Spring Cloud Consul
基于Hashicorp Consul的服务治理组件。
Spring Cloud Security
安全工具包,对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。
Spring Cloud Sleuth
Spring Cloud应用程序的分布式请求链路跟踪,支持使用Zipkin、HTrace和基于日志(例如ELK)的跟踪。
Spring Cloud Stream
轻量级事件驱动微服务框架,可以使用简单的声明式模型来发送及接收消息,主要实现为Apache Kafka及RabbitMQ。
Spring Cloud Task
用于快速构建短暂、有限数据处理任务的微服务框架,用于向应用中添加功能性和非功能性的特性。
Spring Cloud Zookeeper
基于Apache Zookeeper的服务治理组件。
Spring Cloud Gateway
API网关组件,对请求提供路由及过滤功能。
Spring Cloud OpenFeign
基于Ribbon和Hystrix的声明式服务调用组件,可以动态创建基于Spring MVC注解的接口实现用于服务调用,在Spring Cloud 2.0中已经取代Feign成为了一等公民。
面试话术:
企业中对于微服务监控有一套东西,叫做APM。比如:SpringCloudSeluth+Zipkin,Pinpoint、Skywalking,可以实现性能监控、链路跟踪(精确到某个代码,某条sql)、CPU运行情况,链路运行耗时。
当然, 还可以借助于分布式日志管理系统。把项目运行的日志收集,形成统计报表,放入elasticsearch,便于搜索查看。比如:ELK技术栈、GrayLog
话术:
Hystix是Netflix开源的一个延迟和容错库,用于隔离访问远程服务、第三方库,防止出现级联失败。比较常用的手段就是线程隔离和服务熔断。
资料:
在大中型分布式系统中,微服务间调用关系复杂,可能业务会调用多个其它服务,
在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢,资源繁忙,暂时不可用,服务脱机等.
如下图:依赖 I 出现不可用,但是其他依赖仍然可用.访问服务A或H的不会有问题,但是访问服务I的请求会阻塞。
当依赖I 阻塞时,当前服务接收的请求会越来越多被阻塞,直到当前tomcat资源被耗尽,没有更多线程可用,导致整个服务崩溃。
解读:
Hystrix为每个依赖服务调用分配一个小的线程池,如果线程池已满调用将被立即拒绝,默认不采用排队.加速失败判定时间。
用户的请求将不再直接访问服务,而是通过线程池中的空闲线程来访问服务,如果线程池已满,或者请求超时,则会进行降级处理,执行fallback(降级)逻辑
尽管隔离可以避免服务出现级联失败,但是对于访问**服务I(异常服务)**的其它服务,每次处理请求都要等待数秒直至fallback,显然是对系统资源的浪费。
因此,当Hystix判断一个依赖服务失败比例较高时,就会对其做熔断处理,快速失败,不再阻塞等待。
Hystix的熔断状态机模型:
状态机有3个状态: