后端簡歷里出現(xiàn)頻率最高的一句話之一設計并搭建了公司的微服務架構使用 Spring Cloud 實現(xiàn)服務拆分、注冊發(fā)現(xiàn)、配置中心與網關這句話幾乎必然被追問而且追問的強度會高于簡歷上其他任何一條。原因有三個。第一「架構」是團隊級的詞。一套微服務架構落地涉及拆分方案、基礎設施、發(fā)布流程、監(jiān)控體系沒有哪個人能獨立完成。寫「設計了」對方第一反應是你在其中的哪一層。第二這句話沒有任何可驗證的細節(jié)。拆了幾個服務、按什么拆的、拆完之后出了什么問題一個都沒寫。面試官只能靠問來補。第三架構恰好是面試官最擅長問的領域。系統(tǒng)設計是高級面試的固定環(huán)節(jié)他手里有一整套現(xiàn)成的問題。追問鏈長什么樣順序一般是這樣拆分的依據是什么為什么這么切而不是那么切服務之間怎么通信同步還是異步為什么跨服務的數據一致性怎么處理拆完之后出現(xiàn)了什么新問題現(xiàn)在回頭看這個拆分有沒有拆過頭或者拆不夠的地方第一問和最后一問是分水嶺。拆分依據答不出來說明方案不是你定的最后一問答不出來說明你沒有跟到上線之后。中間三問是技術細節(jié)用過的人都能答但答得出來不等于設計過。架構經歷的信息結構備選、取舍、代價架構決策和功能開發(fā)的核心區(qū)別是功能有對錯架構只有取舍。所以架構類經歷的可信度來自你能不能講出「放棄了什么」。一條能守住的架構描述至少包含四樣東西規(guī)模幾個服務、幾個人、多長時間、你負責的邊界、一個具體的技術決策及其備選方案、這個決策帶來的代價。對比設計并搭建了公司的微服務架構使用 Spring Cloud 實現(xiàn)服務拆分、注冊發(fā)現(xiàn)、配置中心與網關參與單體拆分為微服務3 人4 個月最終 7 個服務負責訂單與庫存兩個服務的邊界劃分與實施 - 按業(yè)務事務邊界拆分訂單創(chuàng)建時的庫存扣減由同步調用改為本地消息表 定時補償 放棄了 Seata AT 模式壓測下 TC 成為瓶頸 - 拆分后訂單服務可獨立發(fā)布發(fā)布頻次從兩周 1 次提到每周 2-3 次 - 代價引入 2 個最終一致性場景補了對賬任務和延遲告警 跨服務聯(lián)查從一條 SQL 變成兩次 RPC列表頁 P95 上升約 30ms第二種寫法里規(guī)模、邊界、決策、備選、代價都有。面試官讀完不需要再問「你在哪一層」追問會直接進入「為什么放棄 Seata」「對賬任務怎么設計的」這些都是你做過的事越問越有利。寫代價這一條很多人不敢寫覺得是在暴露方案的缺點。實際上正好相反能說出代價的人才是真的跟到了上線之后。沒有代價的架構方案只存在于 PPT 里。你在架構里的哪一層架構類經歷大致有三個層次可以寫每一層都有價值關鍵是寫準定方向的決定拆不拆、怎么拆、用什么技術棧。通常是架構師或技術負責人。劃邊界的負責某幾個服務的邊界和接口設計參與整體方案討論。多數中級工程師在這一層。實施的按既定方案實現(xiàn)某個服務處理遷移中的具體問題。在第三層的人把自己寫成第一層追問鏈第一問就會露。但第三層本身也有很多可寫的數據遷移怎么做雙寫、灰度切流怎么切、老接口怎么兼容。這些細節(jié)比「設計了架構」更有分量因為它們只有真做過的人才知道。幾種守不住的寫法把用了全家桶等同于設計了架構。Spring Cloud、Nacos、Sentinel、Gateway 都配上了這叫接入不叫設計。設計發(fā)生在拆分方案和邊界劃分上。把畫了架構圖等同于設計。架構圖是結果的表達面試官問的是圖上每根線為什么這么連。把兩個服務寫成微服務架構。兩個服務當然可以寫但寫清楚規(guī)?！笇⒅Ц哆壿嫃闹鲬貌馂楠毩⒎铡贡取肝⒎占軜嫛拐\實得多也更具體。只寫收益不寫問題?！覆鸱趾笙到y(tǒng)可維護性大幅提升」是一句評價不是事實。拆分之后一定會有新問題一個都沒寫對方會認定你沒跟到后面。寫完自查每條架構類描述找三個數幾個服務、幾個人、幾個月。找一個備選方案。找一個代價。三樣都找不到的要么補要么把動詞降到你實際所在的那一層。最后架構經歷不怕被追問怕的是追問落在你沒參與的那一層。把自己的層次寫準把取舍和代價寫出來追問就會落在你最熟的地方。