后端简历里出现频率最高的一句话之一设计并搭建了公司的微服务架构使用 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 都配上了这叫接入不叫设计。设计发生在拆分方案和边界划分上。把画了架构图等同于设计。架构图是结果的表达面试官问的是图上每根线为什么这么连。把两个服务写成微服务架构。两个服务当然可以写但写清楚规模「将支付逻辑从主应用拆为独立服务」比「微服务架构」诚实得多也更具体。只写收益不写问题。「拆分后系统可维护性大幅提升」是一句评价不是事实。拆分之后一定会有新问题一个都没写对方会认定你没跟到后面。写完自查每条架构类描述找三个数几个服务、几个人、几个月。找一个备选方案。找一个代价。三样都找不到的要么补要么把动词降到你实际所在的那一层。最后架构经历不怕被追问怕的是追问落在你没参与的那一层。把自己的层次写准把取舍和代价写出来追问就会落在你最熟的地方。
