很多技術(shù)教程把“集成、驗(yàn)證”講成了兩個(gè)獨(dú)立的章節(jié)把“面試題”又講成另一套東西。但實(shí)際上做項(xiàng)目和準(zhǔn)備面試完全是一件事的兩面項(xiàng)目里怎么把模塊捏合在一起、怎么證明它靠譜面試官問的就是你在這中間的每個(gè)決策和踩坑。這篇我直接把第07講“集成、驗(yàn)證與面試題精講”拆開揉碎結(jié)合我這些年帶項(xiàng)目、做評(píng)審、面別人的經(jīng)驗(yàn)把集成階段的順序、驗(yàn)證手段的取舍、面試回答的套路一次說清楚。適合正在做畢設(shè)、剛?cè)肼毿枰?dú)立負(fù)責(zé)模塊、以及準(zhǔn)備技術(shù)面試的開發(fā)者參考內(nèi)容不繞彎子全是能直接用的方法。1. 集成的核心挑戰(zhàn)與設(shè)計(jì)思路1.1 集成不是把代碼拼在一起那么簡(jiǎn)單很多人對(duì)集成的理解是“大家把代碼往主干一合能跑起來就算完事”。我在實(shí)際項(xiàng)目里見過太多次這種想法的翻車現(xiàn)場(chǎng)每個(gè)人本地都跑得好好的一合到一起就各種報(bào)錯(cuò)接口對(duì)不上、字段名不一致、數(shù)據(jù)格式不對(duì)、環(huán)境配置互相覆蓋?；ㄔ谂胚@些破事上的時(shí)間往往比寫代碼本身還多。真正的集成核心要解決的是“模塊之間的契約問題”。所謂契約不是你說你傳個(gè)參數(shù)我收個(gè)參數(shù)這么簡(jiǎn)單而是包括接口的協(xié)議類型、數(shù)據(jù)字段的類型和含義、異常情況下的返回結(jié)構(gòu)、超時(shí)時(shí)間的約定、冪等性的保障甚至包括日志格式和追蹤標(biāo)識(shí)怎么傳遞。這些東西只要有一項(xiàng)沒約定清楚集成的時(shí)候就會(huì)爆發(fā)問題。我之前帶某個(gè)模擬項(xiàng)目X的時(shí)候A同學(xué)負(fù)責(zé)用戶服務(wù)B同學(xué)負(fù)責(zé)訂單服務(wù)兩個(gè)人都是自己定義返回結(jié)構(gòu)。A同學(xué)用{code, message, data}B同學(xué)用{status, msg, result}。聯(lián)調(diào)的時(shí)候兩邊都認(rèn)為是對(duì)方的問題實(shí)際上誰都沒錯(cuò)錯(cuò)在剛開始集成方案設(shè)計(jì)的時(shí)候沒有把統(tǒng)一返回結(jié)構(gòu)作為第一條約定寫進(jìn)文檔里。后來我們把所有服務(wù)的接口契約單獨(dú)抽出來評(píng)審類似的問題基本在聯(lián)調(diào)前就消滅了。1.2 集成方案選型三種常見模式不同規(guī)模的項(xiàng)目集成的節(jié)奏完全不同。我梳理一下常見的三種模式你可以對(duì)照自己的項(xiàng)目情況選。第一種單體應(yīng)用內(nèi)部的模塊集成。這種其實(shí)最簡(jiǎn)單模塊之間直接方法調(diào)用不需要考慮網(wǎng)絡(luò)開銷和序列化問題。但它的陷阱在于模塊之間容易產(chǎn)生隱式依賴比如一個(gè)模塊直接改了另一個(gè)模塊的全局變量或者共享了一個(gè)靜態(tài)類。這種集成方式的重點(diǎn)在于“邊界意識(shí)”即使在一個(gè)進(jìn)程里也要把模塊之間的交互顯式化通過接口或者抽象類來解耦。第二種微服務(wù)架構(gòu)下的分布式集成。這種模式是目前大多數(shù)互聯(lián)網(wǎng)項(xiàng)目的標(biāo)配也是面試?yán)飭柕米疃嗟?。服?wù)之間通過HTTP或者消息隊(duì)列通信需要考慮網(wǎng)絡(luò)延遲、部分失敗、冪等、分布式事務(wù)等一堆問題。我剛帶項(xiàng)目的時(shí)候團(tuán)隊(duì)里的新人最容易犯的錯(cuò)誤是“同步調(diào)用一切”所有服務(wù)之間都是同步HTTP調(diào)用結(jié)果一個(gè)服務(wù)響應(yīng)慢了整個(gè)鏈路全部阻塞。后來我們引入消息隊(duì)列做異步解耦把不需要實(shí)時(shí)返回的操作全部改成異步整個(gè)系統(tǒng)的吞吐量上去了鏈路的穩(wěn)定性也好了很多。第三種第三方系統(tǒng)的外部集成。比如對(duì)接支付渠道、短信服務(wù)、地圖服務(wù)等。這種集成的關(guān)鍵在于適配層和防依賴腐化。你不能把第三方SDK直接在業(yè)務(wù)代碼里滿天飛一旦對(duì)方升級(jí)接口或者出了問題你的業(yè)務(wù)代碼就得跟著遭殃。正確做法是包一層自己的適配器把第三方的東西隔離在邊界之外。1.3 模塊之間的約定接口設(shè)計(jì)先行很多項(xiàng)目失敗的原因不是因?yàn)榇a寫得差而是因?yàn)榻涌谠O(shè)計(jì)得隨意。接口設(shè)計(jì)這件事必須放在編碼之前做而且要經(jīng)過評(píng)審不是誰寫了就算數(shù)。接口設(shè)計(jì)的基礎(chǔ)原則就那么幾條但每條都是血淚教訓(xùn)換來的。第一字段命名風(fēng)格統(tǒng)一要么全部小寫下劃線要么全部駝峰最怕混用。第二類型定義必須嚴(yán)謹(jǐn)比如金額必須用整數(shù)存分不能用浮點(diǎn)數(shù)存元心態(tài)崩沒崩過只有踩了坑的人知道。第三可選字段和必選字段要標(biāo)注清楚不能讓別人猜。第四錯(cuò)誤碼要有全局編號(hào)規(guī)則不能每個(gè)模塊自己從1開始編號(hào)聯(lián)調(diào)的時(shí)候會(huì)出現(xiàn)兩個(gè)服務(wù)返回同一個(gè)code但表達(dá)的意思完全不同的奇葩場(chǎng)景。我建議你在項(xiàng)目啟動(dòng)初期就建一個(gè)接口契約文檔用表格維護(hù)接口路徑、請(qǐng)求方法、入?yún)⒆侄?、類型、是否必填、出參結(jié)構(gòu)、錯(cuò)誤碼枚舉、超時(shí)閾值。這個(gè)文檔看起來費(fèi)時(shí)間但它就是集成階段的地圖。沒有地圖的集成就是瞎撞有了地圖聯(lián)調(diào)只是照著走一遍而已。2. 集成實(shí)操全流程2.1 環(huán)境準(zhǔn)備與分支策略集成開始之前先把環(huán)境問題解決好否則后面每個(gè)環(huán)節(jié)都會(huì)堵車。最常見的問題就是環(huán)境不統(tǒng)一有人用本地連測(cè)試庫(kù)有人用測(cè)試環(huán)境連開發(fā)庫(kù)還有人直接在本地跑所有的依賴服務(wù)。這種混亂狀態(tài)下出的問題排查起來非常痛苦因?yàn)楹芏鄷r(shí)候問題根本不在代碼邏輯上而是環(huán)境配置差異導(dǎo)致的行為不一致。我個(gè)人的習(xí)慣是用一個(gè)docker-compose把所有依賴的基礎(chǔ)設(shè)施在本地跑起來數(shù)據(jù)庫(kù)、緩存、消息隊(duì)列統(tǒng)一版本每個(gè)人拉下來就能跑通一套完整環(huán)境。然后線上環(huán)境再單獨(dú)部署一套保持和本地的依賴版本一致。這樣至少能保證“在我本地是好的”這句話盡量少出現(xiàn)。分支策略沒什么花哨的推薦采用dev → test → release的環(huán)境配套策略。開發(fā)分支dev開啟日常集成的自動(dòng)化驗(yàn)證允許代碼頻繁合并測(cè)試分支test部署到測(cè)試環(huán)境供前后端人員、測(cè)試人員使用release分支只接受驗(yàn)證通過的版本合并。這樣每個(gè)分支的角色清晰誰往哪個(gè)分支合并都有明確的依據(jù)不會(huì)出現(xiàn)順手把開發(fā)中的半成品放到測(cè)試環(huán)境去坑隊(duì)友的情況。2.2 接口聯(lián)調(diào)的節(jié)奏與方法聯(lián)調(diào)不是一個(gè)端點(diǎn)坐下來對(duì)接口就完事它是有節(jié)奏的。從我?guī)Ф鄠€(gè)項(xiàng)目的經(jīng)驗(yàn)來看聯(lián)調(diào)應(yīng)該分三輪走。第一輪是“契約聯(lián)調(diào)”也可以叫“靜態(tài)聯(lián)調(diào)”。這一輪不涉及真實(shí)邏輯只驗(yàn)證接口的請(qǐng)求和返回結(jié)構(gòu)符合契約。最簡(jiǎn)單的方式是讓后端把接口文檔生成出來前端用Mock數(shù)據(jù)先跑一遍確認(rèn)字段名、嵌套結(jié)構(gòu)、類型都正確。這個(gè)階段如果能配合一個(gè)接口文檔平臺(tái)自動(dòng)生成Mock效率會(huì)高很多。很多前端抱怨后端改字段根本原因是這輪沒做好等真實(shí)接口出來了才發(fā)現(xiàn)字段對(duì)不上那當(dāng)然要返工。第二輪是“功能聯(lián)調(diào)”也就是跑真實(shí)場(chǎng)景。前端調(diào)真實(shí)接口后端也開真實(shí)邏輯把完整的業(yè)務(wù)鏈路走通。這個(gè)階段的核心是“主鏈路優(yōu)先”先把核心流程跑通異常分支和邊界條件放在后面慢慢處理。我見過太多團(tuán)隊(duì)聯(lián)調(diào)時(shí)一個(gè)非核心的報(bào)錯(cuò)卡了兩天核心流程反而沒測(cè)最后上線日期到了核心鏈路還有一堆問題。第三輪是“異常聯(lián)調(diào)”專門驗(yàn)證異常場(chǎng)景。超時(shí)、限流、服務(wù)不可用、重復(fù)請(qǐng)求這些都要在這一輪覆蓋到。有人會(huì)問這些不是測(cè)試該做的嗎我必須強(qiáng)調(diào)一下測(cè)試確實(shí)會(huì)做但作為開發(fā)者在聯(lián)調(diào)階段自己先過一輪異常場(chǎng)景不僅能發(fā)現(xiàn)自己代碼里的防御邏輯缺漏也能順手驗(yàn)證降級(jí)方案是否真的生效而不是等到測(cè)試環(huán)境才靠運(yùn)氣發(fā)現(xiàn)。2.3 數(shù)據(jù)層集成的坑數(shù)據(jù)層集成是整個(gè)集成過程中最容易被低估的部分實(shí)際上它排坑耗時(shí)占比和難度遠(yuǎn)高于接口聯(lián)調(diào)。第一個(gè)坑數(shù)據(jù)庫(kù)表結(jié)構(gòu)變更沒有同步機(jī)制。兩個(gè)服務(wù)分別維護(hù)自己負(fù)責(zé)的表A服務(wù)改了某張表的名字B服務(wù)還在用舊名查詢一上線就一片雪上加霜。解決辦法是在集成方案里明確數(shù)據(jù)字典的變更通知流程任何表結(jié)構(gòu)變更必須同步到所有依賴方且要有兼容過渡期。第二個(gè)坑分布式事務(wù)。我見過很多剛接觸微服務(wù)的人一聽到分布式事務(wù)就頭大然后要么選擇“不做分布式事務(wù)”要么引入一堆分布式事務(wù)框架把系統(tǒng)搞得很重。實(shí)際上大多數(shù)業(yè)務(wù)場(chǎng)景根本不需要強(qiáng)一致阿里巴巴的經(jīng)典分類思路就是把“剛性事務(wù)”降級(jí)為“柔性事務(wù)”使用本地消息表或者事務(wù)消息去保證最終一致性。比如一個(gè)下單操作同時(shí)要扣庫(kù)存和生成訂單正確做法是先提交一個(gè)本地消息由異步任務(wù)去扣庫(kù)存扣成功的才把訂單狀態(tài)置為已支付。這個(gè)思路比引入強(qiáng)一致框架簡(jiǎn)潔得多也和大部分項(xiàng)目的實(shí)際需求匹配。第三個(gè)坑數(shù)據(jù)遷移和數(shù)據(jù)補(bǔ)償。歷史數(shù)據(jù)遷移到新表結(jié)構(gòu)之后業(yè)務(wù)代碼是否還兼容數(shù)據(jù)清洗跑完了要不要做比對(duì)補(bǔ)償任務(wù)掛在哪個(gè)調(diào)度平臺(tái)上失敗了重試幾次這些事不弄清楚就盲上集成生產(chǎn)環(huán)境的數(shù)據(jù)就會(huì)給你顏色看。3. 驗(yàn)證的價(jià)值與設(shè)計(jì)3.1 從單元測(cè)試到端到端測(cè)試的驗(yàn)證體系驗(yàn)證這件事不能只靠最后手工點(diǎn)一遍那不是驗(yàn)證那是碰運(yùn)氣。我這里的驗(yàn)證體系從低到高分為四層單元測(cè)試、接口測(cè)試、集成測(cè)試、端到端測(cè)試。單元測(cè)試驗(yàn)證一個(gè)函數(shù)、一個(gè)方法在給定輸入下產(chǎn)出正確輸出重點(diǎn)是覆蓋復(fù)雜邏輯分支而不是為了湊覆蓋率把每個(gè)getter、setter都測(cè)一遍。接口測(cè)試驗(yàn)證一個(gè)服務(wù)對(duì)外暴露的接口行為符合契約請(qǐng)求參數(shù)的有效性、返回碼的語(yǔ)義、異常分支的狀態(tài)流轉(zhuǎn)都在這里驗(yàn)證。集成測(cè)試驗(yàn)證多個(gè)服務(wù)協(xié)同是否正常通常是在測(cè)試環(huán)境拉起多服務(wù)走真實(shí)的數(shù)據(jù)流和調(diào)用鏈。端到端測(cè)試站在用戶視角模擬完整業(yè)務(wù)流程比如一個(gè)用戶從注冊(cè)到下單到支付到查詢訂單的全鏈路。這四層不是都要寫很多代碼而是按項(xiàng)目情況取舍。如果你是一個(gè)單體小項(xiàng)目單元測(cè)試加端到端測(cè)試就覆蓋得差不多了如果你是一個(gè)中大型分布式項(xiàng)目接口測(cè)試和集成測(cè)試的價(jià)值會(huì)更明顯。關(guān)鍵不是層數(shù)多而是“每一層驗(yàn)證的對(duì)象明確、反饋迅速”出了問題能快速定位是哪一層的鍋。3.2 自動(dòng)化測(cè)試的取舍與經(jīng)濟(jì)性我必須潑一盆冷水自動(dòng)化測(cè)試不是越多越好。很多團(tuán)隊(duì)把覆蓋率當(dāng)成KPI強(qiáng)行把覆蓋率從40%拉到80%結(jié)果代碼里全是低價(jià)值的斷言真正核心的鏈路反而沒人測(cè)。這種自動(dòng)化是虛假繁榮。我自己的取舍標(biāo)準(zhǔn)有三個(gè)。第一核心邏輯必須測(cè)。涉及金額計(jì)算、狀態(tài)流轉(zhuǎn)、權(quán)限判斷、數(shù)據(jù)唯一性約束的邏輯不測(cè)就是在賭。第二復(fù)雜分支必須測(cè)。一個(gè)方法里有五個(gè)if嵌套你不給每個(gè)分支寫測(cè)試后面的維護(hù)者改一個(gè)條件就要提心吊膽。第三重構(gòu)頻繁的模塊必須測(cè)。這是為未來的自己省時(shí)間重構(gòu)完跑一遍測(cè)試比手動(dòng)點(diǎn)功能點(diǎn)效率高得多。有一個(gè)層面很少被提到就是“回滾保護(hù)”。自動(dòng)化測(cè)試在工作實(shí)踐中最大的價(jià)值不是你寫完代碼后跑一遍通過了而是你或者別人某一天改代碼的時(shí)候測(cè)試能把改壞的功能揪出來。這個(gè)“回歸保護(hù)”的價(jià)值往往比驗(yàn)證當(dāng)次功能是否正確更大。3.3 性能、異常與安全性驗(yàn)證集成階段最容易忽略的就是性能驗(yàn)證。很多系統(tǒng)在少量數(shù)據(jù)、低并發(fā)測(cè)試下看起來一切正常一上線就扛不住流量接口一個(gè)接一個(gè)超時(shí)。性能驗(yàn)證不一定要用復(fù)雜的壓測(cè)工具最基本的一個(gè)壓測(cè)工具用起來模擬比預(yù)估峰值高的并發(fā)數(shù)跑一跑關(guān)鍵接口觀察響應(yīng)時(shí)間的變化趨勢(shì)和錯(cuò)誤率能暴露出很多設(shè)計(jì)上的瓶頸比如數(shù)據(jù)庫(kù)連接池不夠、某個(gè)接口存在嚴(yán)重的N1查詢、緩存沒生效等。異常驗(yàn)證也要專門設(shè)計(jì)。熔斷、降級(jí)、重試、超時(shí)這四件套不能只在代碼評(píng)審里講“我加了重試”得上線驗(yàn)證重試多少次、退避策略是什么、會(huì)不會(huì)打爆下游。最經(jīng)典的例子就是重試風(fēng)暴A服務(wù)超時(shí)后立刻重試3次B服務(wù)也超時(shí)也重試3次C服務(wù)直接被打掛。這種問題只有真正壓過一次或者演練一次才心里有數(shù)。安全驗(yàn)證這塊接口層面的鑒權(quán)、越權(quán)、SQL注入、敏感數(shù)據(jù)脫敏測(cè)試用例里必須覆蓋。我見過一個(gè)項(xiàng)目在集成測(cè)試階段發(fā)現(xiàn)訂單詳情的接口只要把訂單ID從1改成2就能查到別人的訂單原因就是僅校驗(yàn)登錄態(tài)、未校驗(yàn)數(shù)據(jù)歸屬。這類問題在功能測(cè)試?yán)锿ǔy(cè)不出來必須專門設(shè)計(jì)越權(quán)用例。4. 面試題精講從知識(shí)到實(shí)戰(zhàn)4.1 面試官真正想考察的三種能力面試題尤其是集成和驗(yàn)證相關(guān)的問題表面上考的是知識(shí)點(diǎn)實(shí)際上考察的是三種底層能力。第一種整體設(shè)計(jì)能力。面試官給你一個(gè)場(chǎng)景問你“怎么做集成方案”不是要你背誦微服務(wù)理論而是你能不能cover住全局哪些是核心流程、哪些可以異步化、接口怎么劃分、異常怎么兜底。這個(gè)能力來自于你真正帶過模塊、處理過集成沖突的經(jīng)驗(yàn)而不是看了幾篇技術(shù)博客就能吹出來的。第二種權(quán)衡與決策能力。面試?yán)锝?jīng)常問“你項(xiàng)目里為什么用消息隊(duì)列不用直接調(diào)用”“為什么用最終一致性而不用強(qiáng)一致”本質(zhì)上就是看你有沒有做過思考、有沒有在幾種方案之間比較過優(yōu)缺。回答時(shí)最忌諱只講好處不講代價(jià)任何技術(shù)選型都有代價(jià)能講清楚代價(jià)才說明你真的想過。第三種問題排查能力。面試官問“你線上遇到的最難排查的問題是什么”不是真想聽一個(gè)高分故事而是看你的排查思路是否系統(tǒng)有沒有先懷疑環(huán)境、再懷疑配置、再看日志、再加監(jiān)控最后定位到代碼而不是瞎猜。4.2 高頻核心問題拆解我整理了幾個(gè)集成與驗(yàn)證方向的高頻面試題每個(gè)都附上回答思路供你參考。問題一服務(wù)A調(diào)用服務(wù)B超時(shí)你會(huì)怎么排查很多人的第一反應(yīng)是“看B的日志”這個(gè)沒錯(cuò)但不夠系統(tǒng)。我的回答會(huì)分層次先確認(rèn)超時(shí)是發(fā)生在連接階段還是讀取階段連接階段大概率是網(wǎng)絡(luò)或者服務(wù)不可用讀取階段大概率是B處理慢或者線程池被打滿再看A的重試配置會(huì)不會(huì)放大問題A的超時(shí)時(shí)間設(shè)置是否合理然后看B的監(jiān)控面板接口耗時(shí)分布、線程池活躍度、數(shù)據(jù)庫(kù)慢查詢最后根據(jù)現(xiàn)象判斷是代碼性能問題、資源不足還是依賴下游慢導(dǎo)致的雪崩?；卮鸢雅挪槁窂绞崂硗瓿杀戎苯咏o出一個(gè)“正確答案”更能打動(dòng)面試官。問題二你們項(xiàng)目的集成測(cè)試是怎么做的這個(gè)問題要結(jié)合自己的項(xiàng)目具體說不能空談理論。你可以從環(huán)境搭建、數(shù)據(jù)準(zhǔn)備、自動(dòng)化手段、人工補(bǔ)充這四個(gè)角度展開。重點(diǎn)突出你曾經(jīng)在集成階段發(fā)現(xiàn)過一個(gè)有代表性的問題然后是怎么定位、怎么解決的。這類帶真實(shí)細(xì)節(jié)的回答比背誦測(cè)試金字塔定義有用一百倍。問題三服務(wù)注冊(cè)發(fā)現(xiàn)、配置中心在集成中扮演什么角色這個(gè)問題考的是你對(duì)“基礎(chǔ)設(shè)施”的理解。我的思路是這些組件解決的是“動(dòng)態(tài)變化”的問題——服務(wù)實(shí)例上下線、配置變更、路由流量調(diào)整。集成過程中服務(wù)地址會(huì)經(jīng)常變不可能靠手工改配置維護(hù)配置中心讓不同環(huán)境的配置隔離清晰避免把測(cè)試環(huán)境的配置帶到線上注冊(cè)發(fā)現(xiàn)讓系統(tǒng)對(duì)實(shí)例變化敏感故障時(shí)能摘流量?；卮饡r(shí)能結(jié)合具體場(chǎng)景講一個(gè)故障案例會(huì)更有說服力。4.3 場(chǎng)景設(shè)計(jì)題的回答框架面試中的場(chǎng)景設(shè)計(jì)題比如“讓你設(shè)計(jì)一個(gè)訂單超時(shí)關(guān)閉系統(tǒng)”本質(zhì)上就是讓你現(xiàn)場(chǎng)做集成方案。我摸索出一個(gè)通用的四步回答框架屢試不爽。第一步確認(rèn)約束問清楚關(guān)鍵場(chǎng)景。比如單量多大、超時(shí)時(shí)間多久、是否需要實(shí)時(shí)性、失敗后如何處理。這一步很重要很多人上來就畫架構(gòu)圖結(jié)果跟面試官期望的方向完全不一樣。第二步識(shí)別核心鏈路畫主線。從用戶下單開始到超時(shí)檢測(cè)到狀態(tài)變更到后續(xù)補(bǔ)償把主干看清楚。第三步拆解選型逐個(gè)說明“為什么”。延遲消息隊(duì)列、定時(shí)任務(wù)輪詢、時(shí)間輪各有什么優(yōu)劣為什么在你的場(chǎng)景里選這個(gè)。每說一個(gè)選型主動(dòng)說出它的代價(jià)。第四步談異常降級(jí)展示邊界思考。消息積壓怎么辦、服務(wù)重啟任務(wù)丟失怎么辦、重復(fù)關(guān)閉訂單怎么冪等。能主動(dòng)把這些講出來就是加分項(xiàng)。這個(gè)框架的精髓在于“把問題拆小”。一個(gè)很宏大的設(shè)計(jì)題拆成約束確認(rèn)、主鏈路、選型、異常四個(gè)部分之后每個(gè)部分的復(fù)雜度都會(huì)降一個(gè)級(jí)別回答起來從容得多。4.4 手寫代碼題與HR面的關(guān)鍵提醒手寫代碼題主要集中在接口實(shí)現(xiàn)、線程安全、數(shù)據(jù)一致性這類細(xì)節(jié)上。我見過不少面試者架構(gòu)講得頭頭是道一寫到單例模式或者多線程就磕磕絆絆。核心原因在于“讀代碼”和“寫代碼”是兩種不同的能力平時(shí)自己上手敲得少。建議你在準(zhǔn)備面試前把數(shù)據(jù)結(jié)構(gòu)、并發(fā)編程、緩存一致性這些基礎(chǔ)代碼題手寫練一遍不是看一眼就過是真正在編輯器里敲出來然后運(yùn)行驗(yàn)證。到了HR面很多人以為要收起技術(shù)感其實(shí)也不對(duì)。HR面更關(guān)注的是你的溝通表達(dá)、做事方式、價(jià)值觀。比如“你最近遇到的一個(gè)困難是什么”你沒有真實(shí)經(jīng)歷過的話編出來的故事一聽就假面試官稍微追問細(xì)枝末節(jié)就露餡。誠(chéng)實(shí)講一件小事說清楚背景、思路、行動(dòng)和結(jié)果比編造一個(gè)跌宕起伏的劇本可靠得多。還有一個(gè)要點(diǎn)是HR面不要只講技術(shù)還要體現(xiàn)你如何推動(dòng)協(xié)作、如何向上同步風(fēng)險(xiǎn)、如何在團(tuán)隊(duì)里處理分歧這些軟素質(zhì)在后面的團(tuán)隊(duì)協(xié)作中往往比技術(shù)本身更關(guān)鍵。5. 常見問題與排查技巧實(shí)錄5.1 集成過程中的典型問題速查表這一節(jié)我把這些年集成階段遇到過的、具有代表性的問題按“現(xiàn)象—原因—解法”的維度整理成速查表你可以直接拿去做排查手冊(cè)?，F(xiàn)象典型原因解決思路接口聯(lián)調(diào)時(shí)字段總是對(duì)不上接口契約文檔與實(shí)際代碼不同步用接口平臺(tái)維護(hù)契約代碼變更觸發(fā)文檔自動(dòng)更新強(qiáng)制評(píng)審測(cè)試環(huán)境一會(huì)好一會(huì)壞多人共用環(huán)境導(dǎo)致互相影響引入環(huán)境隔離或租戶隔離重要流程在獨(dú)立環(huán)境驗(yàn)證服務(wù)啟動(dòng)報(bào)端口占用本地起多個(gè)服務(wù)實(shí)例沖突用docker-compose統(tǒng)一規(guī)劃端口映射避免隨機(jī)端口調(diào)用下游偶爾超時(shí)線程池配置過小或下游GC停頓壓測(cè)確認(rèn)線程池水位優(yōu)化GC參數(shù)并配置合理的超時(shí)重試數(shù)據(jù)庫(kù)死鎖偶現(xiàn)多個(gè)事務(wù)加鎖順序不一致統(tǒng)一加鎖順序優(yōu)化事務(wù)范圍必要時(shí)引入分布式鎖數(shù)據(jù)重復(fù)插入接口未實(shí)現(xiàn)冪等增加冪等表或唯一索引同一請(qǐng)求用唯一業(yè)務(wù)鍵去重接口返回成功但業(yè)務(wù)未執(zhí)行異步消息丟失或消費(fèi)失敗增加消息本地表、消費(fèi)記錄表和補(bǔ)償任務(wù)日志串聯(lián)不上缺少統(tǒng)一的traceId傳遞在網(wǎng)關(guān)生成traceId通過攔截器透?jìng)鞯剿邢掠握{(diào)用5.2 排查問題的三段式方法排查問題最忌“猜測(cè)驅(qū)動(dòng)”也就是“我猜是這里有問題改一下試試不行再改”。這種碰運(yùn)氣式的排查碰到簡(jiǎn)單問題還行碰到復(fù)雜問題會(huì)一直原地打轉(zhuǎn)最后改出一堆新bug。我自己的排查動(dòng)作基本固定為三段。第一段收集證據(jù)。先把日志、監(jiān)控、鏈路追蹤、報(bào)錯(cuò)堆棧全部拉出來確認(rèn)問題的現(xiàn)象到底是什么。很多時(shí)候開發(fā)者在口頭描述“它掛了”時(shí)掛的模式千差萬別是超時(shí)、是報(bào)錯(cuò)、是數(shù)據(jù)錯(cuò)、還是性能慢必須用數(shù)據(jù)把現(xiàn)象釘死。第二段縮小范圍。用二分法把可能出問題的環(huán)節(jié)縮小到某一個(gè)確定的層級(jí)。比如前端報(bào)一個(gè)接口500先確認(rèn)是網(wǎng)關(guān)攔截了還是服務(wù)拋異常再確認(rèn)是Controller層的問題還是Service層的問題再確認(rèn)是代碼邏輯還是數(shù)據(jù)庫(kù)層面。每縮小一步都要有一個(gè)證據(jù)支撐。第三段驗(yàn)證根因。找到嫌疑點(diǎn)后不要急著改代碼。先在測(cè)試環(huán)境復(fù)現(xiàn)一次確認(rèn)根因成立再動(dòng)手修。修完之后再把修復(fù)前后的現(xiàn)象對(duì)比一次防止改出回歸問題。這套流程看起來很樸素但效率極高能保證你所有的改動(dòng)都是基于事實(shí)而不是想象。5.3 我在實(shí)際集成中養(yǎng)成的幾個(gè)習(xí)慣最后一個(gè)部分分享幾個(gè)我一直在用的習(xí)慣它們不是某個(gè)具體的工具或技巧而是做事的方法。第一個(gè)習(xí)慣永遠(yuǎn)在開始前留出15%的緩沖時(shí)間。集成和驗(yàn)證階段的不可預(yù)測(cè)性遠(yuǎn)超編碼階段你以為一天能搞定的聯(lián)調(diào)實(shí)操中因?yàn)榄h(huán)境問題耗掉三天也不罕見。所以做項(xiàng)目排期時(shí)集成階段的時(shí)間一定要留足緩沖不然后面要么趕工刪功能要么熬夜填坑。第二個(gè)習(xí)慣集成階段每天跑一遍全量自動(dòng)化測(cè)試。不要等到提交前才跑那時(shí)候發(fā)現(xiàn)問題往往已經(jīng)晚了。每天跑一次能盡早發(fā)現(xiàn)環(huán)境變動(dòng)或者新改動(dòng)對(duì)已有功能的破壞。第三個(gè)習(xí)慣任何一次線上問題的修復(fù)都必須輸出復(fù)盤記錄。不用寫長(zhǎng)篇大論就寫清楚現(xiàn)象、根因、修復(fù)方案、預(yù)防措施。這樣每一篇都是一份寶貴的排查資料下次遇到類似問題直接查自己的復(fù)盤記錄基本上能省掉一半的排查時(shí)間。6. 從項(xiàng)目到面試的認(rèn)知升級(jí)回到第07講的主題“集成、驗(yàn)證與面試題精講”你會(huì)發(fā)現(xiàn)集成考驗(yàn)的是你對(duì)模塊邊界的理解能力驗(yàn)證考驗(yàn)的是你對(duì)確定性的執(zhí)著程度面試題考驗(yàn)的是你有沒有把前兩者內(nèi)化成自己的經(jīng)驗(yàn)。我在實(shí)際帶項(xiàng)目時(shí)最欣慰的時(shí)刻不是功能上線而是團(tuán)隊(duì)里有人開始主動(dòng)問我“我們這兩個(gè)模塊的接口契約是不是該先評(píng)審一下”或者“這個(gè)異常的測(cè)試用例要不要補(bǔ)上”。當(dāng)一個(gè)人開始主動(dòng)關(guān)注集成邊界、主動(dòng)驗(yàn)證異常分支時(shí)他就已經(jīng)不是在“完成任務(wù)”而是在“把一件事做成”。對(duì)于正在準(zhǔn)備面試的人我的建議是不要背題要把每一個(gè)高頻問題拿到自己的項(xiàng)目里去對(duì)照一遍問自己我的項(xiàng)目里這個(gè)場(chǎng)景是怎么做的如果重新來一次我會(huì)做哪些不同選擇這樣準(zhǔn)備出來的回答每一句都來自真實(shí)經(jīng)驗(yàn)面試官一聽就感覺得到。最后再分享一個(gè)小技巧面試?yán)锊还苡龅绞裁磫栴}先停頓三秒再回答。這三秒不是用來緊張的是用來整理結(jié)構(gòu)的先說結(jié)論、再講理由、最后補(bǔ)充例外情況。這個(gè)習(xí)慣會(huì)讓你所有的回答都顯得有條理、有深度。