柚子茶1990

java-微服务相关面试题

微服务部分

SpringCloud

讲一下你们公司微服务解决方案

我司正在使用的是第一代微服务方案，Springcloud Netflix全家桶。

它是使用Eureka做服务注册与发现，也就是解决服务之间通信问题，

使用Ribbon/OpenFeign做客户端的负载均衡，也就是解决将请求路由到微服务集群的问题，

使用Hystrix断路器的熔断、降级来解决单节点故障，

使用Zuul做服务网关，将它作为整个微服务的大门，来实现登录、权限检查等业务，

使用Config分布式配置中心，来统一管理配置所有微服务的配置文件，

使用Bus消息总线给各个微服务广播消息，可以实现各个微服务配置的自动刷新，

使用Sleuth链路追踪，来实时监控各个微服务建的调用关系，快速定位故障节点

说一说Spring Cloud有哪些常用组件

Eureka：做服务注册与发现，用来解决服务之间通信问题，

Ribbon/OpenFeign：用做客户端的负载均衡，也就是解决将请求路由到微服务集群的问题，

Hystrix：断路器，它的熔断、降级策略用来解决单节点故障，

Zuul：做服务网关，它是整个微服务的大门，可以用来实现登录、权限检查等业务，

Config：分布式配置中心，用来统一管理配置所有微服务的配置文件，

Bus：消息总线，用来给各个微服务广播消息，可以实现各个微服务配置的自动刷新，

Sleuth：链路追踪，用来实时监控各个微服务建的调用关系，快速定位故障节点

Spring Cloud的优缺点？

微服务相对单体应用来说

优点

服务之间无耦合，代码简单方便开发维护，服务之间升级维护互不影响
轻量级HTTP通信机制，不同的服务可以采用不同的编程语言
有极强的扩展能力,业务量大的服务可以再次拆分服务，或者也可以集群部署
支持时下流行的敏捷开发并做了优化

缺点

分布式事务繁琐
部署麻烦，开发人员的学习成本高
技术成本高，开发人员需要花更多的时间学习相关技术
微服务间的通信存在对性能的损耗问题

什么是服务注册

Eureka是一个服务组测与发现的组件，翻译成人话就是管理所有微服务的通讯录的组件。它包含注册中心，客户端两部分组成。客户端在启动的时候会向注册中心发送一条自我介绍信息，比如端口，ip等等，在注册中心就会保存一张所有微服务的通讯录。这就叫服务注册

什么是服务发现

微服务会定期的从客户端拉取一份微服务通讯录，到本地缓存起来，默认是30s一次。当一个微服务向另一个微服务发起调用，直接根据本地的通讯录找到对方的服务名，发送HTTP请求。这个就叫服务发现

什么是服务续约

微服务会定时（默认30s）发送心跳请求，告诉注册中心，自己还处于存活状态，那么服务中心就不会将其从清单中删除，否则，当微服务宕机或者网络故障等因素，没有在规定时间（默认90s）内提交心跳请求，注册中心就会将它从通讯录中删除。

如果服务挂了，注册中心要等到90s后剔除，那么在剔除前的这段时间内，挂掉的服务有可能还是会被调用，怎么处理？

第一，可以修改注册中心剔除服务时间，同时加快服务续约心跳请求的频率

第二，可以使用Hystrix的熔断降级机制，当某个服务不可访问，快速失败，并返回托底数据

第三。重试,提供者集群

你知道EurekaClient服务发现和服务续约每隔30s做一次请求是用什么技术实现的吗？

使用了ScheduledThreadPoolExecutor线程池定时任务来实现

服务发现是先判断是否开启了服务发现功能（默认是开启的），获取定时任务的间隔时间（默认是30s），然后初始化服务发现的定时任务，间隔时间可以在yml中修改

服务续约是先判断是否开启服务注册功能（默认是开启的），获取定时任务间隔时间（默认是30s），然后初始化心跳请求的定时任务，间隔时间可以在yml中修改

Ribbon是什么，Ribbon的工作原理讲一下

