作者 | Mitendra Mahto

譯者 | 張衛(wèi)濱

代理層的關(guān)鍵脆弱性

反向代理是互聯(lián)網(wǎng)大規(guī)?；A(chǔ)設(shè)施中默默無聞的核心組件。它們終止傳輸層安全（Transport Layer Security，TLS）、防御拒絕服務(wù)（DoS）攻擊、平衡負(fù)載、響應(yīng)緩存，并連接快速演變的服務(wù)。無論你稱它為負(fù)載均衡器、邊緣代理、API 網(wǎng)關(guān)還是 Kubernetes Ingress 控制器，這一層都是所有流量匯聚的地方，而且我們也得承認(rèn)，它也是很容易出問題的地方。

它的麻煩在于代理很少以整潔、教科書式的方式失敗。相反，有時(shí)候它們會(huì)在優(yōu)化基準(zhǔn)測(cè)試中表現(xiàn)出色，但是在真實(shí)工作負(fù)載下卻會(huì)崩潰；因?yàn)樵獢?shù)據(jù)中缺失了一個(gè)逗號(hào)，導(dǎo)致實(shí)時(shí)流量悄無聲息地中斷，它們也會(huì)因此而失敗。它們還可能因?yàn)橹荚诤?jiǎn)化技術(shù)棧的抽象變成了隱藏的脆弱點(diǎn)而失敗。

本文是運(yùn)行大規(guī)模反向代理艦隊(duì)（fleet）的一系列戰(zhàn)爭(zhēng)故事的集合。它探討了適得其反的優(yōu)化，觸發(fā)故障的常規(guī)變更，以及塑造我們今天設(shè)計(jì)和運(yùn)行代理方式的運(yùn)維教訓(xùn)。

優(yōu)化陷阱：

當(dāng)優(yōu)化變得有毒

優(yōu)化是很誘人的。它們承諾了免費(fèi)的性能提升，這在基準(zhǔn)測(cè)試中看起來很棒，通常在小環(huán)境中能夠很完美地工作。

但一旦主機(jī)擴(kuò)展至超過五十個(gè)核心，艦隊(duì)在數(shù)百個(gè)節(jié)點(diǎn)上服務(wù)數(shù)百萬 QPS 時(shí)，規(guī)則就會(huì)發(fā)生巨大的變化，一個(gè)地方的性能提升可以迅速成為大規(guī)模的負(fù)擔(dān)。

Freelist 爭(zhēng)用災(zāi)難

我們擴(kuò)展了 Apache Traffic Server（ATS），從一組較小核心的機(jī)器轉(zhuǎn)移到現(xiàn)代化的多核心主機(jī)。假設(shè)很簡(jiǎn)單：更多的核心應(yīng)該意味著成比例的吞吐量增加。在傳統(tǒng)硬件上，ATS 的 freelist 優(yōu)化能夠按預(yù)期工作，減少了堆爭(zhēng)用并提高了分配速度。

但是，在 64 核主機(jī)上，同樣的 freelist 設(shè)計(jì)會(huì)適得其反。ATS 依賴于 freelist 訪問的單個(gè)全局鎖。數(shù)十個(gè)核心同時(shí)訪問它的話，會(huì)導(dǎo)致鎖成為熱點(diǎn)，造成系統(tǒng)抖動(dòng)和浪費(fèi) CPU 周期。吞吐量沒有翻倍，相反尾部延遲增加，總體吞吐量下降。代理花更多時(shí)間爭(zhēng)奪 freelist 的使用權(quán)，而不是服務(wù)于流量。

起初我們對(duì)自己的分析持懷疑態(tài)度，我們?cè)疽詾?freelist 應(yīng)該會(huì)從中受益。但一旦我們 禁用 它，吞吐量從大約 2k 請(qǐng)求每秒跳升到大約 6k 請(qǐng)求每秒，提高了 3 倍。

無鎖設(shè)計(jì)的隱藏成本

我們與 Read-Copy-Update（RCU） 模式進(jìn)行了斗爭(zhēng)，這是一種在內(nèi)核和高性能用戶空間中流行的模式，用于實(shí)現(xiàn)快速的無鎖讀取。它的權(quán)衡在于每次寫入都需要復(fù)制結(jié)構(gòu)，并且只有在所有活動(dòng)讀取器完成后，才能回收原始內(nèi)存。

