Caveman直譯過(guò)來(lái)就是“穴居人”。平時(shí)要是聽(tīng)到有人說(shuō)你“寫(xiě)代碼寫(xiě)成了 caveman 風(fēng)格”別急著覺(jué)得這是在罵人——這行里它還真不是什么貶義詞反而指的是一種特別珍貴的思維模式丟掉花架子回到最原始、最樸素的工具和方法去硬碰硬地解決問(wèn)題。這篇東西不打算介紹某個(gè)叫 Caveman 的開(kāi)源框架我想聊的是我自己實(shí)踐了很多年的“原始人開(kāi)發(fā)哲學(xué)”以及它怎么一次次把我從復(fù)雜到離譜的技術(shù)深坑里撈出來(lái)。說(shuō)白了Caveman 思維就是遇到問(wèn)題先別急著上框架、上中間件、上各種高階特性先想想如果手上只有一把石斧這個(gè)問(wèn)題該怎么砸開(kāi)。聽(tīng)起來(lái)很簡(jiǎn)單但大多數(shù)人都做不到——因?yàn)槲覀兌继矚g“升級(jí)工具”了一碰到麻煩就想著再加一層?xùn)|西而不是想著怎么少一層?xùn)|西。這篇內(nèi)容適合所有被復(fù)雜系統(tǒng)折磨過(guò)的開(kāi)發(fā)者也適合剛?cè)胄小⒄诒桓鞣N“最佳實(shí)踐”勸退的新人。我會(huì)把我踩過(guò)的坑、試過(guò)的笨辦法、最后留下來(lái)的真正好用的套路全部攤開(kāi)講。1. Caveman到底是什么一種被低估的開(kāi)發(fā)哲學(xué)1.1 從“穴居人”到技術(shù)圈黑話Caveman調(diào)試法在英文技術(shù)社區(qū)里Caveman Debugging穴居人調(diào)試法是一個(gè)流傳了很久的黑話指的是整個(gè)行業(yè)發(fā)展了一大圈之后大家發(fā)現(xiàn)最可靠的調(diào)試手段還是最基礎(chǔ)的那幾樣在代碼里插入日志、把變量打出來(lái)、做個(gè)簡(jiǎn)單的斷點(diǎn)甚至直接在瀏覽器里console.log一下看結(jié)果。你想想一個(gè)在山洞里圍著火堆烤肉的原始人想判斷眼前那塊肉到底熟沒(méi)熟他會(huì)怎么做切開(kāi)看。換成我們?nèi)ヅ挪橐粋€(gè)接口返回的數(shù)據(jù)為什么不對(duì)第一反應(yīng)也應(yīng)該是一樣的——把實(shí)際返回的東西打出來(lái)看一眼而不是坐在那對(duì)著三層抽象框架猜。這套思路之所以被叫作“Caveman”是因?yàn)樗_實(shí)原始得有點(diǎn)“返祖”了?，F(xiàn)代開(kāi)發(fā)工具已經(jīng)進(jìn)化到可以在 IDE 里跑復(fù)雜的斷點(diǎn)表達(dá)式、可以做全鏈路追蹤、可以靠 APM 平臺(tái)自動(dòng)分析性能瓶頸但真到了線上環(huán)境很多時(shí)候這些精密儀器反而用不上生產(chǎn)環(huán)境沒(méi)有調(diào)試端口分布式日志鏈路七拐八彎你以為看的是完整調(diào)用鏈結(jié)果只抓到半截。這時(shí)候那個(gè)“穴居人”跳了出來(lái)用最笨的辦法——在關(guān)鍵位置打一行日志重啟等待看輸出——把真相從迷宮一樣的系統(tǒng)深處拖出來(lái)。我在真實(shí)的項(xiàng)目里見(jiàn)過(guò)太多次這種情況兩個(gè)服務(wù)聯(lián)調(diào)A 服務(wù)說(shuō)“我發(fā)過(guò)去了”B 服務(wù)說(shuō)“我沒(méi)收到”兩邊各自拿出自己那套鏈路追蹤截圖吵了半小時(shí)。最后我上去把 B 服務(wù)入口的一行日志打開(kāi)三分鐘后結(jié)論就出來(lái)了——不是沒(méi)收到是收到的報(bào)文里某個(gè)字段被網(wǎng)關(guān)改寫(xiě)成了空串鏈路系統(tǒng)里看到的“正常”根本不是真正落地之后的數(shù)據(jù)。這就是 Caveman Debugging 的威力跳過(guò)所有中間解釋直接去看系統(tǒng)最原始的那層輸出。1.2 為什么現(xiàn)代的我們?nèi)匀恍枰霸既怂季S”你可能覺(jué)得奇怪理論上說(shuō)工具越先進(jìn)人應(yīng)該越不需要返祖才對(duì)。但現(xiàn)實(shí)恰恰相反——系統(tǒng)越復(fù)雜抽象層越多“原始人思維”的價(jià)值就越大。原因其實(shí)不難理解因?yàn)槊恳粚映橄蟊举|(zhì)上都是在“替你干活”同時(shí)也在“替你隱瞞真相”。你用了一個(gè)很高級(jí)的 ORM它幫你把 SQL 生成了你就不用看 SQL 了問(wèn)題是當(dāng)性能出問(wèn)題的時(shí)候你根本不知道它生成的 SQL 到底長(zhǎng)什么樣。你用了一個(gè)很牛的消息隊(duì)列它幫你屏蔽了底層 broker 的細(xì)節(jié)你就不用管消息到底存在哪了問(wèn)題是消息丟失的時(shí)候你連從哪開(kāi)始查都不知道。Caveman 思維的核心就是在適當(dāng)?shù)臅r(shí)候主動(dòng)放棄這些便利回到“親眼看見(jiàn)證據(jù)”的原始狀態(tài)。我自己有一個(gè)習(xí)慣無(wú)論用再高級(jí)的框架我要求自己必須能回答三個(gè)最基本的問(wèn)題——數(shù)據(jù)從哪來(lái)在哪個(gè)環(huán)節(jié)被改過(guò)最后落到哪。這三個(gè)問(wèn)題里的任何一個(gè)如果我是靠“猜”而不是靠“看得見(jiàn)的東西”回答的那離出事故就不遠(yuǎn)了。這種習(xí)慣聽(tīng)起來(lái)很土但它救過(guò)我很多次而且越是在高并發(fā)、微服務(wù)、多團(tuán)隊(duì)協(xié)作的復(fù)雜環(huán)境里它越能救命。2. 核心方法論像原始人一樣把復(fù)雜拆掉2.1 最小化Caveman哲學(xué)的第一性原理原始人為什么活得好好的因?yàn)樗麄兊男枨髽O其有限有火、有吃的、有能躲雨的山洞。他們的所有工具都圍繞這些最核心的需求展開(kāi)多余的東西一概不要。放到我們寫(xiě)代碼這件事上這個(gè)原理就是能用單模塊解決的就不要拆微服務(wù)能用普通函數(shù)解決的就不要上設(shè)計(jì)模式能用數(shù)據(jù)庫(kù)一張表解決的就不要搞一套搜索引擎加緩存的組合拳。我見(jiàn)過(guò)一個(gè)特別典型的反面案例。一個(gè)團(tuán)隊(duì)要做一個(gè)內(nèi)部后臺(tái)的搜索功能數(shù)據(jù)量也就幾萬(wàn)條結(jié)果一上來(lái)就上了 Elasticsearch、Redis 緩存、消息隊(duì)列異步同步整套組合拳打完功能是上線了但團(tuán)隊(duì)三個(gè)人花了兩周時(shí)間維護(hù)這套鏈路。后來(lái)我?guī)退麄兛戳艘谎壑苯訐Q成了數(shù)據(jù)庫(kù)自帶的全文索引再配合一個(gè)簡(jiǎn)單的 LIKE 查詢兜底總共改了不到 200 行代碼查詢速度從 1 秒變成了 20 毫秒部署架構(gòu)簡(jiǎn)化到只需要一臺(tái)實(shí)例。這里我不是說(shuō) Elasticsearch 不好而是說(shuō)在這個(gè)規(guī)模下Elasticsearch 完全是用來(lái)打蚊子的牛刀。Caveman 思維要求你先問(wèn)一個(gè)問(wèn)題這個(gè)場(chǎng)景的本質(zhì)需求是什么答案如果是“在一個(gè)小數(shù)據(jù)集里做簡(jiǎn)單檢索”那最簡(jiǎn)單的方式就是最優(yōu)解再炫酷的技術(shù)都得往后排。2.2 二分法找蟲(chóng)子最快的方式就是折半搜索原始人在山洞里丟了火種他會(huì)怎么找不大可能把整個(gè)山洞翻個(gè)底朝天而是先判斷“到底是在內(nèi)半段還是外半段丟的”然后一步步縮小范圍。這就是二分法。在調(diào)試的時(shí)候二分法是最典型的 Caveman 式手段而且效率高得驚人。具體操作也很簡(jiǎn)單。接到一個(gè) bug 報(bào)告先別急著從頭到尾讀代碼先確定一個(gè)口號(hào)問(wèn)題出在哪一段如果你有一個(gè)完整的函數(shù)調(diào)用鏈從 A 到 B 到 C 到 D最后結(jié)果不對(duì)你可以先在 C 的入口處打一個(gè)日志看運(yùn)行到這里的時(shí)候數(shù)據(jù)是不是已經(jīng)錯(cuò)了。如果 C 入口的數(shù)據(jù)就是錯(cuò)的說(shuō)明問(wèn)題出在 A 或者 B如果 C 入口的數(shù)據(jù)是對(duì)的那問(wèn)題就在 C 或者 D。一番操作下來(lái)排查范圍直接縮小一半每一步都在逼近真相。我講一個(gè)真實(shí)案例。線上有一個(gè)訂單狀態(tài)流轉(zhuǎn)異常用戶支付成功后訂單沒(méi)有變成“已支付”。整個(gè)流程涉及前端回調(diào)、網(wǎng)關(guān)、訂單服務(wù)、支付回調(diào)、消息隊(duì)列總共五個(gè)環(huán)節(jié)。我一開(kāi)始也想著用全鏈路追蹤平臺(tái)拉一下結(jié)果發(fā)現(xiàn)日志在不同服務(wù)里格式不統(tǒng)一追蹤 ID 斷了根本串不起來(lái)。后來(lái)我老老實(shí)實(shí)用了二分法先在訂單服務(wù)收到消息隊(duì)列消息的那一刻打日志結(jié)果發(fā)現(xiàn)根本沒(méi)收到消息那問(wèn)題就不在訂單服務(wù)本身。接著往上游推看網(wǎng)關(guān)是否正確把回調(diào)轉(zhuǎn)發(fā)到了消息生產(chǎn)者結(jié)果發(fā)現(xiàn)網(wǎng)關(guān)那邊回調(diào)成功但生產(chǎn)者發(fā)送消息時(shí)拋了個(gè)不太起眼的異常被 try-catch 吞掉了。整個(gè)定位過(guò)程不到十分鐘總共就加了三行日志。這就是二分法的力量——它不依賴復(fù)雜的工具鏈只依賴你分清楚“上下左右”的耐心。2.3 直接性繞過(guò)間接層解決問(wèn)題Caveman 思維里還有一個(gè)容易被忽略的品質(zhì)直接。原始人想生火不會(huì)先去研究復(fù)雜的鉆木取火工具結(jié)構(gòu)而是直接找兩塊石頭打火。對(duì)應(yīng)到代碼上就是如果需要確認(rèn)一個(gè)服務(wù)的返回結(jié)果直接調(diào)用它的 API 看返回而不是通過(guò)前端 UI 去“間接驗(yàn)證”如果需要判斷數(shù)據(jù)庫(kù)里到底有沒(méi)有記錄直接進(jìn)數(shù)據(jù)庫(kù)查而不是通過(guò) ORM 的調(diào)試輸出猜。特別多人在排查問(wèn)題的時(shí)候習(xí)慣順著自己熟悉的那條路走——比如一個(gè)前端同學(xué)遇到數(shù)據(jù)不對(duì)第一反應(yīng)是在瀏覽器里打斷點(diǎn)看前端代碼邏輯一個(gè)后端同學(xué)遇到接口報(bào)錯(cuò)第一反應(yīng)是去查后端的異常堆棧。這沒(méi)有錯(cuò)但如果能跨過(guò)“自己熟悉的那一層”直接去驗(yàn)證問(wèn)題真正可能最早出現(xiàn)的那一層往往效率更高。有一回我遇到一個(gè)圖片上傳失敗的問(wèn)題前端報(bào)錯(cuò)后端的日志顯示收到了請(qǐng)求但返回了 500。兩個(gè)同事分別在各自的環(huán)境里查了一個(gè)小時(shí)一個(gè)在看 JS 的 FormData 拼接一個(gè)在看服務(wù)端的上傳解析庫(kù)版本。我過(guò)去之后直接問(wèn)了句那臺(tái)存儲(chǔ)服務(wù)器的磁盤(pán)滿了沒(méi)有一查果然滿了。一個(gè)很直接、很原始的問(wèn)題被兩個(gè)人在間接層里猜了半天。很多時(shí)候真相就擺在那里你要做的只是別繞路。3. 實(shí)操Caveman式調(diào)試與修復(fù)全程實(shí)錄3.1 場(chǎng)景一上線后接口超時(shí)我是怎么用print定位的事情是這樣的一個(gè)對(duì)外提供的查詢接口在壓測(cè)環(huán)境一切正常上線之后一到晚高峰就開(kāi)始超時(shí)監(jiān)控面板上看 CPU 不高、內(nèi)存不緊張就是慢。當(dāng)時(shí)團(tuán)隊(duì)里的方案是先上鏈路追蹤看看是不是下游調(diào)用變慢我攔住他們說(shuō)別急先把一個(gè)最原始的問(wèn)題搞清楚請(qǐng)求進(jìn)來(lái)之后到底在哪個(gè)環(huán)節(jié)耗時(shí)最多。我先在這個(gè)接口的入口加了一行時(shí)間戳日志# 在Web框架的入口處做最樸素的耗時(shí)記錄 start time.time() # ... 原有查詢邏輯 ... logger.info(query finished, total cost: %.4f s, time.time() - start)結(jié)果發(fā)現(xiàn)整體耗時(shí)確實(shí)接近 3 秒接下來(lái)繼續(xù)二分直接在查詢函數(shù)前后各打一行時(shí)間戳。加完之后發(fā)現(xiàn)在數(shù)據(jù)庫(kù)查詢這一步就已經(jīng)耗掉了 2.6 秒。再往下拆把 SQL 原樣打到日志里拿到那臺(tái)數(shù)據(jù)庫(kù)實(shí)例上去用 EXPLAIN 執(zhí)行一下發(fā)現(xiàn)命中的查詢條件沒(méi)有走索引全表掃描了一張上百萬(wàn)行的表。問(wèn)題至此水落石出壓測(cè)環(huán)境的數(shù)據(jù)量小全表掃描也能秒回線上數(shù)據(jù)量一上來(lái)問(wèn)題就暴露了。整個(gè)過(guò)程沒(méi)有用任何高大上的 APM 工具就是幾行 print 加一條 EXPLAIN。這件事給我的啟發(fā)是在很多性能問(wèn)題里真正的瓶頸并不會(huì)藏在“高級(jí)工具才能發(fā)現(xiàn)”的地方它就是那么樸素地待在那——一張沒(méi)有索引的表、一個(gè)沒(méi)帶條件的分頁(yè)查詢、一次循環(huán)里的遠(yuǎn)程調(diào)用。你要做的不是把工具刷滿而是愿意蹲下來(lái)一行日志一行日志地把耗時(shí)看清楚。3.2 場(chǎng)景二一次詭異數(shù)據(jù)丟失最后靠“原始人筆記”解決的還有一次是半夜收到告警說(shuō)某個(gè)批處理任務(wù)的數(shù)據(jù)比預(yù)期少了一部分。我們那套批處理任務(wù)鏈路特別長(zhǎng)定時(shí)觸發(fā)器 - 任務(wù)調(diào)度平臺(tái) - 業(yè)務(wù)代碼 - 分布式緩存 - 數(shù)據(jù)庫(kù)批量寫(xiě)入。一開(kāi)始懷疑是調(diào)度平臺(tái)漏觸發(fā)又懷疑是緩存過(guò)期策略太激進(jìn)整個(gè)團(tuán)隊(duì)在群里猜了一晚上各種理論層出不窮。我凌晨爬起來(lái)做了一件事把原始人筆記拿了出來(lái)——一本實(shí)體筆記本一支筆我開(kāi)始一條一條地列“已知事實(shí)”。第一任務(wù)確實(shí)被觸發(fā)了因?yàn)檎{(diào)度平臺(tái)有記錄第二業(yè)務(wù)代碼確實(shí)跑完了因?yàn)槿罩纠镉薪Y(jié)束標(biāo)記第三寫(xiě)入的數(shù)據(jù)量比預(yù)期少因?yàn)樽罱K數(shù)據(jù)庫(kù)統(tǒng)計(jì)對(duì)不上。這三個(gè)已知事實(shí)一列問(wèn)題范圍立刻從“整條鏈路”縮小到了“業(yè)務(wù)代碼內(nèi)部的數(shù)據(jù)處理環(huán)節(jié)”。于是我重新去讀業(yè)務(wù)代碼里那段數(shù)據(jù)轉(zhuǎn)換邏輯發(fā)現(xiàn)里面有一個(gè)很隱蔽的過(guò)濾條件它會(huì)把某個(gè)狀態(tài)碼的數(shù)據(jù)剔除掉而這個(gè)狀態(tài)碼的數(shù)據(jù)恰好那天的上游接入了新格式。兩邊一核對(duì)上游確實(shí)把狀態(tài)碼寫(xiě)成了新值而我們的過(guò)濾條件還停留在舊值。問(wèn)題解決用時(shí)不到 20 分鐘。事后復(fù)盤(pán)真正起作用的不是任何技術(shù)工具而是那個(gè)“把已知事實(shí)一條條列下來(lái)”的原始習(xí)慣。那本筆記到現(xiàn)在我都還在用——不是因?yàn)樗男矢叨且驗(yàn)楫?dāng)大腦被一堆相互矛盾的猜測(cè)塞滿的時(shí)候?qū)懺诩埳系陌准埡谧直热魏?IDE 的調(diào)試器更能讓人冷靜下來(lái)。3.3 場(chǎng)景三面對(duì)“微服務(wù)全家桶”Caveman式架構(gòu)評(píng)審前兩年我和幾個(gè)朋友一起參與評(píng)審過(guò)一個(gè)新項(xiàng)目的架構(gòu)設(shè)計(jì)。那個(gè)項(xiàng)目的規(guī)模說(shuō)實(shí)話很小預(yù)估 QPS 不到 50業(yè)務(wù)模型也就兩三個(gè)核心對(duì)象。但架構(gòu)師給出來(lái)的方案是標(biāo)準(zhǔn)全家桶服務(wù)端拆成六個(gè)微服務(wù)、每個(gè)服務(wù)配一套獨(dú)立數(shù)據(jù)庫(kù)、中間再上消息隊(duì)列、Redis 緩存、Kubernetes 集群。我當(dāng)時(shí)的第一個(gè)反應(yīng)就是這需要用 caveman 的標(biāo)準(zhǔn)好好量一量。我把原方案里每個(gè)組件的必要性都問(wèn)了一遍六個(gè)微服務(wù)之間有沒(méi)有哪怕一個(gè)是可以先合并的如果合并成兩個(gè)單體服務(wù)哪些問(wèn)題會(huì)變大消息隊(duì)列解決的核心問(wèn)題在這個(gè)量級(jí)下是不是直接用同步調(diào)用更簡(jiǎn)單Redis 緩存的收益能不能靠一次數(shù)據(jù)庫(kù)主從分離來(lái)替代結(jié)果問(wèn)到最后有一半的組件答不出“非它不可”的理由。最終架構(gòu)調(diào)整為兩個(gè)服務(wù)加一個(gè)數(shù)據(jù)庫(kù)部署復(fù)雜度大幅下降上線時(shí)間提前了兩周運(yùn)行至今非常穩(wěn)定。這不是說(shuō)微服務(wù)不好而是說(shuō)在“幾十 QPS、兩三個(gè)人維護(hù)、排期緊張”的現(xiàn)實(shí)條件下微服務(wù)全家桶帶來(lái)的運(yùn)維成本和心智負(fù)擔(dān)遠(yuǎn)遠(yuǎn)超過(guò)了它帶來(lái)的好處。Caveman 架構(gòu)評(píng)審的原則其實(shí)就一條每個(gè)組件都必須當(dāng)場(chǎng)回答“為什么不能去掉它”。如果答案不夠干脆那就去掉它。你會(huì)發(fā)現(xiàn)去著去著系統(tǒng)輕了人也輕松了問(wèn)題反而變少了。4. 讓Caveman思維落地的工具與配置4.1 一個(gè)原始人友好的本地調(diào)試環(huán)境很多人以為 Caveman 思維意味著不用工具、全靠眼睛看這是誤解。原始人不是沒(méi)有工具而是只用夠用的工具。我個(gè)人的本地調(diào)試環(huán)境相當(dāng)樸素但每個(gè)都是精心挑過(guò)的編輯器就用主流 IDE 加最少的插件不堆砌那些看起來(lái)很酷但從來(lái)沒(méi)用到過(guò)的語(yǔ)法高亮、代碼地圖、AI 補(bǔ)全全家桶。我的理由是編輯器最核心的價(jià)值是讓你能快速閱讀和修改代碼而不是讓你沉浸在手不碰鍵盤(pán)的錯(cuò)覺(jué)里。本地?cái)?shù)據(jù)庫(kù)我直接用 Docker 起一個(gè)最簡(jiǎn)實(shí)例需要什么表自己建絕不掛一堆自動(dòng)遷移和種子數(shù)據(jù)腳本。我還會(huì)給本地環(huán)境配置一個(gè)“一號(hào)萬(wàn)能調(diào)試入口”一個(gè)簡(jiǎn)單的命令行腳本能夠直接調(diào)用項(xiàng)目里任意核心函數(shù)并打印結(jié)果。實(shí)現(xiàn)起來(lái)不復(fù)雜本質(zhì)上就是創(chuàng)建一個(gè)腳本入口文件把你想驗(yàn)證的函數(shù)引進(jìn)來(lái)傳參跑完打印。沒(méi)有啟動(dòng)整個(gè)服務(wù)沒(méi)有走 HTTP 請(qǐng)求沒(méi)有經(jīng)過(guò)鑒權(quán)中間件一步到位看到函數(shù)級(jí)別的輸出。這個(gè)腳本的存在讓“驗(yàn)證一個(gè)想法”的成本變得極低我非常推薦每個(gè)人都給自己的項(xiàng)目配一個(gè)這樣的入口。它看著簡(jiǎn)陋但每一次排查問(wèn)題時(shí)它都比那些需要等容器編排啟動(dòng)的完整環(huán)境快十倍。4.2 在代碼里留一條“Caveman逃生通道”實(shí)踐經(jīng)驗(yàn)多了以后我養(yǎng)成了一個(gè)習(xí)慣在系統(tǒng)里故意保留幾條“原始通道”也就是繞過(guò)各種高級(jí)組件、直接操作底層資源的接口。聽(tīng)起來(lái)有點(diǎn)反直覺(jué)但這其實(shí)是一份非常重要的保險(xiǎn)。最簡(jiǎn)單的例子有的團(tuán)隊(duì)把所有數(shù)據(jù)庫(kù)訪問(wèn)都封在倉(cāng)儲(chǔ)層里業(yè)務(wù)代碼完全不碰 SQL。這很整潔但當(dāng)線上出問(wèn)題時(shí)你連“直接查個(gè)關(guān)聯(lián)數(shù)據(jù)”的能力都沒(méi)有所有排查都得繞彎。我的做法是允許在某些運(yùn)維接口里直接執(zhí)行只讀 SQL并做好嚴(yán)格的權(quán)限控制。這個(gè)接口平時(shí)幾乎不用但一旦遇到復(fù)雜的數(shù)據(jù)核對(duì)現(xiàn)場(chǎng)它就是那條 Caveman 逃生通道——一瞬間直達(dá)數(shù)據(jù)源頭完全繞開(kāi)業(yè)務(wù)語(yǔ)義的干擾。類(lèi)似的逃生通道還包括一個(gè)可以直接讀取原始日志文件的腳本、一個(gè)能在內(nèi)存里 dump 關(guān)鍵數(shù)據(jù)結(jié)構(gòu)的小工具、一個(gè)繞過(guò)消息隊(duì)列直接把消息寫(xiě)給消費(fèi)者的調(diào)試接口。我從不指望這些通道出現(xiàn)在生產(chǎn)環(huán)境的主流程里它們只服務(wù)于一個(gè)目的在緊急時(shí)刻讓你能親眼看到系統(tǒng)最底層發(fā)生了什么。從我的經(jīng)驗(yàn)來(lái)看有沒(méi)有這條通道決定了一個(gè)團(tuán)隊(duì)在凌晨三點(diǎn)的故障面前是花二十分鐘解決還是花三個(gè)小時(shí)猜來(lái)猜去。5. 常見(jiàn)問(wèn)題與避坑實(shí)錄5.1 過(guò)度使用Caveman式調(diào)試的三個(gè)反噬場(chǎng)景任何方法都有邊界Caveman 思維也不例外。我總結(jié)了自己和身邊人過(guò)度“返祖”時(shí)踩過(guò)的坑最典型的有三個(gè)。第一把“加日志”當(dāng)成萬(wàn)能藥打了一堆毫無(wú)信息量的日志。給每個(gè)函數(shù)入口都加一行“進(jìn)來(lái)了”給每個(gè)出口都加一行“出去了”這種日志除了讓日志文件膨脹沒(méi)有任何排查價(jià)值。真正的 Caveman 日志應(yīng)該打在判斷點(diǎn)你懷疑哪里出問(wèn)題就在那一步打“輸入是什么、輸出是什么、分支走了哪邊”要的是信息密度不是日志數(shù)量。第二繞過(guò)所有正經(jīng)工具純手工驗(yàn)證一切。有人把 Caveman 理解成“絕不用調(diào)試器絕不用追蹤平臺(tái)”這就走向另一個(gè)極端了。我的立場(chǎng)是成熟的調(diào)試器、斷點(diǎn)、性能分析器都是好東西該用就得用。Caveman 思維不是拒絕工具而是拒絕“靠工具掩蓋真相”——當(dāng)工具能直接給出答案時(shí)你還在純靠眼睛看日志那不叫返祖叫犯傻。第三在團(tuán)隊(duì)協(xié)作里不寫(xiě)文檔、不留注釋美其名曰“保持原始”。這完全是對(duì) Caveman 哲學(xué)的誤讀。原始人不寫(xiě)文檔是因?yàn)闆](méi)發(fā)明文字不是因?yàn)閷?xiě)字不好。一個(gè)項(xiàng)目的可維護(hù)性很大程度上取決于清晰的注釋和準(zhǔn)確的設(shè)計(jì)文檔該寫(xiě)必須寫(xiě)這和“用最簡(jiǎn)方案解決問(wèn)題”完全不沖突。5.2 團(tuán)隊(duì)協(xié)作中怎么平衡“原始”與“專(zhuān)業(yè)”推崇 Caveman 思維最怕的就是變成一種個(gè)人英雄主義的表演“我能靠幾行日志解決的問(wèn)題你們非得搞那么復(fù)雜。”在團(tuán)隊(duì)里一定要把握好度。我的原則是Caveman 思維優(yōu)先用于自己的方案設(shè)計(jì)和排查思路而不是用來(lái)否定別人的工具和習(xí)慣。像微服務(wù)拆分、消息隊(duì)列引入這類(lèi)決策如果我有不同意見(jiàn)我不會(huì)在會(huì)上甩一句“這也太復(fù)雜了”而是把“為什么現(xiàn)在不需要它”的論據(jù)一條條擺出來(lái)跟大家討論。同時(shí)一旦團(tuán)隊(duì)最終決定上了某套比較復(fù)雜的技術(shù)棧我會(huì)全力配合因?yàn)?Caveman 的目標(biāo)是讓團(tuán)隊(duì)更穩(wěn)更快不是讓團(tuán)隊(duì)吵起來(lái)。實(shí)操上還有一個(gè)小技巧遇到一個(gè)自己覺(jué)得過(guò)度復(fù)雜的方案別急著全局反對(duì)可以先圈定一個(gè)最小的試點(diǎn)范圍用 Caveman 的簡(jiǎn)方案快速做出一個(gè)能跑的版本讓大家看到足夠直觀的效果。用事實(shí)說(shuō)服比用理論對(duì)抗有效得多。我在前面說(shuō)的那個(gè)架構(gòu)評(píng)審案例里之所以最后能調(diào)整方案就是因?yàn)槲野押喜⒑蟮膬蓚€(gè)服務(wù)先搭了出來(lái)跑通了一條主流程大家一眼就看出沒(méi)必要拆成六個(gè)。5.3 一張速查表什么場(chǎng)景該“進(jìn)化”什么場(chǎng)景該“回歸穴居”為了讓大家在實(shí)際工作里能快速判斷我做了一張簡(jiǎn)單的對(duì)照表列出哪些場(chǎng)景適合 Caveman 式的簡(jiǎn)單直給哪些場(chǎng)景還是應(yīng)該用更“現(xiàn)代”的工具和體系。典型場(chǎng)景更推薦的方法原因接口返回異常、數(shù)據(jù)對(duì)不上入口/出口加日志 二分定位直接看到真實(shí)數(shù)據(jù)繞開(kāi)中間層猜測(cè)明確是 SQL 慢查詢問(wèn)題EXPLAIN 索引優(yōu)化數(shù)據(jù)庫(kù)自己會(huì)告訴你它怎么跑的分布式事務(wù)一致性異常先逐節(jié)點(diǎn)核對(duì)“落庫(kù)事實(shí)”靠猜和靠追蹤都不如看誰(shuí)寫(xiě)錯(cuò)了高并發(fā)性能壓測(cè)與調(diào)優(yōu)專(zhuān)業(yè)的壓測(cè)工具 Profiler需要量化指標(biāo)純?nèi)罩拘侍臀⒎?wù)架構(gòu)評(píng)審先問(wèn)“去掉行不行”再談引入避免為了架構(gòu)而架構(gòu)大型系統(tǒng)全鏈路監(jiān)控成熟的鏈路追蹤平臺(tái)工具已經(jīng)幫我們串好了沒(méi)必要手工拼歷史遺留大坑的遷移分步走 數(shù)據(jù)核對(duì)遷移最怕黑盒原始核對(duì)法最穩(wěn)前端頁(yè)面樣式問(wèn)題瀏覽器 DevTools 實(shí)時(shí)調(diào)試可視化調(diào)整直接看到結(jié)果比打斷點(diǎn)還快這張表的意思很簡(jiǎn)單Caveman 不是讓你退化成工具絕緣體而是讓你在“現(xiàn)代工具”和“原始方法”之間自由切換。你既能在調(diào)試器里優(yōu)雅地打斷點(diǎn)也能在最快的時(shí)間里寫(xiě)下三行日志。兩手都要硬才是一個(gè)合格的“現(xiàn)代穴居人”。我個(gè)人這兩年最深的體會(huì)是很多項(xiàng)目真正被拖垮的時(shí)刻不是技術(shù)不夠而是人已經(jīng)喪失了親手去驗(yàn)證一個(gè)簡(jiǎn)單猜測(cè)的耐心。我們太習(xí)慣讓工具替我們思考讓框架替我們決策偶爾把自己扔回那個(gè)什么都沒(méi)有的山洞用最笨的辦法重新去面對(duì)問(wèn)題反而能找回一種特別清醒的控制感。下次再遇到抓狂的生產(chǎn)事故不妨先深呼吸問(wèn)自己一句假如我是一個(gè)洞穴里的原始人此刻手上只有一塊石頭和一根樹(shù)枝我會(huì)從哪開(kāi)始下手答案往往比你想的更簡(jiǎn)單。