Ribbon是一个客户端负债均衡器，它可以按照负债均衡算法，向多个服务发起调用。当一个微服务有多个集群时，就可以使用它做请求负载均衡，通常结合RestTemplate来使用

说一下 Ribbon的工作原理

消费者会30/次注册中心拉取服务注册清单缓存到本地，当消费者需要调用一组提供者集群服务时，Ribbon会根据提供者服务名，在本地缓存的服务地址清单里找到这一组服务的通讯地址，然后按照负债均衡算法（默认是轮询），选择其中的一个通讯地址，发起http调用服务。

Ribobn内部通过LoadBalancerInterceptor拦截RestTemplate发起的请求，然后交给RibbonLoadBalancerClient负载均衡客户端做负载均衡，RibbonLoadBalancerClient把选择服务的工作交给ILoadBalancer负载均衡器，ILoadBalancer会调用 IRule负载均衡算法类来选择服务。之后RibbonLoadBalancerClient把选择好的服务交给LoadBalancerRequest去发请求。

Ribbon有哪些负载均衡算法，怎么配置

RoundRobinRule：简单轮询，ribbon默认规则

AvailabilityFilteringRule：忽略短路状态和并发过高的服务器

WeightedResponseTimeRule：根据服务器响应时间作为权重，响应时间越长权重越小

ZoneAvoidanceRule：根据区域选择

BestAvailableRule：忽略短路的服务器，选择并发较低的服务器

RandomRule：随机选择一个可用服务器

Retry：重试机制的选择逻辑

OpenFeign和Ribbon的区别

OpenFeign整合了Ribbon和Hystrix,屏蔽了Ribbon拼接URL，参数的细节，使用声明式编程，让服务调用变得更加简单，OpenFiegn底层也是走的Ribbon的负载均衡策略。推荐使用OpenFeign

OpengFiegn的工作流程

首先，当程序启动时，@EnableFeignClient会扫描@FeignClient注解的接口，并交给Spring容器管理。

当发起请求时，会使用jdk动态代理，并为每个方法都生成相应的RequestTemplate，同时封装http信息，包括url和请求参数等，

最后把RestTemplate交个HttpClient发送请求，使用ribbon的负载均衡发起调用

为什么要使用Eureka 为什么要使用Ribbon 为什么要使用config配置中心

在微服务系统中，各个服务之间是需要进行网络通信的，那么他们相互调用就得知道对方的通信地址。eureka就是专门来做做服务注册与发现，解决服务之间通信问题的

当一个微服务做了集群，也就是同一个服务名会对应多个地址，那么我们在调用的时候，应该调用哪一个就成了问题，Ribbon是一个负债均衡器，它可以按照负债均衡算法，向多个服务发起调用。当一个微服务有多个集群时，就可以使用它做请求的分发

在微服务系统中，服务数量很多，而每个服务都有自己的配置文件，管理起来很麻烦。用了配置中心就可以帮我们集中管理配置文件，它支持本地配置文件，也支持将配置文件放到远程仓库如git集中管理

为什么Feign的客户端接口没有写实现类也可以直接被依赖注入

自动注入的实例其实是一个jdk动态代理对象，Feign会为每个方法生成相应的requestTemplate，它根据服务名找到对应的服务，根据返回值类型、形参列表匹配相应的接口，然后封装url、请求参数，最后生成request请求，使用Ribbon负载均衡发起调用

介绍一下Hystrix

Hystrix意为熔断器，它可以将出现故障的服务，通过熔断、降级等手段隔离开，这样不影响整个系统的主业务。它可以防止由单节点异常导致整个微服务故障，如果遇到故障时，快速失败，熔断的同时可以返回兜底数据达到服务降级的目的

什么是熔断，什么是降级

熔断，是对服务链路的一种保护机制，当链路上的某个服务不可访问时，服务就会触发降级返回拖地数据，同时当失败率到达一个阈值，就标记该服务为短路状态，当请求访问时直接熔断。直到检查到该服务能正常访问时，就快速恢复

