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