在大規(guī)模情況下，即使存在延遲，不斷進(jìn)行 new/delete 周期的成本也會(huì)急劇上升。代理面對(duì)著數(shù)十萬主機(jī)。添加或刪除一個(gè)主機(jī)意味著復(fù)制大型的結(jié)構(gòu)，在流量高峰期間會(huì)導(dǎo)致可觀的內(nèi)存波動(dòng)。無鎖讀取很快，但延遲的內(nèi)存回收成為了降低性能的昂貴代價(jià)。令人驚訝的是，切換回簡(jiǎn)單的基于鎖的方法不僅更有效，而且更可預(yù)測(cè)。

大規(guī)模的 DNS 崩潰

使用 HAProxy 時(shí)，我們?cè)?jīng)遇到一個(gè)故障，揭示了大規(guī)模場(chǎng)景下如何暴露出較小規(guī)模下可以忽略的數(shù)學(xué)問題。內(nèi)置的 DNS 解析器 對(duì)某些場(chǎng)景會(huì)使用 quadratic-time 查找（這意味著查找時(shí)間與記錄或主機(jī)的數(shù)量的平方成比例增長(zhǎng)）。在小型主機(jī)數(shù)量下，額外的工作是可以忽略的，系統(tǒng)能夠順暢運(yùn)行。

但當(dāng)我們?cè)诟蟮呐炾?duì)上啟用這個(gè)代理時(shí)，成本一下子顯現(xiàn)出來。曾經(jīng)只是一個(gè)小問題的事情在數(shù)百臺(tái)主機(jī)上變得難以收拾，這導(dǎo)致整個(gè)代理艦隊(duì)出現(xiàn) CPU 峰值和崩潰。

后來，這個(gè) bug 在上游進(jìn)行了修復(fù)，但教訓(xùn)一直伴隨著我們。低效的行為變得危險(xiǎn)并不一定需要改變它們的復(fù)雜性。有時(shí)，規(guī)模會(huì)使隱藏的成本變得無法忽視。

生產(chǎn)教訓(xùn)：在小規(guī)模下“工作正?！钡拇a可能仍然隱藏著 O(N2) 或更糟的行為。在數(shù)百或數(shù)千個(gè)節(jié)點(diǎn)上，這些成本不再是理論上的，而是真正開始破壞生產(chǎn)環(huán)境。

平凡的故障：

默認(rèn)值和例行任務(wù)的反噬

導(dǎo)致數(shù)十億美元的系統(tǒng)產(chǎn)生崩潰很少是由于冷僻的 zero-days 攻擊或深?yuàn)W的協(xié)議錯(cuò)誤。它們幾乎都是平平無奇的，比如，錯(cuò)位的字符、被遺忘的默認(rèn)值，或者操作系統(tǒng)功能過于完美地執(zhí)行其工作。

引發(fā)致命災(zāi)難的 YAMl 逗號(hào)

對(duì)于某些路由和策略決策，我們的代理會(huì)從遠(yuǎn)程服務(wù)獲取運(yùn)行時(shí)元數(shù)據(jù)。工程師在 UI 中能夠編輯這個(gè)值，它預(yù)期是一個(gè)逗號(hào)分隔的列表（a,b,c）。有一天，LinkedIn 的一位工程師漏掉了一個(gè)逗號(hào)，將列表變成了一個(gè)單一的畸形令牌?？刂品?wù)的驗(yàn)證很少，因此將錯(cuò)誤的載荷傳遞給了下游。我們的代理解析器更嚴(yán)格。當(dāng)代理拉取更新并嘗試將值解釋為列表時(shí)，它無法對(duì)其進(jìn)行處理并導(dǎo)致了崩潰。

因?yàn)檫@些元數(shù)據(jù)對(duì)啟動(dòng)至關(guān)重要，所有需要立即重啟的實(shí)例在獲得相同的錯(cuò)誤值后都會(huì)再次崩潰。更糟糕的是，用戶界面本身就位于代理之后，所以我們無法修復(fù)列表，直到我們執(zhí)行了一次帶外（out-of-band）恢復(fù)。

沉默的殺手：文件描述符和 Watchdogs