降级，是当某个服务不可访问时，我们返回一些事先准备好的数据给客户端，比如说，友情提示服务暂不可用，请骚后重试，这样用户体验就上去了

什么是资源隔离？

指的是限制某一个分布式服务的资源使用，可以理解为限流，也就是限制某个服务的请求数量。它包括线程池隔离和信号量隔离

线程池隔离，是指用一个线程池来存储当前请求，可以通过设置线程池最大线程数和最大排队队列数来限制请求数量

信号量隔离：是指用一个计数器来记录当前有多少个线程在运行，请求进来计数器就增加1，超过最大信号量，就直接返回

资源隔离：信号量和线程池的区别

线程池方式是异步处理，它与调用线程不是同一个线程

信号量方式是同步处理，与调用线程是同一个线程

线程池方式由于需要排队，调度，线程切换，因此开销较大，信号量方式无需切换线程，开销较小

对于CAP理论，Eureka选择的是AP还是CP？它保证了一致性还是可用性？

CAP理论指的是，一个分布式系统中，一致性，可用性，分区容错性，三个要素只能同时实现两点。Eureka选择的是AP，它是弱一致性的，保证了可用性和分区容错性，放弃了数据一致性。也就是说当多个Eureka之间不可通信时，需要保证服务可用，正常提供服务注册发现功能，但是网络恢复后最终还是会同步的。

说一下Eureka的自我保护

为了防止服务被误删除，Eureka不会立即删除过时的服务数据。这种机制可能会导致客户端从注册中心获取到已经下线的服务并发起调用而导致错误，因此在开发阶段我们可以关闭自我保护机制。在生产环境中，我们需要打开自我保护，因为它可以防止因为网络波动，服务没有及时续约而造成的服务误删除问题。

你们项目是如何做服务降级的？

比如在秒杀业务中，需要实时从redis中查询库存，通过设置hystrix的最大信号量，以此来防止redis雪崩。当并发过高，请求数超过最大信号量，触发降级，直接向客户端返回兜底数据：”活动太火爆啦，请骚后重试“

Zuul有哪几类Filter,他们的执行顺序是怎么样的？

zuul按照执行顺序，分为pre前置过滤，route路由过滤，post后置过滤，error异常后过滤

正常流程是请求先经过前置过滤器，到达路由过滤器进行路由，路由到各种微服务执行请求，返回结果后经过后置过滤，返回用户

异常流程，如果再整个过程中出现异常，都会进入error异常过滤器，处理完毕后经过post过滤器返回用户，如果error自己出现异常，最终也会通过post过滤器返回用户，如果post过滤器出现异常，也会跳转到error过滤器，然后直接返回用户

在Zuul中做登录检查如何实现？

可以通过继承ZuulFilter抽象类，自定义pre类型的过滤器，shouldFilter方法中可以定义需要放行的资源，run方法中检查请求头中的token信息，如果没有token，就响应到客户端未登录的信息，并组织filter继续往后执行

在Zuul中如何做限流？

方式一：可以通过继承ZuulFilter抽象类自定义pre过滤器，加上限流算法，来实现

方式二：可以通过hystrix的资源隔离模式，设置线程池最大连接数或者最大信号量来实现

方式三：常用，Ratelimit，使用令牌桶算法。。。

配置中心解决什么问题？

在分布式系统中，服务数量很多，而每个服务都有自己的配置文件，管理起来很麻烦。配置中心是个好东西，可以帮我们集中管理配置文件，它支持本地配置文件，也支持将配置文件放到远程仓库如git集中管理。

EureakServer的搭建流程

第一步，导入eureka-server依赖，以及springboot的web环境依赖。

第二布，主启动类上打注解，@EnableEurekaServer，开启eureka服务端功能

第三步，yml配置文件中，配置注册中心的端口号，主机名，注册中心地址

Ribbon的整合流程

第一步，导入ribbon依赖

第二部，给RestTemplate的Bean定义方法上，加上注解@LoadBalanced，让这个restTemplate有负载均衡的功能

第三步，修改restTemplate调用服务的url，将目标主机名换成目标服务名

Feign的整合流程

第一步，导入openfeign依赖

