北京
你有沒有遇到過這種情況：一個服務(wù)端明明應(yīng)該讓基礎(chǔ)設(shè)施決定流量走向，卻非要客戶端先搞清楚“我該去哪個區(qū)”才能發(fā)出請求？這就像你每次進(jìn)餐廳，服務(wù)員都先讓你決定坐哪桌，但經(jīng)理卻說會根據(jù)空位給你分配，然后你報了桌號，經(jīng)理再告訴你那個桌剛好不歸她管。我們團(tuán)隊(duì)就帶著這么個尷尬的設(shè)計(jì)跑了多年，直到幾次區(qū)域中斷逼著我們重新審視。
這個服務(wù)是AWS內(nèi)部支撐其他團(tuán)隊(duì)的“用戶設(shè)置”接口，需要低延遲、按身份返回配置。架構(gòu)很標(biāo)準(zhǔn)：在美西（俄勒岡）和歐洲（愛爾蘭）各部署一套API Gateway，用Route 53的延遲路由把請求送到離用戶最近的區(qū)域。問題出在認(rèn)證環(huán)節(jié)。當(dāng)時我們只能選IAM認(rèn)證，而IAM對接API Gateway的唯一簽名方案是SigV4。
SigV4的簽名過程會將“區(qū)域”硬編碼進(jìn)憑證范圍，美西的簽名到了愛爾蘭就變成廢紙。這意味著，客戶端在構(gòu)建請求之前，必須先知道自己會落到哪個區(qū)。但Route 53根據(jù)延遲動態(tài)分配區(qū)域這件事，客戶端根本不知道。于是我們造了個取巧的預(yù)檢端點(diǎn)：客戶端先打一個不鑒權(quán)的輕量接口，服務(wù)器返回一個區(qū)域名，客戶端拿到后，再帶著正確的區(qū)域簽名發(fā)起真正的調(diào)用。這個DiscoverRegion步驟沒有業(yè)務(wù)價值，純粹是為了遷就認(rèn)證模型而生。
這種變通方案在穩(wěn)定期無傷大雅，頂多增加一點(diǎn)延遲。但它把所有調(diào)用方的邏輯都焊死在了這套“先問路、再敲門”的流程里。后來幾次區(qū)域級宕機(jī)真把我們敲醒了：當(dāng)區(qū)域內(nèi)所有服務(wù)異常時，預(yù)檢請求同樣會失敗或超時，客戶端連“該跑去哪個合適區(qū)”都不知道。我們意識到，這層隱藏往返不僅是性能噪音，更是韌性短板。
救星是SigV4a。這套簽名方案允許你為一組區(qū)域生成同一個簽名，任何列表內(nèi)的區(qū)域都能驗(yàn)證通過。客戶端不再需要預(yù)判目的地，只管把請求丟給基礎(chǔ)設(shè)施；Route 53根據(jù)實(shí)際狀況把流量送走，API Gateway直接驗(yàn)簽放行。對我們來說，代碼改動很小——把簽名算法從SigV4切成SigV4a幾乎就是改個常量值。真正的功夫花在協(xié)調(diào)下游調(diào)用方上：幾十個內(nèi)部團(tuán)隊(duì)要逐一通知、測試、驗(yàn)證，期間不乏有人在舊邏輯上加新功能，得不斷往回拉。
這件事給的教訓(xùn)比技術(shù)細(xì)節(jié)本身值錢：你為某個約束費(fèi)心打磨的繞過方案，可能早已不是必須。SigV4a在我們最初設(shè)計(jì)時還不存在，可我們抱著“一直這么跑就好”的心態(tài)，錯過了多次升級窗口。定期把那些“因?yàn)楫?dāng)年沒有XX所以這樣繞”的模塊拿到新工具清單下晾一晾，不是找錯，而是檢查支撐它的約束是否已經(jīng)消失。偶爾拆掉一塊自己壘的磚，反而讓整個結(jié)構(gòu)更抗風(fēng)。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
財聞
