第1章：岗位能力画像与简历优化模板
1.1 岗位能力画像：面试官在找什么人？
| 能力维度 | 面试高频考点 | 预期熟练度 | 简历关键词 |
|---|---|---|---|
| 微服务架构设计 | 服务拆分、领域驱动设计（DDD）、API网关 | 能说出拆分原则，至少一个实战案例 | DDD、服务拆分、BFF、Gateway |
| 服务治理与注册发现 | Nacos/Eureka原理、一致性协议、负载均衡 | 能对比AP与CP，解释心跳机制 | Nacos、Eureka、Consul、Ribbon |
| 分布式事务与一致性 | Seata（AT/TCC）、可靠消息最终一致性、Saga | 至少掌握两种模式，能选型 | Seata、TCC、可靠消息、最终一致性 |
| 服务监控与可观测性 | 链路追踪（SkyWalking/Zipkin）、Prometheus+Grafana | 了解Trace/Log/Metric三支柱 | SkyWalking、Jaeger、Prometheus |
| CI/CD与容器化 | Docker、K8s部署、Jenkins流水线 | 能写Dockerfile，懂Pod/Service | Docker、Kubernetes、Helm、Jenkins |
1.2 简历优化模板：用能力画像反哺简历
把你的工作经历按照“微服务能力画像”重新组织，每段项目描述遵循 STAR（情境-任务-行动-结果） 结构，并嵌入下方关键词。面试官扫读简历时，会快速匹配能力矩阵。
简历项目描述模板
【项目名称：XX电商平台微服务改造】
● 情境：原有单体架构日均订单10万+，响应超时频发，团队决定升级为微服务。
● 任务：负责订单与库存服务的拆分及分布式事务改造。
● 行动：
- 引入Nacos实现服务注册与配置中心，AP模式保障高可用。
- 使用Seata AT模式处理下单减库存的分布式事务，事务成功率从85%提升至99.7%。
- 搭建SkyWalking进行全链路追踪，平均错误定位时间从2小时缩短至15分钟。
● 结果：系统吞吐量提升3倍，双11峰值下单5万笔/秒无故障。1.3 面试问答卡片：高频问题与回答框架
卡片一：微服务架构设计
面试问题：你是怎么做服务拆分的？说说你的原则和一次实际经历。
面试官考察点：
- 是否掌握DDD限界上下文等方法论，还是拍脑袋拆？
- 能否平衡业务内聚性和技术复杂度？
- 是否有过拆分后失败的反思？
回答框架：
- 先陈述拆分原则：高内聚低耦合、按业务能力（DDD限界上下文）、避免分布式事务优先。
- 举一个具体项目：电商订单与库存拆分，原始问题（库存扣减耦合在订单里）。
- 说明拆分过程：先梳理领域模型，定义Bounded Context，再剥离库存服务。
- 给出结果：交付效率提升40%，但初期因调用链路变长导致响应增加5ms，后续用缓存补偿。
简短示例回答（80字）：
“我按DDD限界上下文拆分，比如把库存从订单中剥离成独立服务。首先识别出‘库存管理’是独立质变领域，然后定义接口契约，用Seata AT处理跨服务事务。拆分后订单模块迭代速度提升40%，但注意避免过度拆分，一开始保持3~5个服务最合适。”
可能追问：
- 如果服务之间调用链路过长，你怎么优化？（答：引入异步消息、数据同步缓存）
- 你们拆分后数据一致性怎么保证？（答：分布式事务方案选型）
避坑提醒： 不要只说“按业务功能拆分”，这太表面。面试官想听你有没有领域驱动设计的思维颗粒度。
卡片二：服务治理与注册发现
面试问题：Nacos和Eureka有什么区别？你们为什么选Nacos？
面试官考察点：
- 是否理解AP/CP的区别及其业务含义？
- 有没有真实选型对比经验？
- 是否踩过坑（如集群脑裂、配置热更新）？
回答框架：
- 对比核心：Eureka纯AP，牺牲一致性；Nacos支持AP和CP切换，且内置配置中心。
- 选型理由：我们需要配置热更新（Nacos原生支持）和动态灰度发布，且业务允许短暂不一致。
- 实际使用：选了Nacos AP模式，采用健康检查（每5秒心跳），集群部署3节点保高可用。
简短示例回答（85字）：
“我们选Nacos而非Eureka，因为Nacos自带配置中心，支持配置实时推送，且可在AP/CP切换。业务上我们订单服务允许短暂不一致（比如5秒内读到老节点），所以用AP模式。Eureka纯AP但无配置能力，若只做注册也够用，但需要额外维护配置中心。”
可能追问：
- Nacos AP模式下，如果发生网络分区，你怎么感知和处理？（答：心跳机制+健康检查回调）
- 你们配置热更新遇到过推送失败吗？（答：MD5校验+灰度推送）
避坑提醒： 不要只说“Nacos比Eureka好”，要结合场景。如果你们的业务对一致性要求极高（如金融转账），选Nacos CP或Consul更合理，面试官会追问场景匹配。
卡片三：分布式事务与一致性
面试问题：你项目中用了Seata AT模式，能说说它的原理吗？有什么局限性？
面试官考察点：
- 是否真正理解AT模式两阶段提交（全局锁、undolog）？
- 能否分析AT与TCC、可靠消息的适用场景？
- 有没有遇到过AT模式性能瓶颈或数据回滚失败？
回答框架：
- 先说AT原理：一阶段执行业务SQL并记录undolog，二阶段提交（或回滚时用undolog反向补偿）。
- 优点：对业务代码侵入小，自动生成undolog。
- 局限性：对数据库加全局锁，高并发下锁冲突严重；不支持所有SQL（如DDL、select for update）。
- 实际处理：我们针对高并发场景换成TCC+消息队列最终一致性。
简短示例回答（90字）：
“Seata AT的核心是代理数据源，一阶段通过‘before image+after image’记录undolog，二阶段提交删除记录或回滚用undolog反向补偿。优点是零侵入，但全局锁在秒杀场景下TPS骤降。我们订单核心链路用TCC模式（预留库存+确认释放），非核心用可靠消息最终一致性，平衡了性能与一致性。”
可能追问：
- AT模式事务隔离级别怎么控制？（答：读未提交+全局锁防脏读）
- 可靠消息如果投递失败怎么办？（答：本地消息表+定时任务扫描+重试+告警）
避坑提醒： 不要只说“我们项目用了Seata”，一定要说出你了解原理和局限。面试官最反感“用过但不知道底层”的候选人。