第二部，主配置类加注解，@EnableFeignClients，开启feign支持

第三步，定义feign客户端接口，并加上注释@FeignClient("目标服务名")，接口中定义方法，该方法与目标服务的对应方法的方法名，返回值类型，形参列表，url路径要一致

Hystrix的整合流程

第一步，导入hystrix依赖
第二部，主启动类加注解，@EnableCircuitBreaker，开启熔断功能
第三步，在需要开启熔断功能的方法上，加注解@HystrixCommand(fallbackMethod="xxx")，xxx是降级方法
第四步，定义降级方法，方法名需要和fallbackMethod的值一致，形参列表和返回值类型需要和目标方法一致

feign整合Hystrix：

第一步，yml中配置，feign.hystrix.enable=true，开启hystrix功能
第二部，@FeignClient标签中，定义fallback或者fallbackFactory，指定降级类
第三步，

如果是fallback，就实现feign接口，并覆写接口中的方法作为降级方法

如果是fallbackFactory，就实现FallbackFactory接口，同时指定泛型为feign接口，覆写create方法，返回一个feign接口的匿名内部类，类中写降级方法

Zuul的整合流程

第一步，导入zuul依赖

第二步，主启动类上加注解@EnableZuulProxy，开启zuul功能

第三步，yml中配置，统一访问前缀prefix，禁用通过服务名方式访问服务ignoredServices，配置路由routes指定某个服务使用某个路径来访问

ConfigServer的整合流程

配置中心服务端配置：

第一步，导入config-server依赖

第二步，主启动类加注解，@EnableConfigServer，开启配置中心

第三步，配置文件中，配置远程仓库地址，仓库账号密码

客户端配置：

第一步，导入config-client依赖

第二步，创建bootstrap.yml配置文件，配置中心地址config.uri，要拉取的配置文件名name，环境名profile

你们微服务项目的技术栈描述一下

前端门户系统：HTML + JQuery + CSS

前端管理系统：VUE + ElementUI

后端系统：基于SpringCloud微服务框架（Eureka+OpenFeign+Hystrix+Zuul+Config）

+MyBatisPlus+SpringMVC+Redis+ElasticSearch+RabbitMQ+AlicloudOSS

浏览器发起一个请求，在你的微服务项目中的怎么去执行的？

浏览器发起的所有请求首先通过Nginx，通过负载均衡算法，路由给zuul集群，然后通过zuul前置过滤，作登录校验后，它会从配置中心拉取的通讯地址中，根据url匹配到对应的服务，然后使用ribbon发起restful调用。微服务间也可以通过feign相互调用，最终执行完任务，返回浏览器

说下Ribbon和Feign的区别呢

Ribbon和Feign都是SpringCloud Netflix中实现负载均衡的组件，不同点在于

Ribbon是需要我们手动构建http请求，根据目标服务名通过负载均衡算法直接调用目标服务，

Feign是采用接口的方式，将需要调用的目标服务方法定义成抽象方法，路径，服务名，形参列表，返回值类型需要保持一致。我们只需要调用接口中的方法就可以了。它会自动帮我们生成jdk动态代理，为每个方法生成RequestTemplate并封装url和请求参数，使用负载均衡算法发起调用

Ribbon的实现方式，一般配合RestTemplate发起http请求，我们需要在注册RestTemplate的Bean的方法上加@LoadBalanced，使它具有负载均衡的能力

Feign的实现方式，是在主启动类上加@EnableFeignClients，在客户端接口上加注解@FeignClient

Spring,SpringBoot和SpringCloud的关系以及区别

Spring是一个开源的轻量级控制反转和面向切面编程的容器框架。轻量级是说它开发使用简单，功能强大。控制反转是指将对象的创建，销毁控制交给ioc容器，方便解耦合，降低维护难度，面向切面编程是指将相同的逻辑横向抽取出来，可以对一些通用业务如事务，日志进行集中管理。

Springboot是一个基于spring的框架，对spring做了大量简化，使开发流程更快，更高效。比如它大量简化maven依赖，基于注解配置（JavaConfig）无需XML，内嵌Tomcat，部署流程简单，打包和部署更加灵活，允许独立运行

