作者 | Mitendra Mahto

譯者 | 張衛(wèi)濱

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

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

它的麻煩在于代理很少以整潔、教科書式的方式失敗。相反，有時候它們會在優(yōu)化基準測試中表現(xiàn)出色，但是在真實工作負載下卻會崩潰；因為元數(shù)據(jù)中缺失了一個逗號，導致實時流量悄無聲息地中斷，它們也會因此而失敗。它們還可能因為旨在簡化技術(shù)棧的抽象變成了隱藏的脆弱點而失敗。

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

優(yōu)化陷阱：

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

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

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

Freelist 爭用災難

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

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

起初我們對自己的分析持懷疑態(tài)度，我們原本以為 freelist 應該會從中受益。但一旦我們 禁用 它，吞吐量從大約 2k 請求每秒跳升到大約 6k 請求每秒，提高了 3 倍。

無鎖設計的隱藏成本

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

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

大規(guī)模的 DNS 崩潰

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

但當我們在更大的艦隊上啟用這個代理時，成本一下子顯現(xiàn)出來。曾經(jīng)只是一個小問題的事情在數(shù)百臺主機上變得難以收拾，這導致整個代理艦隊出現(xiàn) CPU 峰值和崩潰。

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

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

平凡的故障：

默認值和例行任務的反噬

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

引發(fā)致命災難的 YAMl 逗號

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

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

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

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

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

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

信任但驗證：

測量熱路徑

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

不是緩存的緩存頭信息

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

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

調(diào)試持續(xù)了數(shù)周，因為方法的名稱創(chuàng)造了一種虛假的信任感。它看起來像是緩存，但實際上幾乎沒有緩存任何東西。

隨機數(shù)瓶頸

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

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

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

蹩腳的頭信息檢查

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

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

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

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

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

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

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

保持公共路徑的清潔

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

哈希鍵爭用

在調(diào)試負載均衡器中的爭用問題時，我們注意到每個請求都要承擔哈希查找的成本，主機更新也會停滯。更令人驚訝的是，哈希表通常只包含一個鍵。

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

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

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

我們將其簡化為：

{ app_name => host_list }

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

異常情況驅(qū)動的錯誤修復

在代理遷移期間，我們最初將大多數(shù)設置保留為默認值。遷移開始后不久，我們收到了一個涉及異常長頭信息和 cookie 的罕見用例失敗的報告?？焖傩迯褪欠浅：唵蔚模禾岣?限制。問題消失了，直到下周再次出現(xiàn)。我們再次提高了限制，然后一次又一次，每次都來自同一個異常。

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

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

實驗膨脹

在我們的代理中，我們建立了對實驗的支持，旨在進行快速的 A/B 測試、功能推出或遷移。該機制非常有效，但需要仔細設置和驗證。后來，有人默認擴展了它：添加了工具來為每個服務自動生成實驗配置。

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

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

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

為高壓下的運維人員而設計

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

儀表板變黑的場景

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

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

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

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

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

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

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

結(jié) 論

反向代理是現(xiàn)代基礎(chǔ)設施中最繁忙和最脆弱的點。我們的教訓并不是來源于冷僻的協(xié)議或尖端算法，而是在規(guī)模擴大時才會出現(xiàn)的隱性成本、普通故障和運維人員現(xiàn)狀。通過保持公共路徑的精簡，驗證每一個假設，并為處于壓力狀態(tài)的運維人員設計功能，我們可以使得這個關(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)載。