面试官:你能说一下什么是熔断?什么是服务降级吗?

服务熔断

服务熔断的作用类似于我们家用的保险丝,当某服务出现不可用或响应超时的情况时,为了防止整个系统出现雪崩,暂时停止对该服务的调用。

服务降级

服务降级是从整个系统的负荷情况出发和考虑的,对某些负荷会比较高的情况,为了预防某些功能(业务场景)出现负荷过载或者响应慢的情况,在其内部暂时舍弃对一些非核心的接口和数据的请求,而直接返回一个提前准备好的fallback(退路)错误处理信息。这样,虽然提供的是一个有损的服务,但却保证了整个系统的稳定性和可用性。

熔断VS降级

相同点:

目标一致 都是从可用性和可靠性出发,为了防止系统崩溃;

用户体验类似 最终都让用户体验到的是某些功能暂时不可用;

不同点:

触发原因不同 服务熔断一般是某个服务(下游服务)故障引起,而服务降级一般是从整体负荷考虑;

Hystrix简介

Hystrix:英 [hɪst'rɪks] 美 [hɪst'rɪks] ,翻译过来是“豪猪”的意思。在分布式环境中,不可避免地会出现某些依赖的服务发生故障的情况。

Hystrix是这样的一个库,它通过添加容许时延和容错逻辑来帮助你控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点,阻止跨服务的级联故障,并提供了退路选项,所有这些都可以提高系统的整体弹性。

Hystrix的设计目的:

  • 通过第三方客户端的库来为访问依赖服务时的潜在故障提供保护和控制;

  • 防止在复杂分布式系统中出现级联故障;

  • 快速失败和迅速恢复;

  • 在允许的情况下,提供退路对服务进行优雅降级;

  • 提供近实时的监控、报警和操作控制;

接下来我们将通过对 《模拟RPC调用(Feign)》一章中的 message-center 项目进行改造,演示如何使用Hystrix,eureka服务注册中心以及message-service服务提供者无需更改。

https://blog.youkuaiyun.com/pengjunlee/article/details/86615408

使用Hystrix

引入Hystrix依赖

在 pom.xml 文件中引入Hystrix依赖:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.0.6.RELEASE</version>
 </parent>
 
 <properties>
  <spring-cloud.version>Finchley.SR2</spring-cloud.version>
 </properties>
 
 <dependencies>
  <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
  <!-- Eureka-Client 依赖 -->
  <dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
  </dependency>
  <!-- Feign 依赖 -->
  <dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-openfeign</artifactId>
  </dependency>
  <!-- Hystrix 依赖 -->
  <dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
  </dependency>
 </dependencies>
 
 <dependencyManagement>
  <dependencies>
   <!-- SpringCloud 版本控制依赖 -->
   <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-dependencies</artifactId>
    <version>${spring-cloud.version}</version>
    <type>pom</type>
    <scope>import</scope>
   </dependency>
  </dependencies>
 </dependencyManagement>

修改启动类

在MessageCenterApplication启动类上增加@EnableCircuitBreaker注解:

@SpringBootApplication
@EnableFeignClients
@EnableCircuitBreaker
public class MessageCenterApplication {
 
 public static void main(String[] args) {
  new SpringApplicationBuilder(MessageCenterApplication.class).web(WebApplicationType.SERVLET).run(args);
 }
 
}

这里我们在启动类中又增加了@EnableCircuitBreaker注解,用来开启断路器功能。如果你觉得启动类上的注解个数有点多的话,可以使用一个@SpringCloudApplication 注解来代替@SpringBootApplication(或者@EnableEurekaServer)、@EnableDiscoveryClient、@EnableCircuitBreaker这三个注解。

搜索公众号”Java笔记虾“,回复 后端面试 ,送你一份Java面试宝典.pdf

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {
}

修改Controller

接下来,我们为MessageCenterController中的getMsg()接口增加断路器功能,修改部分代码如下:

 @GetMapping("/msg/get")
 @HystrixCommand(fallbackMethod = "getMsgFallback")
 public Object getMsg() {
  String msg = messageService.getMsg();
  return msg;
 }
 
 public Object getMsgFallback() {
  return "祝您 2019 猪年大吉,'猪'事如意!";
 }

先启动Eureka,再启动一个8771端口的message-service服务,最后启动message-center。待启动完成之后,Eureka注册中心实例注册信息如下:

此时,访问 http://localhost:8781/api/v1/center/msg/get ,返回如下结果表明服务调用成功:

然后,停掉message-service服务,再次请求 http://localhost:8781/api/v1/center/msg/get ,返回结果如下:

