《深入Spring Cloud与Kafka的电商系统面试三连问：Java求职者的实战突围》

面试场景设定：

你是一位具有5年Java后端开发经验的求职者，正在参与一家互联网大厂的高级开发岗面试。面试官围绕“电商系统”进行提问，内容涵盖Spring Cloud、Kafka、数据库设计与服务容错等核心技术，并设置逐步深入的技术追问。

第一轮：微服务架构基础设计
面试官：我们公司正在搭建一套微服务电商平台，请你说明下如何用Spring Cloud进行模块拆分及服务间通信设计？

问题1：你会如何划分电商系统的微服务模块？
问题2：Spring Cloud中你打算使用什么方式做服务注册与发现？
问题3：服务间通信你会选择RestTemplate还是OpenFeign？为什么？
问题4：如果有一些核心服务不允许宕机，怎么保证高可用性？
问题5：限流与熔断你如何设计？

第二轮：消息驱动与数据一致性设计
面试官：电商系统中订单、库存、支付都涉及复杂的消息协同，你在Kafka中如何设计异步通信？

问题1：请说出订单创建后如何异步通知库存中心进行扣减？Kafka的消费逻辑怎么设计？
问题2：你如何保证消息“至少投递一次”但避免重复消费？
问题3：假设库存服务处理失败，你如何保证消息重试但又不阻塞整体流程？
问题4：如何在Kafka与数据库操作之间保证最终一致性？你会怎么落地？
问题5：Kafka集群宕机时系统怎么降级？

第三轮：系统监控与异常诊断
面试官：系统上线后稳定运行很关键，我们有一套基于Prometheus + Grafana + ELK的运维体系，你觉得这些组件怎么协同工作？

问题1：Spring Boot如何集成Micrometer将服务指标采集给Prometheus？
问题2：有哪些指标你会重点关注来判断系统健康？
问题3：日志采集方面，ELK Stack怎么部署和使用？
问题4：一次支付请求链路过慢，你如何用Zipkin或Jaeger排查瓶颈？
问题5：请说下你在定位线上生产故障时的经验和工具使用方法。

面试官总结发言：
“感谢你的分享，我们会在内部进行评估，稍后通过电话或邮件联系你，辛苦了！”

知识详解与学习总结：
第一轮技术点详解：
微服务划分：典型模块包括：用户服务、商品服务、订单服务、库存服务、支付服务、网关服务等。每个服务职责单一，符合高内聚低耦合原则。

服务注册与发现：使用Spring Cloud Netflix Eureka或Consul注册服务，自动发现服务位置，提高灵活性。

服务通信：推荐使用OpenFeign，因为其更贴近声明式开发，支持Ribbon负载均衡与Hystrix熔断配置。

高可用性：通过服务集群+注册中心+负载均衡+熔断降级机制（如Resilience4j）确保关键路径稳定运行。

限流设计：可以借助Spring Cloud Gateway内置限流器或使用Sentinel做细粒度限流策略。

第二轮技术点详解：
Kafka消息驱动：在订单服务下单后发送Kafka消息到库存主题，库存服务监听处理消息并扣减库存。采用消费者组实现并发消费。

重复消费与幂等性：在消费端加入幂等逻辑，如幂等Key写入Redis或数据库记录防重复处理。

重试机制：使用DLQ（死信队列）或定制重试Topic实现失败重试，同时主业务流程不阻塞。

最终一致性：使用事务消息+本地消息表+定时补偿等方案，避免分布式事务带来的性能和复杂性问题。

Kafka降级：启用消息缓冲队列，必要时降级到同步调用，或者存入数据库待恢复后补偿处理。

第三轮技术点详解：
指标采集：Micrometer是Spring Boot内置的指标桥接库，配合Prometheus采集如JVM GC、线程数、HTTP请求时间等关键指标。

系统健康指标：包括CPU负载、内存占用、请求成功率、平均响应时间、错误率、消息积压等。

日志分析：ELK (Elasticsearch + Logstash + Kibana) 可实时分析日志数据，通过Kibana可视化操作异常日志。

链路追踪：使用Zipkin/Jaeger采集分布式调用数据，快速定位在哪个服务环节出现延迟。

故障排查经验：先看Prometheus告警、再看ELK日志、使用链路追踪定位具体服务，再借助日志或热线程Dump工具诊断。