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