可以看出fallback中的信息被直接返回了,表明Hystrix断路器调用成功。

注意:fallback方法的签名需要和原方法保持一致。

 /**
  * 获取消息详情
  */
 @GetMapping("/api/v1/msg/detail/{id}")
 @HystrixCommand(fallbackMethod = "getDetailFallback")
 public MessageEntity getDetail(@PathVariable(name = "id") Long id) {
  return messageService.getById(id);
 }
 
 /**
  * 获取消息详情退路
  */
 public MessageEntity getDetailFallback(Long id){
  return null;
 }

Feign结合Hystrix

以MessageService的Feign客户端为例,为其添加Hystrix断路器功能。

搜索公众号”Java笔记虾“,回复 后端面试 ,送你一份Java面试宝典.pdf

修改Feign客户端

通过配置@FeignClient注解的fallback属性来位MessageServiceClient指定一个自定义的fallback处理类(MessageServiceFallback)。

@FeignClient(name = "message-service", fallback = MessageServiceFallback.class)
public interface MessageServiceClient {
 
 @GetMapping("/api/v1/msg/get")
 public String getMsg();
 
}

创建Fallback处理类

MessageServiceFallback需要实现MessageServiceClient接口,并且在Spring容器中必须存在一个该类型的有效Bean。在这里,我们使用@Component注解将其注入到Spring容器中。

@Component
public class MessageServiceFallback implements MessageServiceClient {
 
 @Override
 public String getMsg() {
  System.out.println("调用消息接口失败,对其进行降级处理!");
  return "消息接口繁忙,请稍后重试!";
 }
 
}

修改配置

在新版本的Springcloud中,Feign默认关闭了对Hystrix的支持,需要在application.yml进行配置:

feign:
  hystrix:
    enabled: true

当message-service服务不可用时,请求

 

http://localhost:8781/api/v1/center/msg/get,返回结果如下:

查看后台日志,打印如下内容,表明fallback方法被成功调用了:

监控Hystrix

启用健康监控

Actuator是Springboot提供的用来对应用系统进行自省和监控的功能模块,借助于Actuator开发者可以很方便地对应用系统某些监控指标进行查看、统计等。

若要使用Actuator对Hystrix 流进行监控,除了需在工程POM文件中引入spring-boot-starter-actuator依赖:

  <!-- Actuator 依赖 -->
  <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>

还需要在application.yml 中添加如下配置:

management:
  endpoints:
    web:
      exposure:
        include: hystrix.stream

启用Hystrix-Dashboard

使用Hystrix一个最大的好处就是它会为我们自动收集每一个HystrixCommand的信息,并利用Hystrix-Dashboard通过一种高效的方式对每一个断路器的健康状态进行展示。

值得注意的是,在使用HystrixCommand对RibbonClient进行包装的时候,你需要确保你配置的Hystrix超时时间要比Ribbon的超时时间长,包括由它们引起的重试时间,举个例子:如果你的Ribbon连接超时时间是1秒,并且Ribbon会连续重试请求3次,那么你的Hystrix连接超时时间需要配置成稍大于3秒。

引入Hystrix-Dashboard依赖

在 pom.xml 文件中引入Hystrix-Dashboard依赖:

  <!-- Hystrix Dashboard 依赖 -->
  <dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
  </dependency>

修改启动类

在MessageCenterApplication启动类上增加@EnableHystrixDashboard注解:

@EnableFeignClients
@SpringCloudApplication
@EnableHystrixDashboard
public class MessageCenterApplication {
 
 public static void main(String[] args) {
  new SpringApplicationBuilder(MessageCenterApplication.class).web(WebApplicationType.SERVLET).run(args);
 }
 
}

仪表盘界面

启动应用,访问 http://localhost:8781/hystrix ,打开Hystrix-Dashboard监控首页。

在这里配置好需要监控的Hystrix流地址

http://localhost:8781/actuator/hystrix.stream ,开始监控。

参考文章

https://github.com/netflix/hystrix/wiki

https://github.com/netflix/hystrix

https://cloud.spring.io/spring-cloud-netflix/single/spring-cloud-netflix.html

 

 

