1. 电商场景下的技术挑战与架构演进
最近几年在帮团队面试Java开发时，发现很多候选人对微服务的理解还停留在概念层面。今天我就以电商系统这个典型场景为例，聊聊大厂面试中最常问到的微服务实战问题。我们团队刚完成了一个日订单量百万级的跨境电商平台重构，过程中积累了不少踩坑经验。
电商系统天生就适合微服务架构——商品、订单、支付、库存等模块天然具备业务边界，高峰期流量波动剧烈需要弹性扩展，不同业务线的迭代节奏也各不相同。但真正落地时会遇到很多教科书上没写的问题：分布式事务怎么处理？链路追踪如何实现？服务网格该怎么选型？
2. 微服务核心组件实战解析
2.1 Spring Cloud Alibaba技术栈选型
我们最终选择了Spring Cloud Alibaba方案，主要基于以下考量：
- Nacos同时支持服务发现和配置中心，比Eureka+Config组合更轻量
- Sentinel的熔断规则支持热点参数限流，特别适合秒杀场景
- Seata的AT模式对业务代码侵入小，适合老系统改造
配置中心有个容易踩的坑：Nacos的配置变更默认采用推模式，但在网络抖动时可能丢失通知。我们后来在关键服务上都加了本地缓存兜底，并启用了长轮询补偿机制。
2.2 分布式事务解决方案对比
电商中最棘手的订单支付场景，我们对比了三种方案：
- 本地消息表：实现简单但需要定期扫描
- TCC模式：性能好但要写太多补偿代码
- Seata AT模式：自动回滚但锁粒度大
最终采用分层策略：普通订单用Seata，秒杀订单用TCC+Redis原子操作。这里要注意Seata的全局锁默认超时时间是60秒，高并发场景需要适当调低。
3. 高频面试问题深度剖析
3.1 服务雪崩防护实战
面试官最爱问的问题之一："你们怎么防止级联故障？"我们的防护体系包括：
- 资源隔离：不同业务线程池物理隔离
- 熔断降级：Sentinel配置慢调用比例阈值
- 请求裁剪：过滤非核心参数降低处理耗时
有个真实案例：某次大促时推荐服务RT飙升，由于提前做了商品详情页的降级策略，自动切换到了缓存数据，保证了核心链路通畅。
3.2 分布式追踪的实现细节
很多候选人知道要用Sleuth+Zipkin，但说不清具体实现。我们自研的追踪系统包含：
- 透传字段：通过MDC传递traceId
- 采样策略：动态调整采样率（高峰期1/1000）
- 存储优化：使用Elasticsearch的冷热数据分离
特别注意：异步线程会丢失上下文，需要手动传递traceId。我们封装了ThreadPoolExecutor的包装类来自动处理。
4. 性能优化关键指标
4.1 JVM调优实战参数
电商系统JVM配置要特别注意：
- 年轻代大小：建议占总堆1/3到1/2
- SurvivorRatio：设置为8避免过早晋升
- CMS参数：-XX:+UseCMSInitiatingOccupancyOnly
我们某个商品服务出现过Full GC频繁，最后发现是JSON序列化时产生了大量临时对象。改用Protobuf后Young GC次数下降了70%。
4.2 数据库分库分表策略
订单表我们采用基因法分片：
- 以user_id后4位作为分片键
- 相同用户订单落在同一分片
- 配合ShardingSphere实现透明访问
有个教训：最初按订单ID哈希分片，导致用户查询要扫描所有分库。后来改造时数据迁移花了整整两周。
5. 容器化部署实践
5.1 Kubernetes资源限制配置
生产环境一定要设置：
yaml复制resources:
limits:
cpu: "2"
memory: 4Gi
requests:
cpu: "0.5"
memory: 1Gi
曾经有服务内存泄漏导致节点OOM，现在所有Pod都配置了存活探针和就绪探针。
5.2 镜像构建优化技巧
多阶段构建能显著减小镜像体积：
dockerfile复制FROM maven AS build
COPY pom.xml .
RUN mvn dependency:go-offline
FROM openjdk:11-jre-slim
COPY --from=build /target/*.jar app.jar
原来300MB的镜像优化后不到100MB，部署速度提升3倍。
6. 面试实战技巧
最后分享几个面试应答技巧：
- 被问"微服务优缺点"时，要结合电商场景具体分析
- 回答"CAP选择"问题时，说明不同业务模块的不同策略
- 讨论分库分表时，要区分OLTP和OLAP场景
最近面试中遇到个不错的回答："我们订单服务采用最终一致性，而库存服务必须强一致性，因为..."这种结合业务细节的答案最能体现实战经验。