面试题答案
一键面试1. 异常处理设计模式与微服务架构结合
1.1 跨服务异常传播
- 采用统一的异常格式：在微服务间通信时，定义标准的异常数据结构。例如，使用JSON格式封装异常信息，包含异常码、异常信息、堆栈跟踪等。这样无论哪个微服务抛出异常，接收方都能以统一方式解析。
- 使用HTTP状态码：在基于HTTP的微服务通信中，利用HTTP状态码表示异常类型。如400表示客户端请求错误，500表示服务端内部错误等。这样下游服务能根据状态码快速判断异常类别。
- 自定义异常传播机制：对于复杂业务场景，可设计自定义的异常传播头信息。例如，在HTTP请求头中添加
X-Exception-Info字段，携带详细异常信息，方便跨服务追踪。
1.2 异常隔离
- 服务熔断：使用Hystrix等熔断框架。当某个微服务调用失败次数达到一定阈值时，触发熔断机制，阻止后续对该服务的调用，避免级联故障。例如，订单微服务调用库存微服务频繁失败，订单微服务熔断库存微服务调用，直接返回友好提示给用户。
- 服务降级：当系统资源紧张或某个微服务不可用时，对非核心功能进行降级处理。比如电商系统在大促期间，为保证订单核心流程，对商品评论展示等非关键功能进行简化或暂时屏蔽。
- 资源隔离：采用线程池隔离或信号量隔离。不同微服务调用分配独立线程池，若一个微服务调用线程池耗尽，不会影响其他微服务调用。如支付微服务和物流查询微服务使用不同线程池。
1.3 确保高可用性和故障恢复能力
- 重试机制：对于一些临时性故障，如网络抖动导致的服务调用失败，采用重试策略。例如，使用Spring Retry框架，设置重试次数、重试间隔等参数。若订单创建时调用支付服务失败，可尝试重试几次。
- 事件驱动架构：通过消息队列实现事件驱动。当微服务出现异常时，发送异常事件到消息队列，由专门的事件处理服务进行处理。如用户注册微服务注册失败，发送注册失败事件到消息队列，通知邮件服务发送提醒邮件。
2. 实际案例
以电商系统为例，该系统包含商品微服务、订单微服务、支付微服务等多个微服务。
- 跨服务异常传播：当用户下单时，订单微服务调用商品微服务检查库存。若库存不足，商品微服务抛出
InsufficientStockException异常，以标准JSON格式封装，通过HTTP 400状态码返回给订单微服务。订单微服务解析异常信息，向用户提示库存不足。 - 异常隔离：在高并发时，支付微服务可能因流量过大响应缓慢。订单微服务使用Hystrix对支付微服务调用进行熔断。当支付微服务失败率超过50%且连续调用10次以上，订单微服务触发熔断，不再调用支付微服务，直接返回“支付繁忙，请稍后重试”提示。同时，对订单查询等非关键功能进行降级，减少系统资源消耗。
- 高可用性和故障恢复：订单创建过程中，若调用支付微服务因网络问题失败，订单微服务使用Spring Retry进行重试。若重试3次仍失败，将订单创建失败事件发送到消息队列，由订单补偿服务进行后续处理，如回滚库存等，确保系统的一致性和高可用性。