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