SpringCloud是基于SpringBoot实现的，用于微服务架构中管理和协调服务的，它是一系列框架的有序集合，它为开发者提供了一系列工具，例如服务发现与注册，配置中心，网关，负载均衡，熔断器，链路追踪等等，让微服务架构落地变得更简单

分布式事务

什么是分布式事务，

分布式事务，指的是在分布式环境中，一个请求可能涉及到对多个数据库的写操作，要保证多数据库的一致性就需要用到分布式事务

分布式事务你知道哪些解决方案？这些方案如何选型

常见的分布式事务解决方案，2PC，TCC，可靠消息最终一致性，最大努力通知

2PC，它将整个事务流程分为两个阶段，P指的是准备阶段，C指的是提交阶段。它是一个阻塞协议，不适用于并发较高，事务生命周期长的分布式事务。

TCC，它是基于补偿性事务的AP系统的一种实现，补偿也就是说先按照预定方案执行，如果失败了就走补偿方案。它可以自己定义数据操作的粒度，但是对应用的侵入性强，可以用在登录送积分，送优惠券等等场景

可靠消息最终一致性，指的是当事务发起方执行完本地事务后，就发出一条消息通知其他参与方，并且他们一定能接收到消息并处理事务。适合执行周期长，并且实时性要求不高的场景

最大努力通知，是在不影响主业务的情况下，尽可能的保证数据的一致性，它适用于一些最终一致性敏感度低的业务，比如支付结果通知

什么是2pc

2PC，是将整个事务流程分为两个阶段，P指的是准备阶段，C指的是提交阶段。它常见的标准有XA，JTA，Seata

由DTP模型定义事务管理器TM和资源管理器RM之间通讯的接口规范叫做XA，它规定的交互方式是酱紫的：应用程序AP通过TM提交和回滚事务，TM通过XA接口来通知RM数据库事务的开始，结束，提交，回滚

2PC能保证分布式事务的原子性，但是也有很多缺陷

比如，在第一阶段，如果参与者迟迟不回复协调者，就会造成事务的阻塞，性能不好

比如，在第二阶段，如果事务协调者发出提交事务指令后宕机，一部分参与者收到消息提交了事务，另一部分没有收到消息没有提交事务，这就会导致数据不一致

再比如，在第二阶段，如果事务协调者发出提交事务指令后宕机，收到指令的参与者也宕机了，我们就不能确定事务的执行结果，究竟有没有提交

Seata相比传统2PC有什么区别，以及优点？

Seata是由阿里中间件团队发起的开源项目Fescar更名而来，是一个开源的分布式事务框架，它通过对本地关系数据库的分支事务协调，来驱动完成全局事务

Seata的主要优点是性能好，不会长时间占用链接资源，对业务零入侵

与传统的2PC的区别主要两方面

在架构层次方面，传统的2PC方案的RM本质就是数据库自身，而Seata的RM是以jar包形式作为中间件层部署在应用程序上

在两阶段提交上方面，传统2PC方案是在第二阶段完成才释放资源，而Seata是在第一阶段就将本地事务提交，提高了效率

Seata的TC,TM,RM的含义，以及作用？

TC：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚

TM：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令

RM：控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分支事务的提交和回滚

你知道TCC吗，它有什么样的优缺点？

TCC是基于补偿型事务的AP系统的一种实现。补偿指的先按照事先预定的方案去执行，如果失败了就走补偿方案

它的优点是异步执行效率高，它能对分布式事务中的各个资源分别锁定，分别提交与释放

它的缺点是对应用的侵入性强，改动成本高，实现难度大

解释一下Seata的工作原理

Seata有三个角色：

TM任务管理器，负责开启，提交，回滚事务的发起，
TC事务协调器，接收TM的指令通知RM提交或者回滚事务
RM资源管理器，控制着分支事务的提交和回滚

假设有服务A需要调用服务B，且两个服务都需要修改各自的数据库,A服务作为程序入口充当TM和RM，B服务控制着分支事务充当RM。