基本的操作系統(tǒng)限制可能會(huì)變成災(zāi)難性的失敗。在一次事件中，系統(tǒng)標(biāo)準(zhǔn)化將 最大文件描述符（FD）限制重置為一個(gè)更低的默認(rèn)值，這對(duì)于大多數(shù)應(yīng)用程序來說是合理的，但對(duì)于處理數(shù)十萬個(gè)并發(fā)連接的代理來說卻遠(yuǎn)遠(yuǎn)不夠。在高峰流量期間，代理耗盡了文件描述符（FD）。新的連接和正在進(jìn)行的請(qǐng)求被默默地丟棄或延遲，導(dǎo)致級(jí)聯(lián)故障看起來比實(shí)際情況要復(fù)雜得多。

另一次中斷來自于“例行清理”。一位工程師發(fā)現(xiàn)了在用戶 nobody) 下運(yùn)行的進(jìn)程，并假設(shè)它們是離散的。許多 Unix 服務(wù)（包括我們的代理）故意以 nobody 身份運(yùn)行，以減少權(quán)限。清理腳本在全艦隊(duì)范圍內(nèi)殺死了它們，瞬間使網(wǎng)站的很大一部分癱瘓。

生產(chǎn)教訓(xùn)：最具破壞性的故障往往并不引人注目。它們來自默認(rèn)設(shè)置、不良輸入和每個(gè)人都視為理所當(dāng)然的日常清理任務(wù)。我們要始終將遠(yuǎn)程元數(shù)據(jù)視為不可信的，驗(yàn)證語義，而不僅僅是語法。緩存并回退到已知的最新正確值。將控制平面與數(shù)據(jù)平面解耦，并在金絲雀后面分階段進(jìn)行更改。如果可能的話，優(yōu)先選擇靜態(tài)配置而不是動(dòng)態(tài)元數(shù)據(jù)。在危險(xiǎn)行為之前監(jiān)控資源，并在每個(gè)全艦隊(duì)范圍內(nèi)的行動(dòng)周圍強(qiáng)制執(zhí)行護(hù)欄。

信任但驗(yàn)證：

測(cè)量熱路徑

在大流量的基礎(chǔ)設(shè)施中，缺乏根據(jù)的假設(shè)是一種毒藥。在大規(guī)模環(huán)境中，最小的函數(shù)可以悄悄地消耗不成比例的資源。

不是緩存的緩存頭信息

在代理中解析頭信息是代價(jià)昂貴的操作，我們的許多策略邏輯依賴于檢查特定的頭信息。為了優(yōu)化這一點(diǎn)，我們的代碼庫(kù)使用了一個(gè)名為 extractHeader 的方法，它被注釋為值將會(huì)被緩存，并且頭信息只解析一次。從表面上看，代碼似乎就是這樣工作的，有一個(gè) Boolean 標(biāo)志指示結(jié)果是否已經(jīng)被提取。

然而，當(dāng)我們?cè)诖笠?guī)模環(huán)境中分析 CPU 的使用情況時(shí)，頭信息解析不斷作為一個(gè)瓶頸出現(xiàn)。這有點(diǎn)出乎意料，函數(shù)名稱已經(jīng)承諾會(huì)緩存頭信息。經(jīng)過深入研究，我們發(fā)現(xiàn)多年來，該函數(shù)積累了新的邏輯。在某個(gè)地方，headerExtracted 標(biāo)志被重置了，每次訪問頭信息時(shí)都強(qiáng)制進(jìn)行完整的重新解析。在單個(gè)請(qǐng)求中，同一個(gè)頭信息可以被重新解析數(shù)百次。

調(diào)試持續(xù)了數(shù)周，因?yàn)榉椒ǖ拿Q創(chuàng)造了一種虛假的信任感。它看起來像是緩存，但實(shí)際上幾乎沒有緩存任何東西。

隨機(jī)數(shù)瓶頸

乍看上去，生成隨機(jī)數(shù)像是一個(gè)簡(jiǎn)單的、無狀態(tài)的計(jì)算，是一個(gè)微不足道的、可以忽略的操作。實(shí)際上，常見的rand()實(shí)現(xiàn)依賴于一個(gè)全局鎖來保護(hù)其狀態(tài)。在低 QPS 下，鎖爭(zhēng)用是不可見的。但是，多核心機(jī)器在持續(xù)負(fù)載下，那個(gè)全局鎖就會(huì)變成一個(gè)熱點(diǎn)。請(qǐng)求堆積等待“隨機(jī)性”，本應(yīng)是系統(tǒng)中成本最低的操作之一變成了延遲和吞吐量崩潰的根源。