<think>嗯,用户正在准备Java管理岗位的面试,结合之前的回答和用户提供的站内引用,需要更聚焦技术管理岗位的特殊性。用户引用的资料提到技术一面考察基础能力,二面涉及管理思考,还提到分布式系统和高并发场景的实际问题处理,比如Kafka重复消费、Redis分布式锁实现等。 用户的核心诉求是明确Java技术管理岗的双重能力要求:既要保持技术深度,又要具备团队管理能力。从引用[2]和[5]可以看出,初次转型管理的候选人常忽视技术愿景传递和团队效能量化。因此需要强调这两点。 技术深度方面,引用[4]提到的Kafka消息幂等性和Redis分布式锁是高频考点,需补充到分布式系统设计中。管理能力则要突出引用[5]中Dubbo这类技术选型的决策逻辑——不能只讲原理,要明如何服团队采用。 特别要注意用户隐藏需求:ta可能正从开发岗转向管理岗。引用[3]提到的"岗位匹配度"很重要,需建议ta准备技术转型管理的案例,比如如何用业务语言解释技术债务(引用[2]的治理策略)。 最后,用户提供的引用多次出现阿里面试题,明大厂对量化指标(如QPS提升、部署频率)的执着。在"面试准备建议"板块需强化数据思维,要求ta用具体数字佐证管理成果。</think>针对Java技术管理岗位的面试,需同时展现技术深度和管理能力。结合引用资料及实践经验,核心准备要点如下: --- ### 一、技术深度(结合引用[1][4]的考核重点) 1. **Java核心与高并发** - JVM调优:内存泄漏定位(MAT工具)、GC算法选型(G1 vs ZGC场景)[^1] - 并发编程:线程池参数设计(`corePoolSize`与`workQueue`关系)、`ConcurrentHashMap`分段锁演化[^4] - 分布式锁实现:Redis锁(Redlock算法)、ZK锁的CAP权衡[^4] 2. **分布式系统设计** - 消息中间件:Kafka消息幂等性(`enable.idempotence`配置)、积压治理方案[^4] - 微服务治理:Dubbo服务熔断策略、Seata分布式事务SAGA模式[^5] - 缓存穿透/雪崩:布隆过滤器实现、多级缓存架构设计[^1] 3. **故障处理能力** - 线上问题定位:`jstack`分析死锁、`Arthas`热修复方案 - 高可用设计:限流算法实现(令牌桶伪代码) ```java // 令牌桶限流示例 public synchronized boolean tryAcquire() { long now = System.currentTimeMillis(); tokens = Math.min(capacity, tokens + (now - lastTime) * rate); if (tokens < 1) return false; tokens--; lastTime = now; return true; } ``` --- ### 二、管理能力(引用[2][5]的管理者视角) 1. **技术决策框架** - 技术选型方法论:开源组件License合规审计(如AGPL风险)、技术债务量化(SonarQube指标)[^2] - 架构演进:单体拆微服务的五大信号(团队规模、部署频率、故障隔离需求)[^5] 2. **团队效能提升** - 流程优化:CI/CD流水线设计(从周级到小时级部署)[^2] - 技术氛围建设:代码评审Checklist设计、技术债偿还机制(如20%迭代资源专用于重构)[^5] 3. **资源协调与风险控制** - 优先级模型:RICE评分法(Reach, Impact, Confidence, Effort) - 应急预案设计:依赖方故障降级方案(如熔断后本地缓存兜底)[^4] --- ### 三、面试应答策略(引用[3][4]的实战案例) 1. **技术问题示例** > **面试官**:如何保证Kafka消息的精确一次消费? > **应答要点**: > 1. 生产者端:启用`idempotence=true`+`acks=all` > 2. 消费者端:幂等设计+外部存储去重(Redis原子操作) > 3. 业务补偿:死信队列+人工干预机制[^4] 2. **管理问题示例** > **面试官**:如何推动老旧系统重构? > **应答框架**: > 1. 价值量化:用故障率下降50%+部署时间缩短70%争取资源 > 2. 渐进式重构:Strangler Pattern逐步替换模块 > 3. 风险控制:并行运行验证+流量灰度切换[^5] --- ### 四、差异化准备建议 1. **技术深度证明** - 准备架构图:高并发系统设计(标注QPS从1k到10w的演进路径) - 性能调优案例:JVM GC停顿从2s优化到200ms的具体参数[^1] 2. **管理能力展示** - 团队效能数据:代码覆盖率从60%→90%、部署频率提升5倍 - 技术规划文档:展示3年技术演进路线图(含Serverless/AI工程化落地节点)[^3] 3. **行业趋势结合** - 云原生:K8s Operator在Java应用中的实践 - 成本治理:Spot实例节省40%云成本的弹性策略[^2] --- ### 关键注意事项 1. 避免纯理论:所有技术方案需关联业务结果(如“引入Redis集群提升订单查询TP99从1s→200ms”) 2. 突出决策逻辑:技术选型需明权衡依据(如“选RabbitMQ而非Kafka因需延迟队列功能”)[^3] --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值