A服务的TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID
A服务的RM向TC注册分支事务，并将其纳入XID对应全局事务的管辖
A服务执行分支事务，写undolog日志，向TC上报事务状态
当调用B服务时，B服务的RM向TC注册分支事务，该分支事务执行，然后写undolog,向TC上报事务状态
服务执行完毕A服务的TM向TC发送commit或者rollback指令
TC接收到指令，向参与事务的RM发送指令
事务参与者RM受到commit指令，删除undolog日志。如果是rollback指令就根据undolog回滚

你能简单描述一下你在项目中是如何集成Seata的吗

事务协调器：安装并启动Seata客户端

主业务端：

第一步，导入Seata依赖
第二步，yml中配置事务组名，同时需要添加配置文件file.conf，registry.conf，需要注意yml中事务组名与file.comf中的事务组名一致
第三步，配置DataSource，需要适用Seata对DataSource进行代理
第四步，数据库中添加undo log日志表
第五步，业务方法上加注解@GlobalTransactional(rollbackFor = Exception.class)注解

事务参与者：

前四步与主业务端相同，第五步不需要了

没有Seata或者TCC这些事务框架,你可以怎么处理事务?

不用框架就要自己实现,如果业务要求强一致性这个不太好做,需要协调多个数据库的同时提交和回滚.如果是业务不要求强一致性,我可以参照TCC思想 ,可以考虑自己实现异步写数据库方案,如果失败可以做补偿.当然这个要根据业务特性来,很多大公司都是自己封装事务框架.

分布式锁

你说一下什么是分布式锁

分布式锁是在分布式/集群环境中解决多线程并发造成的一系列数据安全问题.所用到的锁就是分布式锁，这种锁需要被多个应用共享才可以，通常使用Redis和zookeeper来实现。

分布式锁有哪些解决方案

常用的三种方案

基于数据库实现：通常基于主键，或者唯一索引来实现分布式锁,但是性能比较差，一般不建议使用

基于Redis ：可以使用setnx来加锁，但是需要设置锁的自动删除来防止死锁，所以要结合expire使用.为了保证setnx和expire两个命令的原子性，可以使用set命令组合。

另外释放锁在finallly中调用del删除锁，而删除锁前需要判断该锁是否是当前线程加的锁以免误删除锁，需要通过get获取锁然后进行判断，但是需要保证get判断或和del删除锁的原子性，可以使用LUA脚本实现。

总之自己封装Redis的分布式锁是很麻烦的，我们可以使用Redissoin来实现分布式锁，Redissoin已经封装好了。

基于zookeeper ：使用临时顺序节点实现，线程进来都去创建临时顺序节点,第一个节点的创建线程获取到锁，后面的节点监听自己的上一个节点的删除事件，如果第一个节点被删除，释放锁第二个节点就成为第一个节点，获取到锁。

在项目中可以使用curator，这个是Apache封装好的基于zookeeper的分布式锁方案。

Redis如何实现分布式锁，用什么命令

可以使用setnx来加锁，但是需要设置锁的自动删除来防止死锁，所以要结合expire使用.为了保证setnx和expire两个命令的原子性，可以使用set命令组合。

Redis实现分布式锁可能会出现什么问题，如何解决

添加锁和设置过期时间可以使用set命令进行组合，达到原子性加锁

需要用lua解决删除和判断锁的原子性，否则可能会删除掉别人的锁。

Redis集群环境中，redis节点挂掉可能会导致加锁失败，可以使用Redisson的红锁来解决。

你项目中怎么使用分布式锁的

自己封装Redis的分布式锁是很麻烦的，我们可以使用Redissoin来实现分布式锁，Redissoin已经封装好了

了解Redission的看门狗原理吗？

Redisson对分布式锁进行了封装，对于锁超时问题，它提供了看门狗进行锁时间的续期，底层使用了定时任务每10s检查一下，如果业务还未执行完成，未释放锁，就进行超时时间续期。

你在项目中如果使用ZK实现分布式锁的？