我們的解決方案是切換到一個(gè)低成本、線程安全的 隨機(jī)數(shù)生成器，它專為并發(fā)設(shè)計(jì)，但是充分汲取了教訓(xùn)。即便是我們認(rèn)為無狀態(tài)的數(shù)學(xué)函數(shù)也可能存在隱藏同步和爭(zhēng)用成本，在大規(guī)模環(huán)境下引發(fā)大問題。

生產(chǎn)教訓(xùn)：永遠(yuǎn)不要假設(shè)“簡(jiǎn)單”的庫(kù)調(diào)用是免費(fèi)的。在熱路徑中對(duì)它們進(jìn)行分析，特別是在多核心、高 QPS 工作負(fù)載下，隱藏的鎖會(huì)將微不足道的函數(shù)變成瓶頸。

蹩腳的頭信息檢查

有些問題不是來自錯(cuò)誤的代碼，而是來自存在隱藏的昂貴副作用的慣用代碼。

一位開發(fā)人員曾經(jīng)用 Go 編寫了一個(gè)簡(jiǎn)單的檢查，以驗(yàn)證 HTTP 頭信息是否為空：

if len(splitted_headers) > 1 { ... }

這是完全慣用的 Go 代碼：清晰、可讀、安全。在單元測(cè)試和小規(guī)模運(yùn)行中，它能夠完美地工作。但在生產(chǎn)環(huán)境中，面對(duì)每秒數(shù)千個(gè)請(qǐng)求，strings.Split的開銷就變得明顯了。每次調(diào)用都會(huì)分配一個(gè)新的切片，在熱路徑中會(huì)創(chuàng)建不必要的混亂。CPU 周期消失在分配操作中，延遲悄然上升。

解決方案也非常簡(jiǎn)單，那就是避免分割。通過直接掃描字符，我們消除了分配操作，并將檢查變成了一個(gè)輕量級(jí)的操作。

生產(chǎn)教訓(xùn)：慣用代碼并不意味著是可以部署到生產(chǎn)環(huán)境的代碼。在測(cè)試中看起來簡(jiǎn)單或無害的操作在大規(guī)模環(huán)境中可能會(huì)成為隱藏的瓶頸。在熱路徑中，缺乏根據(jù)的假設(shè)代價(jià)高昂?？陀^地進(jìn)行分析，相信數(shù)據(jù)而不是假設(shè)。

異常不是常態(tài)：

保持公共路徑的清潔

在分布式系統(tǒng)中，優(yōu)雅往往來自于統(tǒng)一，即一個(gè)規(guī)則涵蓋所有情況。但將正常路徑和異常合并在一起，將會(huì)使系統(tǒng)變得脆弱和緩慢。

哈希鍵爭(zhēng)用

在調(diào)試負(fù)載均衡器中的爭(zhēng)用問題時(shí)，我們注意到每個(gè)請(qǐng)求都要承擔(dān)哈希查找的成本，主機(jī)更新也會(huì)停滯。更令人驚訝的是，哈希表通常只包含一個(gè)鍵。

根本原因是一個(gè)罕見的部署。一個(gè)上游團(tuán)隊(duì)將同一個(gè)應(yīng)用程序拆分到多個(gè)集群中，每個(gè)集群都映射到不同的分片鍵。為了支持這個(gè)案例，代碼被泛化了，總是期望一個(gè)像這樣的結(jié)構(gòu)：

{ app_name => { hash_key1 => host_list1, hash_key2 => host_list2 } }

但對(duì)于幾乎所有的應(yīng)用程序來講，只有一個(gè)主機(jī)列表?；诜制拈g接性是一個(gè)例外，而不是常態(tài)，但它成為了每個(gè)人的默認(rèn)設(shè)置。

我們將其簡(jiǎn)化為：

{ app_name => host_list }

