后端简历里出现频率最高的一句话之一：
设计并搭建了公司的微服务架构，使用 Spring Cloud 实现服务拆分、注册发现、配置中心与网关
这句话几乎必然被追问，而且追问的强度会高于简历上其他任何一条。原因有三个。
第一，「架构」是团队级的词。一套微服务架构落地，涉及拆分方案、基础设施、发布流程、监控体系，没有哪个人能独立完成。写「设计了」，对方第一反应是：你在其中的哪一层。
第二，这句话没有任何可验证的细节。拆了几个服务、按什么拆的、拆完之后出了什么问题，一个都没写。面试官只能靠问来补。
第三，架构恰好是面试官最擅长问的领域。系统设计是高级面试的固定环节，他手里有一整套现成的问题。
追问链长什么样
顺序一般是这样：
- 拆分的依据是什么，为什么这么切而不是那么切
- 服务之间怎么通信，同步还是异步，为什么
- 跨服务的数据一致性怎么处理
- 拆完之后出现了什么新问题
- 现在回头看，这个拆分有没有拆过头或者拆不够的地方
第一问和最后一问是分水岭。拆分依据答不出来，说明方案不是你定的；最后一问答不出来，说明你没有跟到上线之后。中间三问是技术细节，用过的人都能答，但答得出来不等于设计过。
架构经历的信息结构：备选、取舍、代价
架构决策和功能开发的核心区别是：功能有对错，架构只有取舍。所以架构类经历的可信度，来自你能不能讲出「放弃了什么」。
一条能守住的架构描述至少包含四样东西：规模（几个服务、几个人、多长时间）、你负责的边界、一个具体的技术决策及其备选方案、这个决策带来的代价。
对比：
设计并搭建了公司的微服务架构，使用 Spring Cloud 实现服务拆分、注册发现、配置中心与网关参与单体拆分为微服务（3 人，4 个月，最终 7 个服务），负责订单与库存两个服务的边界划分与实施： - 按业务事务边界拆分，订单创建时的库存扣减由同步调用改为本地消息表 + 定时补偿， 放弃了 Seata AT 模式（压测下 TC 成为瓶颈） - 拆分后订单服务可独立发布，发布频次从两周 1 次提到每周 2-3 次 - 代价：引入 2 个最终一致性场景，补了对账任务和延迟告警； 跨服务联查从一条 SQL 变成两次 RPC，列表页 P95 上升约 30ms第二种写法里，规模、边界、决策、备选、代价都有。面试官读完不需要再问「你在哪一层」，追问会直接进入「为什么放弃 Seata」「对账任务怎么设计的」，这些都是你做过的事，越问越有利。
写代价这一条很多人不敢写，觉得是在暴露方案的缺点。实际上正好相反，能说出代价的人才是真的跟到了上线之后。没有代价的架构方案只存在于 PPT 里。
你在架构里的哪一层
架构类经历大致有三个层次可以写，每一层都有价值，关键是写准：
定方向的：决定拆不拆、怎么拆、用什么技术栈。通常是架构师或技术负责人。
划边界的：负责某几个服务的边界和接口设计，参与整体方案讨论。多数中级工程师在这一层。
实施的：按既定方案实现某个服务，处理迁移中的具体问题。
在第三层的人把自己写成第一层，追问链第一问就会露。但第三层本身也有很多可写的：数据迁移怎么做双写、灰度切流怎么切、老接口怎么兼容。这些细节比「设计了架构」更有分量，因为它们只有真做过的人才知道。
几种守不住的写法
把用了全家桶等同于设计了架构。Spring Cloud、Nacos、Sentinel、Gateway 都配上了，这叫接入，不叫设计。设计发生在拆分方案和边界划分上。
把画了架构图等同于设计。架构图是结果的表达，面试官问的是图上每根线为什么这么连。
把两个服务写成微服务架构。两个服务当然可以写，但写清楚规模，「将支付逻辑从主应用拆为独立服务」比「微服务架构」诚实得多，也更具体。
只写收益不写问题。「拆分后系统可维护性大幅提升」是一句评价，不是事实。拆分之后一定会有新问题，一个都没写，对方会认定你没跟到后面。
写完自查
每条架构类描述，找三个数：几个服务、几个人、几个月。找一个备选方案。找一个代价。
三样都找不到的，要么补，要么把动词降到你实际所在的那一层。
最后
架构经历不怕被追问，怕的是追问落在你没参与的那一层。把自己的层次写准，把取舍和代价写出来，追问就会落在你最熟的地方。
