先說一個(gè)我最近踩過的坑一個(gè)本該只影響單個(gè)節(jié)點(diǎn)的口令輪換最后把整條調(diào)用鏈的三分之二節(jié)點(diǎn)都拉下了水。整個(gè)排查看下來問題根源不是口令本身而是一段本地優(yōu)先、遠(yuǎn)端回寫的配置讀取邏輯。這個(gè)系統(tǒng)在我眼里一直是個(gè)黑盒直到我用一場(chǎng)口令實(shí)驗(yàn)逼著它露出了內(nèi)部構(gòu)造的一角。標(biāo)題里的三個(gè)詞——共享狀態(tài)、隔離問題、黑盒——這次全部湊齊了。如果你正在維護(hù)多節(jié)點(diǎn)服務(wù)或者經(jīng)常要做密鑰、口令、配置的輪換操作這篇復(fù)盤應(yīng)該能幫你提前避開同樣的陷阱。先交代一下背景我這邊維護(hù)的是一套內(nèi)部平臺(tái)的多節(jié)點(diǎn)網(wǎng)關(guān)每個(gè)節(jié)點(diǎn)各自部署一份本地配置文件里面存了下游服務(wù)的訪問口令。因?yàn)榘踩弦?guī)要求下游服務(wù)的口令每90天必須輪換一次這已經(jīng)是我們做過的第四輪輪換了。之前幾輪都是干干凈凈的改配置、重啟節(jié)點(diǎn)、驗(yàn)證請(qǐng)求最多半小時(shí)結(jié)束。但這一次我本著灰度優(yōu)先的想法想只改其中一個(gè)節(jié)點(diǎn)的口令觀察一段時(shí)間確認(rèn)無誤后再批量替換結(jié)果這個(gè)看似穩(wěn)妥的流程反而成了挖坑的開始。1. 一次只動(dòng)一個(gè)節(jié)點(diǎn)的口令輪換把整條鏈路打出了4011.1 身份背景多節(jié)點(diǎn)網(wǎng)關(guān)與計(jì)劃中的灰度變更先說清楚這套系統(tǒng)的拓?fù)洹＞W(wǎng)關(guān)層一共部署了六個(gè)節(jié)點(diǎn)前面掛著一個(gè)負(fù)載均衡入口后面連著一個(gè)下游計(jì)費(fèi)服務(wù)。每個(gè)網(wǎng)關(guān)節(jié)點(diǎn)的本地配置里都保存著調(diào)用下游服務(wù)所需的訪問口令網(wǎng)關(guān)啟動(dòng)的時(shí)候會(huì)把配置加載進(jìn)內(nèi)存之后的請(qǐng)求都用這份內(nèi)存里的口令去和下游做認(rèn)證。正常來說六個(gè)節(jié)點(diǎn)是彼此獨(dú)立的每個(gè)節(jié)點(diǎn)各自持有配置、各自建立連接池、各自的故障也只影響自己。這也是我們敢做單個(gè)節(jié)點(diǎn)灰度的前提——我改A節(jié)點(diǎn)理論上只有A節(jié)點(diǎn)的請(qǐng)求會(huì)變B和C節(jié)點(diǎn)依然用舊口令走老路兩邊互不干擾?？诹畋旧硎且淮畮О姹竞缶Y的字符串比如tk_20240201_A3f9。我們約定每次輪換后下游服務(wù)只認(rèn)最新的那個(gè)口令。按道理說我只要讓A節(jié)點(diǎn)先用新口令下游就會(huì)接受而B、C節(jié)點(diǎn)繼續(xù)用舊口令下游會(huì)因?yàn)檎J(rèn)證失敗拒絕它們——但這正是我要觀察的過渡期現(xiàn)象。1.2 第一次實(shí)驗(yàn)只改A節(jié)點(diǎn)錯(cuò)誤率卻按節(jié)點(diǎn)分布擴(kuò)散操作很簡(jiǎn)單登錄A節(jié)點(diǎn)把本地配置文件里的口令字段替換成新值然后重啟網(wǎng)關(guān)進(jìn)程。重啟過程很順利A節(jié)點(diǎn)起來了健康檢查通過我盯著監(jiān)控面板準(zhǔn)備看A節(jié)點(diǎn)的請(qǐng)求曲線。五分鐘之后奇怪的事情發(fā)生了。下游計(jì)費(fèi)服務(wù)的告警群開始刷消息auth failed認(rèn)證失敗。我趕緊打開網(wǎng)關(guān)的日志排查第一眼的結(jié)論是報(bào)錯(cuò)請(qǐng)求的來源不止A節(jié)點(diǎn)B、C節(jié)點(diǎn)的請(qǐng)求也在大量報(bào)401。要知道B和C節(jié)點(diǎn)我根本還沒碰過它們的內(nèi)存里還是舊口令舊口令理論上應(yīng)該還能繼續(xù)工作一段時(shí)間——前提是下游仍然臨時(shí)接受舊口令。這里就出現(xiàn)了一個(gè)認(rèn)知裂縫如果這是一個(gè)真正的無狀態(tài)、隔離架構(gòu)B和C節(jié)點(diǎn)不可能受A節(jié)點(diǎn)的影響。但監(jiān)控?cái)?shù)據(jù)告訴我它們就是被影響了。錯(cuò)誤率在這幾個(gè)節(jié)點(diǎn)上分布得還很均勻不是只有A節(jié)點(diǎn)出問題。這說明什么呢要么下游服務(wù)的認(rèn)證策略變了要么這個(gè)系統(tǒng)的狀態(tài)隔離根本沒有文檔里描述的那么干凈。1.3 最初的誤判下游開了白名單卻沒通知我們會(huì)議室里大家的第一反應(yīng)是下游服務(wù)的認(rèn)證側(cè)是不是偷偷把舊口令的容忍窗口關(guān)掉了按照過去的輪換流程下游一般會(huì)保留舊口令24小時(shí)作為緩沖但這次可能因?yàn)榘踩呗陨?jí)緩沖期被縮短甚至取消了。如果真的這樣那么B、C節(jié)點(diǎn)用舊口令去調(diào)下游被401拒絕就是正常現(xiàn)象只是我們不知情。為了驗(yàn)證這個(gè)猜測(cè)我直接翻開了網(wǎng)關(guān)和下游服務(wù)之間的認(rèn)證日志。結(jié)果很打臉下游返回的認(rèn)證錯(cuò)誤信息里明確寫著invalid token version。也就是說下游服務(wù)確實(shí)只認(rèn)新口令舊口令已經(jīng)徹底失效了。可是B、C節(jié)點(diǎn)內(nèi)存里的口令明明是舊的它們的報(bào)錯(cuò)為什么和A節(jié)點(diǎn)用新口令報(bào)的錯(cuò)混在一起更讓我不解的是如果B和C一直在用舊口令那么從重啟完成后那一刻起它們的請(qǐng)求就應(yīng)該全部報(bào)錯(cuò)錯(cuò)誤率應(yīng)該是100%。但監(jiān)控里顯示的錯(cuò)誤率只有20%左右剩下80%的請(qǐng)求是成功的。這20%的分布模式很不規(guī)律像是有什么東西在舊口令和新口令之間反復(fù)橫跳。2. 從日志到緩存再到源碼黑盒的第一條解剖路徑2.1 把報(bào)錯(cuò)請(qǐng)求按來源節(jié)點(diǎn)聚合發(fā)現(xiàn)了一半好一半壞順著這個(gè)20%報(bào)錯(cuò)的線索我把網(wǎng)關(guān)日志按來源節(jié)點(diǎn)做了聚合統(tǒng)計(jì)。寫了個(gè)簡(jiǎn)單的命令把每個(gè)節(jié)點(diǎn)的認(rèn)證成功和失敗次數(shù)分別數(shù)出來grep auth gateway.log | awk {print $3, $5} | sort | uniq -c結(jié)果有點(diǎn)意思六個(gè)節(jié)點(diǎn)的錯(cuò)誤率全部落在18%到22%之間沒有哪個(gè)節(jié)點(diǎn)是0%也沒有哪個(gè)節(jié)點(diǎn)是100%。每個(gè)節(jié)點(diǎn)都是既有一部分請(qǐng)求成功又有一部分請(qǐng)求失敗。這對(duì)節(jié)點(diǎn)各自持有獨(dú)立配置的解釋模型是一個(gè)致命打擊——如果每個(gè)節(jié)點(diǎn)真的只有一份口令那么它要么全對(duì)要么全錯(cuò)不可能做到一部分請(qǐng)求對(duì)、一部分請(qǐng)求錯(cuò)。除非每個(gè)節(jié)點(diǎn)的內(nèi)存里同時(shí)存在兩份口令一份是啟動(dòng)時(shí)加載的本地配置值另一份是運(yùn)行期間動(dòng)態(tài)獲取的共享緩存值。請(qǐng)求處理時(shí)有一部分請(qǐng)求走了動(dòng)態(tài)獲取的新口令另一部分走了本地加載的舊口令兩者被混著用了。這個(gè)猜測(cè)一旦立起來所有現(xiàn)象就都能解釋了節(jié)點(diǎn)的請(qǐng)求在新舊口令之間隨機(jī)切換整體錯(cuò)誤率取決于新舊口令在流量中的占比以及下游對(duì)兩者的接受程度。2.2 Redis里躺著一個(gè)誰(shuí)也沒主動(dòng)寫過的配置key帶著這個(gè)猜測(cè)我打開網(wǎng)關(guān)連接的那個(gè)Redis實(shí)例。這套網(wǎng)關(guān)注冊(cè)里確實(shí)有一個(gè)Redis平時(shí)用來做限流計(jì)數(shù)和分布式鎖配置相關(guān)的Key我印象里是沒有的。我掃了一圈鍵空間發(fā)現(xiàn)了一個(gè)從沒見過的keygw:downstream:token。查看它的值里面存的正是我剛剛在A節(jié)點(diǎn)寫下的新口令。TTL還有將近十個(gè)小時(shí)。說實(shí)話看到這個(gè)key的那一刻我的第一反應(yīng)是誰(shuí)寫進(jìn)去的按我們的運(yùn)維流程沒有任何腳本會(huì)往Redis里寫這個(gè)配置。配置的分發(fā)走的是另一套手工流程——登錄節(jié)點(diǎn)、改文件、重啟進(jìn)程從來沒有人往Redis寫入過任何配置項(xiàng)。而這個(gè)key也不可能自己憑空出現(xiàn)。唯一的解釋是網(wǎng)關(guān)的代碼本身在某條路徑上把這個(gè)值寫進(jìn)去了。而這個(gè)路徑必然隱藏在一個(gè)所有節(jié)點(diǎn)共用的共享狀態(tài)之下。Redis作為共享存儲(chǔ)讓任何一個(gè)節(jié)點(diǎn)的寫入對(duì)所有節(jié)點(diǎn)即時(shí)可見。A節(jié)點(diǎn)寫入的是新口令于是其他節(jié)點(diǎn)也讀到了新口令——這就是為什么B、C節(jié)點(diǎn)明明本地還是舊配置卻一樣會(huì)拿新口令去調(diào)下游。2.3 關(guān)鍵代碼Redis優(yōu)先讀取失敗后本地兜底并回寫接下來就是翻源碼。網(wǎng)關(guān)的配置讀取模塊大概長(zhǎng)這樣用Go的偽代碼表示實(shí)際邏輯比我這個(gè)示例復(fù)雜但核心脈絡(luò)是一致的func getSecretFromCache(key string) (string, error) { // 第一步Redis優(yōu)先 val, err : rdb.Get(ctx, key).Result() if err nil { return val, nil } if !errors.Is(err, redis.Nil) { return , err } // 第二步本地兜底并回寫 Redis localVal : localConfig.Get(key) if localVal ! { _ rdb.Set(ctx, key, localVal, 12*time.Hour).Err() } return localVal, nil }邏輯本身非常簡(jiǎn)單先嘗試從Redis拿值如果拿到了就直接用如果Redis里沒有這個(gè)key就回到本地配置讀取并且在讀取之后把它回寫到Redis里設(shè)置一個(gè)12小時(shí)的過期時(shí)間。這個(gè)設(shè)計(jì)最初的出發(fā)點(diǎn)是好的——讓配置具備動(dòng)態(tài)下發(fā)能力。只要運(yùn)維往Redis里放一個(gè)新口令所有節(jié)點(diǎn)都會(huì)自動(dòng)感知不用一臺(tái)臺(tái)登錄改文件。本地配置只是兜底避免Redis抖動(dòng)時(shí)服務(wù)不可用。聽起來很合理對(duì)吧問題出在那個(gè)回寫動(dòng)作?；貙懸馕吨魏喂?jié)點(diǎn)在Redis miss之后都會(huì)拿自己的本地值去覆蓋這個(gè)共享key。如果六個(gè)節(jié)點(diǎn)的本地配置不一樣比如我這次只改了A節(jié)點(diǎn)那么先觸發(fā)回寫的節(jié)點(diǎn)就會(huì)把這個(gè)key覆蓋成自己手里的值后觸發(fā)的節(jié)節(jié)點(diǎn)再把它覆蓋成另一個(gè)值。誰(shuí)的寫入晚誰(shuí)就是整個(gè)集群的真值來源。而它影響的不止自己這個(gè)節(jié)點(diǎn)而是所有會(huì)讀取這個(gè)key的節(jié)點(diǎn)。3. 第二次實(shí)驗(yàn)驗(yàn)證誰(shuí)最后重啟誰(shuí)就定義全局狀態(tài)3.1 一個(gè)矛盾現(xiàn)場(chǎng)改B節(jié)點(diǎn)的舊口令居然讓報(bào)錯(cuò)消失了讀到源碼之后我對(duì)這個(gè)回寫覆蓋的機(jī)制已經(jīng)有了比較強(qiáng)的把握但實(shí)話說光靠讀代碼還不夠它只是解釋了為什么狀態(tài)會(huì)共享還沒解釋為什么每個(gè)節(jié)點(diǎn)的錯(cuò)誤率都是20%。時(shí)間線擺在我面前是這樣的A節(jié)點(diǎn)先重啟它寫入了新口令。之后B、C節(jié)點(diǎn)在運(yùn)行過程中遇到Redis miss各自觸發(fā)了一次回寫——但B和C手里的本地配置還是舊口令它們回寫會(huì)把Redis里的新口令覆蓋成舊口令。新一輪請(qǐng)求再讀Redis拿到的反而變成舊口令于是又有一部分請(qǐng)求開始用舊口令打下游被401拒絕。這樣一來集群的狀態(tài)就有趣了Redis里的值在新舊口令之間來回橫跳。誰(shuí)先觸發(fā)回寫Redis里就是誰(shuí)的本地值。錯(cuò)誤率具體是多少取決于最近一次回寫來自哪個(gè)節(jié)點(diǎn)。這就解釋了為什么六個(gè)節(jié)點(diǎn)的錯(cuò)誤率都穩(wěn)定在20%左右——大量請(qǐng)求快速消耗TTL不斷觸發(fā)新的回寫新舊值在競(jìng)爭(zhēng)中維持了一個(gè)動(dòng)態(tài)比例。為了把這個(gè)推斷做實(shí)我做了第二次實(shí)驗(yàn)。我登錄B節(jié)點(diǎn)把B的本地配置改成了舊口令——也就是B本來就在用的那個(gè)值然后重啟B節(jié)點(diǎn)。按照回寫覆蓋的邏輯B重啟完成后只要它第一個(gè)請(qǐng)求觸發(fā)一次Redis miss就會(huì)把Redis里的新口令覆蓋成舊口令。之后全集群的節(jié)點(diǎn)都會(huì)從Redis讀到舊口令錯(cuò)誤率應(yīng)該大幅下降甚至歸零。結(jié)果真的是這樣。B節(jié)點(diǎn)重啟后大約三分鐘全集群的401錯(cuò)誤率直線下降到0。所有節(jié)點(diǎn)包括A節(jié)點(diǎn)它們的請(qǐng)求全部恢復(fù)成功。這個(gè)結(jié)果看起來像修復(fù)了問題但實(shí)際上只是把共享的全局狀態(tài)從新口令切回了舊口令。如果此時(shí)A節(jié)點(diǎn)再重啟一次它會(huì)再次把Redis里的值覆蓋回新口令全集群又會(huì)開始報(bào)錯(cuò)。所謂的修復(fù)不過是讓最后一個(gè)重啟的節(jié)點(diǎn)說了算。3.2 推導(dǎo)共享狀態(tài)的寫入順序后啟動(dòng)的節(jié)點(diǎn)覆蓋先啟動(dòng)的把兩次實(shí)驗(yàn)放一起看結(jié)論已經(jīng)非常明確了。第一次實(shí)驗(yàn)改A全局被A的新口令覆蓋其他節(jié)點(diǎn)跟著遭殃第二次實(shí)驗(yàn)重啟B全局被B的舊口令覆蓋所有節(jié)點(diǎn)跟著恢復(fù)。這串現(xiàn)象翻譯成正式話術(shù)就是所有節(jié)點(diǎn)的配置讀取邏輯在Redis miss時(shí)都執(zhí)行了一次本地值覆蓋共享值的回寫而回寫的效果是全局可見的。共享key的最終取值完全取決于最后一個(gè)觸發(fā)回寫的節(jié)點(diǎn)是誰(shuí)。更嚴(yán)格地說取決于那個(gè)節(jié)點(diǎn)最后一次重啟之后、第一個(gè)觸發(fā)Redis miss的請(qǐng)求的時(shí)間點(diǎn)。我用一張表整理兩次實(shí)驗(yàn)的對(duì)應(yīng)關(guān)系實(shí)驗(yàn)操作的節(jié)點(diǎn)本地口令Redis最終值全集群效果實(shí)驗(yàn)一A節(jié)點(diǎn)新口令新口令約20%請(qǐng)求用新口令401錯(cuò)誤率上升實(shí)驗(yàn)二B節(jié)點(diǎn)舊口令舊口令被B覆蓋全集群恢復(fù)到舊口令錯(cuò)誤率歸零這個(gè)表格背后最扎心的一點(diǎn)是如果我不做第二次實(shí)驗(yàn)只是老老實(shí)實(shí)把A節(jié)點(diǎn)改回去并重啟理論上也能讓集群恢復(fù)。但是我永遠(yuǎn)無法確認(rèn)到底是誰(shuí)改的、為什么改。第二次實(shí)驗(yàn)的價(jià)值在于它提供了對(duì)照當(dāng)B節(jié)點(diǎn)這個(gè)變量被單獨(dú)操作時(shí)全局狀態(tài)確實(shí)跟著B走了。這才能證明回寫路徑真實(shí)存在而不是什么幽靈腳本在改Redis。3.3 無狀態(tài)節(jié)點(diǎn)的黑盒側(cè)面代碼承諾和實(shí)際行為的偏差這個(gè)事故教會(huì)我最重要的一件事不是不要用Redis存配置這種單點(diǎn)結(jié)論而是你腦子里對(duì)系統(tǒng)架構(gòu)的假設(shè)和代碼實(shí)際運(yùn)行的行為可能是兩個(gè)完全不同的黑盒。在做這次實(shí)驗(yàn)之前我對(duì)這套網(wǎng)關(guān)的認(rèn)知是節(jié)點(diǎn)是無狀態(tài)的配置是本地隔離的任何一個(gè)節(jié)點(diǎn)的變更不會(huì)影響其他節(jié)點(diǎn)。這個(gè)認(rèn)知來自架構(gòu)文檔來自每個(gè)節(jié)點(diǎn)獨(dú)立配置文件的表象來自我們過去多次成功輪換口令的慣性經(jīng)驗(yàn)。但代碼告訴我節(jié)點(diǎn)在無狀態(tài)的外殼下隱藏著一條回寫共享緩存的路徑而這條路徑把六個(gè)節(jié)點(diǎn)緊密耦合成了一個(gè)整體。黑盒之所以是黑盒不是因?yàn)樗娴臒o法理解而是因?yàn)槟氵€沒有找到合適的探針。在我這次的口令實(shí)驗(yàn)之前這個(gè)系統(tǒng)的回寫邏輯從來沒有被觸發(fā)過——因?yàn)樗泄?jié)點(diǎn)的本地配置始終一致回寫也好、不回寫也好對(duì)結(jié)果沒有任何影響。只有當(dāng)我把其中一個(gè)節(jié)點(diǎn)的配置故意改成與其他人不同這個(gè)隱藏路徑才第一次顯形。這種差異實(shí)驗(yàn)的思路值得每個(gè)做分布式系統(tǒng)的人記下來想讓一個(gè)黑盒里的隱藏狀態(tài)露出馬腳最好的辦法不是盯著它看而是主動(dòng)制造一個(gè)可以讓隱藏狀態(tài)產(chǎn)生可觀測(cè)差異的條件。共享狀態(tài)只有在節(jié)點(diǎn)間值不一致時(shí)才會(huì)顯現(xiàn)。4. 通過這次事故我重新理解了隔離設(shè)計(jì)的三層邊界4.1 配置隔離權(quán)威源只能有一個(gè)副本必須是只讀緩存這次事故的本質(zhì)不是用了Redis做配置錯(cuò)而是配置的權(quán)威源不明確而且副本有寫權(quán)限。一個(gè)正確的配置架構(gòu)里權(quán)威源應(yīng)該且只能有一個(gè)。其他任何位置的配置要么是從權(quán)威源拉取的只讀副本要么是本地緩存的只讀快照。它們可以讀、可以用但不能反向?qū)懭霗?quán)威源。一旦副本擁有寫權(quán)限配置的一致性就變成了最后一次寫入獲勝的競(jìng)速游戲節(jié)點(diǎn)之間的隔離邊界隨之瓦解。拿我們這個(gè)場(chǎng)景來說最合理的方案應(yīng)該是這樣的配置中心或者一個(gè)明確的配置管理服務(wù)是唯一權(quán)威源口令的增刪改只能在這里發(fā)生。Redis里可以放一份配置緩存但這份緩存只能由配置中心寫入節(jié)點(diǎn)無權(quán)寫入。節(jié)點(diǎn)啟動(dòng)時(shí)從配置中心拉取全量配置落到本地作為只讀快照運(yùn)行期間如果發(fā)現(xiàn)遠(yuǎn)端版本號(hào)變化就重新拉取。如果配置中心不可達(dá)節(jié)點(diǎn)繼續(xù)使用本地快照同時(shí)告警但無論如何都不能把本地的值反向傳播到共享存儲(chǔ)里去。這樣改完之后我再去輪換口令流程就變成先在配置中心修改口令配置中心異步更新Redis緩存各節(jié)點(diǎn)根據(jù)自己的刷新節(jié)奏拉取新版本。節(jié)點(diǎn)之間依然彼此隔離任何一個(gè)節(jié)點(diǎn)的故障或重啟都不會(huì)把別的節(jié)點(diǎn)帶偏。4.2 狀態(tài)隔離無狀態(tài)是一種需要持續(xù)驗(yàn)證的承諾無狀態(tài)節(jié)點(diǎn)這四個(gè)字說起來輕松聽起來安全。但在真實(shí)系統(tǒng)里無狀態(tài)往往是一個(gè)需要持續(xù)驗(yàn)證的承諾而不是一個(gè)默認(rèn)成立的屬性。我反思過為什么這個(gè)問題藏了這么久才暴露因?yàn)槲覀冞^去的所有運(yùn)維操作都默認(rèn)六個(gè)節(jié)點(diǎn)的本地配置是一樣的。既然所有節(jié)點(diǎn)持有的值相同那么無論回寫發(fā)生在哪個(gè)節(jié)點(diǎn)Redis里的值都不會(huì)變。錯(cuò)誤就藏在這個(gè)不變里它沒有制造任何可觀測(cè)的差異于是所有人都認(rèn)為系統(tǒng)是正常的。這提醒我對(duì)于任何聲稱無狀態(tài)、可水平擴(kuò)展的模塊定期做差異注入式的測(cè)試是必要的。具體做法可以是刻意讓其中一個(gè)節(jié)點(diǎn)的某個(gè)配置值與其他人不同然后觀察系統(tǒng)的行為是否符合預(yù)期。如果它真的無狀態(tài)、真隔離那么差異只會(huì)影響這個(gè)節(jié)點(diǎn)本身如果像我們這次一樣配置其實(shí)被隱性共享了那么差異就會(huì)溢出到整個(gè)集群。這種測(cè)試的成本其實(shí)不高。你不需要每次都改口令可以選一個(gè)影響面小的配置項(xiàng)比如日志級(jí)別、超時(shí)時(shí)間在灰度環(huán)境里做一輪就能驗(yàn)證節(jié)點(diǎn)是否真正隔離。問題在于很多人包括從前的我根本不覺得需要做這個(gè)驗(yàn)證直到線上事故親自教一遍。4.3 故障隔離回寫路徑是最容易被忽視的隱性單點(diǎn)再往深一層說回寫共享存儲(chǔ)這個(gè)動(dòng)作表面上只是一個(gè)微不足道的容錯(cuò)設(shè)計(jì)實(shí)際上卻是一顆隱性的單點(diǎn)炸彈。它的威脅在于回寫路徑的故障不會(huì)以節(jié)點(diǎn)不可用的形式出現(xiàn)而是以全局狀態(tài)被污染的形式出現(xiàn)。你很難用常規(guī)的健康檢查發(fā)現(xiàn)它因?yàn)楣?jié)點(diǎn)本身活得好好的接口也在正常響應(yīng)只是它給全局狀態(tài)寫入了錯(cuò)誤的值然后把錯(cuò)誤傳播到了所有其他節(jié)點(diǎn)。這個(gè)特性讓回寫路徑比顯式依賴更危險(xiǎn)。顯式依賴比如節(jié)點(diǎn)必須依賴配置中心才能啟動(dòng)一旦故障你會(huì)立刻知道因?yàn)楣?jié)點(diǎn)起不來告警馬上觸發(fā)。而隱性依賴節(jié)點(diǎn)在Redis miss時(shí)靜默回寫故障時(shí)一切看起來都很正常只有當(dāng)你仔細(xì)觀察數(shù)據(jù)流時(shí)才能發(fā)現(xiàn)全局狀態(tài)已經(jīng)被悄悄改寫了。所以我現(xiàn)在的習(xí)慣是審查代碼時(shí)對(duì)所有寫共享存儲(chǔ)的路徑保持高度警惕尤其是發(fā)生在異常分支、兜底分支、降級(jí)分支里的寫入操作。兜底邏輯的第一原則應(yīng)該是盡可能保守——讀取失敗時(shí)返回本地值就夠了完全沒必要再往外寫點(diǎn)什么。5. 對(duì)黑盒系統(tǒng)的實(shí)驗(yàn)紀(jì)律探針要小證據(jù)要留回滾要快5.1 變更前先留狀態(tài)基線變更中盯全局而不是局部回顧這次事故的全過程我發(fā)現(xiàn)最幸運(yùn)的一點(diǎn)是我在改動(dòng)A節(jié)點(diǎn)之前順手截圖保存了六個(gè)節(jié)點(diǎn)的初始配置。如果不是這張截圖實(shí)驗(yàn)二里B節(jié)點(diǎn)覆蓋Redis的判斷就不會(huì)那么扎實(shí)因?yàn)槲倚枰烂總€(gè)節(jié)點(diǎn)手里原本拿著什么口令才能確認(rèn)Redis里的變化確實(shí)來自B的回寫。所以我把這條當(dāng)成實(shí)驗(yàn)紀(jì)律的第一條任何對(duì)黑盒系統(tǒng)的變更動(dòng)手之前先采集一份完整的基線數(shù)據(jù)?；€至少包括各個(gè)節(jié)點(diǎn)的配置值、共享存儲(chǔ)里的相關(guān)key、監(jiān)控面板上的錯(cuò)誤率快照。有了基線你才能在變更后區(qū)分什么變了、什么沒變而不是靠記憶和感覺。監(jiān)控也一樣。我一開始犯的錯(cuò)誤是盯著A節(jié)點(diǎn)的曲線看因?yàn)槲业淖⒁饬θ谖也僮鞯哪莻€(gè)節(jié)點(diǎn)上。但正確做法是把全局視圖打開觀察所有節(jié)點(diǎn)的錯(cuò)誤率分布。這個(gè)系統(tǒng)的故障面是集群級(jí)的只有全局視角才能讓你在第一時(shí)間發(fā)現(xiàn)影響范圍超出了操作范圍這個(gè)關(guān)鍵信號(hào)。5.2 最小實(shí)驗(yàn)要同時(shí)包含正向驗(yàn)證和反向?qū)φ者@次的兩次實(shí)驗(yàn)其實(shí)是一對(duì)很好的正向與反向?qū)φ战M。實(shí)驗(yàn)一只改A是正向驗(yàn)證它證明了一個(gè)節(jié)點(diǎn)的本地配置變化可以傳導(dǎo)到全局。但單靠正向驗(yàn)證還不夠因?yàn)閭鲗?dǎo)到全局的中間路徑可能有很多種解釋——也許是配置中心自動(dòng)同步也許是幽靈腳本。實(shí)驗(yàn)二只改B并觀察B覆蓋全局就是反向?qū)φ账炎兞繂为?dú)撥動(dòng)觀察結(jié)果是否嚴(yán)格跟隨這個(gè)變量。這種成對(duì)實(shí)驗(yàn)的設(shè)計(jì)思路比單次實(shí)驗(yàn)可靠得多。做最小化實(shí)驗(yàn)時(shí)盡量設(shè)計(jì)成可以雙向驗(yàn)證的形式正向驗(yàn)證證明加了這個(gè)變量結(jié)果變了反向?qū)φ兆C明動(dòng)了另一個(gè)變量結(jié)果也跟著變。兩者疊加才能把黑盒里那條隱藏路徑的邊界畫清楚。在具體操作上反向?qū)φ諏?shí)驗(yàn)要注意控制變量。我當(dāng)時(shí)只改了B節(jié)點(diǎn)的本地配置并重啟沒有動(dòng)Redis、沒有改配置中心、沒有動(dòng)其他任何節(jié)點(diǎn)。因?yàn)橹粍?dòng)了這一個(gè)變量B節(jié)點(diǎn)重啟后Redis值的變化才能可靠地歸因于B的回寫邏輯。如果同時(shí)改多個(gè)東西歸因就會(huì)變得模糊實(shí)驗(yàn)的價(jià)值就大打折扣。5.3 給配置加版本號(hào)讓共享狀態(tài)從不可見到可追溯最后說一個(gè)我在修復(fù)時(shí)順手做掉、但價(jià)值很大的改造給配置值加了版本號(hào)。修復(fù)后的讀取邏輯大致長(zhǎng)這樣type ConfigValue struct { Value string json:value Version int64 json:version } func getConfigWithVersion(ctx context.Context, key string) (ConfigValue, error) { remote, err : configCenter.GetConfig(ctx, key) if err ! nil { // 配置中心不可達(dá)時(shí)回退到本地快照但不反向?qū)懟?return localSnapshot.Get(key), nil } if localSnapshot.Valid(remote.Version) { // 遠(yuǎn)程版本與本地版本不一致時(shí)記錄審計(jì)日志 log.Warnf(config version changed: key%s local%d remote%d, key, localSnapshot.VersionOf(key), remote.Version) } return remote, nil }版本號(hào)的意義在于它把共享狀態(tài)從不可見變成了可追溯。以前一個(gè)節(jié)點(diǎn)改了口令Redis里那個(gè)key的值變了但你不知道是誰(shuí)改的、什么時(shí)候改的。加了版本號(hào)之后每次寫入都會(huì)帶上自增的版本號(hào)你需要知道的事情都寫在版本號(hào)里這個(gè)值是最新來自配置中心的還是某個(gè)節(jié)點(diǎn)本地兜底留下的舊值。有人可能覺得加了版本號(hào)還是擋不住節(jié)點(diǎn)回寫覆蓋因?yàn)榛貙懸廊粫?huì)發(fā)生。但事實(shí)是把版本號(hào)加進(jìn)代碼之后回寫邏輯本身的荒謬性就徹底暴露出來了——一個(gè)本地節(jié)點(diǎn)在寫入共享緩存時(shí)根本無法自洽地生成一個(gè)比配置中心更新的版本號(hào)。所以這個(gè)改造相當(dāng)于從設(shè)計(jì)上把節(jié)點(diǎn)回寫這條路堵死了剩下唯一合法的寫入者只有配置中心。最后再分享兩個(gè)小技巧我在收尾之前再分享兩個(gè)這次事故后養(yǎng)成的實(shí)操習(xí)慣。第一個(gè)是遇到看起來只該影響局部卻影響全局的現(xiàn)象先別急著懷疑外部服務(wù)優(yōu)先檢查共享存儲(chǔ)里有沒有本來不該存在的key。第二個(gè)是寫兜底邏輯時(shí)默認(rèn)禁止回寫動(dòng)作任何向共享存儲(chǔ)寫入的操作都必須經(jīng)過顯式批準(zhǔn)而不是藏在異常分支里順手寫一句。這次口令實(shí)驗(yàn)給我的最大收獲倒不是Redis用法上的教訓(xùn)而是讓我重新審視了一個(gè)基礎(chǔ)問題我們真的了解自己系統(tǒng)里的共享狀態(tài)嗎如果不做差異實(shí)驗(yàn)很多隱性共享永遠(yuǎn)不會(huì)有暴露的機(jī)會(huì)。希望這篇復(fù)盤能幫你少踩一次同樣的坑尤其是在做配置輪換、密鑰更新這類看起來平平無奇的操作時(shí)多留一份對(duì)隔離邊界的敬畏。