這消除了不必要的哈希查找，消除了更新爭(zhēng)用，并使系統(tǒng)更快、更容易理解。罕見的基于分片的部署會(huì)被明確地進(jìn)行處理，放在了公共路徑之外。

異常情況驅(qū)動(dòng)的錯(cuò)誤修復(fù)

在代理遷移期間，我們最初將大多數(shù)設(shè)置保留為默認(rèn)值。遷移開始后不久，我們收到了一個(gè)涉及異常長(zhǎng)頭信息和 cookie 的罕見用例失敗的報(bào)告。快速修復(fù)是非常簡(jiǎn)單的：提高 限制。問題消失了，直到下周再次出現(xiàn)。我們?cè)俅翁岣吡讼拗?，然后一次又一次，每次都來自同一個(gè)異常。

只有當(dāng)我們進(jìn)行基準(zhǔn)測(cè)試時(shí)，真正的成本才顯現(xiàn)出來：每次提高限制都會(huì)增加內(nèi)存使用量，降低整體吞吐量。通過迎合一個(gè)異常值，我們降低了每個(gè)人的性能。

正確的答案不是讓系統(tǒng)適應(yīng)那個(gè)異常。我們撤銷了對(duì)限制的更改，并要求那個(gè)單一用例繼續(xù)使用舊技術(shù)棧。我們這樣做了之后，新技術(shù)棧立即提供了更高的吞吐量和更低的延遲。團(tuán)隊(duì)最終修復(fù)了有問題的 cookie，并在后來遷移到了新技術(shù)棧。

實(shí)驗(yàn)膨脹

在我們的代理中，我們建立了對(duì)實(shí)驗(yàn)的支持，旨在進(jìn)行快速的 A/B 測(cè)試、功能推出或遷移。該機(jī)制非常有效，但需要仔細(xì)設(shè)置和驗(yàn)證。后來，有人默認(rèn)擴(kuò)展了它：添加了工具來為每個(gè)服務(wù)自動(dòng)生成實(shí)驗(yàn)配置。

起初，這似乎是一個(gè)勝利：減少了手動(dòng)工作，更容易啟動(dòng)。實(shí)際上，大多數(shù)這種實(shí)驗(yàn)都是無效的。它們沒有按預(yù)期工作，但給人的印象它們卻是按照預(yù)期運(yùn)行的，這誤導(dǎo)了運(yùn)維人員。調(diào)試變得很痛苦，因?yàn)槭〉膶?shí)驗(yàn)看起來像是路由問題，而且啟動(dòng)序列經(jīng)常在額外的復(fù)雜性下出現(xiàn)中斷。

最終，我們回滾了更改，移除了默認(rèn)的自動(dòng)生成功能，并要求實(shí)驗(yàn)要明確且逐個(gè)進(jìn)行添加。后來，工具更新為自動(dòng)檢查其他來源是否需要這樣的實(shí)驗(yàn)，并僅在這些場(chǎng)景中添加。這些更新大幅減少了路由規(guī)則的數(shù)量，節(jié)省了關(guān)鍵的 CPU 周期，并保持了網(wǎng)站的穩(wěn)定。

生產(chǎn)教訓(xùn)：永遠(yuǎn)不要讓異常情況決定常態(tài)。明確地處理它們，將其隔離在特定路徑或?qū)又?，而不是污染主線邏輯。看起來像“靈活性”的東西通常只是延遲出現(xiàn)的脆弱性，等待在大規(guī)模場(chǎng)景上顯現(xiàn)。

為高壓下的運(yùn)維人員而設(shè)計(jì)

機(jī)器運(yùn)行著系統(tǒng)，但它們的恢復(fù)需要人類來執(zhí)行。代理可能每秒處理數(shù)百萬請(qǐng)求，但當(dāng)邊緣出現(xiàn)問題時(shí)，系統(tǒng)恢復(fù)依賴于一個(gè)在凌晨 3 點(diǎn)盯著終端的疲憊運(yùn)維人員。

儀表板變黑的場(chǎng)景

在部分停電期間，我們的整個(gè)監(jiān)控和警報(bào)管道都變黑了。儀表盤、追蹤 UI 和服務(wù)發(fā)現(xiàn)控制臺(tái)都離線了，我們甚至不能從受影響的數(shù)據(jù)中心失敗中脫離出去，因?yàn)楣收限D(zhuǎn)移的用戶界面（UI）和命令行界面（CLI）都依賴于已經(jīng)降級(jí)的服務(wù)。拯救我們的是基礎(chǔ)指令：ssh、grep、awk和netstat。有了這些肌肉記憶工具，以及最終在故障轉(zhuǎn)移工具中埋藏的手動(dòng)工具，我們追蹤失敗的流程，隔離了錯(cuò)誤的層，并強(qiáng)制執(zhí)行故障轉(zhuǎn)移。如果團(tuán)隊(duì)失去了對(duì)基礎(chǔ)的舒適感，或者如果沒有那個(gè)逃生艙口，我們就會(huì)手足無措。

我們還痛苦地認(rèn)識(shí)到，可觀測(cè)性系統(tǒng)永遠(yuǎn)不能依賴于它們要監(jiān)控的代理。在某個(gè)時(shí)候，代理日志能夠正確地發(fā)送到一個(gè)中央平臺(tái)，但查看這些日志的 UI 和中央可視化服務(wù)器本身只能通過代理艦隊(duì)進(jìn)行訪問。當(dāng)艦隊(duì)限于泥潭時(shí)，運(yùn)維人員無法再訪問儀表盤。日志仍在流動(dòng)，但我們無法看到它們。

修復(fù)方法是在每個(gè)節(jié)點(diǎn)上保留一個(gè)本地日志路徑，始終可以使用grep和awk等簡(jiǎn)單的 shell 工具訪問它們，即使這意味著冗余。但這保證了無論代理的狀態(tài)如何，都能看到系統(tǒng)。

負(fù)載均衡器的開關(guān)迷宮

另一個(gè)痛點(diǎn)是我們的負(fù)載均衡算法。它試圖處理一切：連接錯(cuò)誤、預(yù)熱、垃圾收集（GC）暫停、流量激增，有幾十種開關(guān)，如閾值、步長(zhǎng)、起始權(quán)重和衰減率。在紙面上，它看起來很強(qiáng)大，但在實(shí)踐中，它是混亂的。

當(dāng)因?yàn)槟撤N情況出現(xiàn)失敗時(shí)，運(yùn)維人員要花費(fèi)數(shù)小時(shí)在黑暗中嘗試調(diào)整各種開關(guān)，這有時(shí)能解決問題，有時(shí)卻讓問題變得更糟。想象一下凌晨 3 點(diǎn)的緊急呼叫，緊接著是六個(gè)小時(shí)的猜測(cè)性工作。最終，我們放棄了復(fù)雜性，轉(zhuǎn)而采用了一個(gè)簡(jiǎn)單的基于時(shí)間的預(yù)熱機(jī)制，類似于 HAProxy 的慢啟動(dòng)。恢復(fù)變得可預(yù)測(cè)、流程化且快速，這是最好的運(yùn)維結(jié)果。

生產(chǎn)教訓(xùn)：運(yùn)維人員不會(huì)在完美條件下使用完美的儀表盤進(jìn)行調(diào)試。他們會(huì)使用即便其他一切都在宕機(jī)時(shí)仍然有效的工具進(jìn)行調(diào)試。設(shè)計(jì)你的邊緣層，以便在功能豐富的工具消失時(shí)，基本的日志、純文本、簡(jiǎn)單命令仍然能給運(yùn)維人員足夠的信息去觀察和行動(dòng)。

結(jié) 論

反向代理是現(xiàn)代基礎(chǔ)設(shè)施中最繁忙和最脆弱的點(diǎn)。我們的教訓(xùn)并不是來源于冷僻的協(xié)議或尖端算法，而是在規(guī)模擴(kuò)大時(shí)才會(huì)出現(xiàn)的隱性成本、普通故障和運(yùn)維人員現(xiàn)狀。通過保持公共路徑的精簡(jiǎn)，驗(yàn)證每一個(gè)假設(shè)，并為處于壓力狀態(tài)的運(yùn)維人員設(shè)計(jì)功能，我們可以使得這個(gè)關(guān)鍵層既具有彈性又流程化，這是所有生產(chǎn)系統(tǒng)的理想結(jié)果。

When Reverse Proxies Surprise You: Hard Lessons from Operating at Scale(https://www.infoq.com/articles/scaling-reverse-proxies/)

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。