誤刪ElasticSearch生產(chǎn)數(shù)據(jù)庫后的復(fù)盤

項目背景

這件事情發(fā)生在幾年前時，當(dāng)時我在一家初創(chuàng)的電子商務(wù)公司就職，主要負責(zé)領(lǐng)導(dǎo)兩支團隊開發(fā)幾項核心后臺功能。后臺的作用是管理在前端當(dāng)中向全球用戶開放的信息，這些信息又分別由不同的團隊維護。雖然這家公司歷史不長，但已經(jīng)在全球市場上建立起影響力，坐擁數(shù)十萬用戶群體。

其中一支團隊開發(fā)了支持大部分后臺流程和工具的主要后臺產(chǎn)品目錄，存放著庫存、產(chǎn)品信息管理、訂單履行流程等大量內(nèi)容。這個組件相當(dāng)關(guān)鍵，大多數(shù)后臺服務(wù)、應(yīng)用程序和業(yè)務(wù)流程都會以某種方式進行訪問。具體情況可以參考下圖：

圖一：非規(guī)范化讀取模型的簡化架構(gòu)示意

該平臺采用的是微服務(wù)架構(gòu)，其中產(chǎn)品目錄屬于讀取模型，包含由多個不同領(lǐng)域事件流建立而成的非規(guī)范化信息，再由其他微服務(wù)加以管理。產(chǎn)品目錄本身由一個 ElasticSearch 數(shù)據(jù)庫支持，其中容納共 1700 萬種產(chǎn)品，具體涉及產(chǎn)品元數(shù)據(jù)、庫存、生產(chǎn)信息、可用性、定價等，而且全部都向 REST API 開放。我們之所以使用 ElasticSearch，主要是因為需要配合大量不同種類的過濾器（共有 50 多種不同過濾器，其中一些還帶有文本搜索功能）。

再談 ElasticSearch

正常來講，沒人能直接向數(shù)據(jù)庫發(fā)起寫入（我們在不同用例中使用到了多種技術(shù)，包括 SQLServer、MongoDB 和 Cassandra 等），但 ElasticSearch 卻是個例外。畢竟在傳統(tǒng)上，ElasticSearch 應(yīng)該是由工程團隊，而非基礎(chǔ)設(shè)施或 DBA 團隊進行管理。與其他數(shù)據(jù)庫技術(shù)不同，ElasticSearch 是通過 REST 接口訪問的。通常，URL 具有以下格式（當(dāng)時我們使用的是 ElasticSearch 版本 5）：{cluster_endpoint}/{index_name}/{type}/{document_id}(例如: elastic.com/productIndex/product/152474145)這種類型在后續(xù)版本中被刪除了。

其中任何類型的操作都是通過 HTTP 調(diào)用或者 SQL 腳本完成的。就是說在 ElasticSearch 當(dāng)中，我們肯定要用到 HTTP 請求。比如說根據(jù) REST 指南，如果用戶擁有一套產(chǎn)品目錄索引（ElasticSearch 中的索引基本相當(dāng)于 SQL 表）并想獲取特定產(chǎn)品，則需要執(zhí)行 GET elastic.com/productIndex/product/152474145。更新的時候，需要使用 PUT 或 PATCH 操作操作這個端點，刪除的時候用 DELETE，創(chuàng)建的時候則是用 POST 或 PUT。另外，這些操作還可以指向 URL 中的不同部分，比如對 elastic.com/productIndex/product 執(zhí)行 GET 可以獲取類型信息，創(chuàng)建、刪除或者更新等操作也是同理。如果指向的是 elastic.com/productIndex，則代表獲取索引信息、更新、刪除或創(chuàng)建索引。

事件回溯

那是一個普通的禮拜五，一整天大家都在不停地開會，反正上班的日常就那個樣子。為了處理臨時任務(wù)，比如幫助同事解決問題或者根據(jù)團隊申請幫他們完成無權(quán)進行的操作，我抓住了會議之間的一點點小閑暇。這時候，我看到一條請求希望通過 API 中本不可用的過濾器導(dǎo)出一些數(shù)據(jù)。這操作挺少見的，但考慮到對方團隊很著急、理由又充分，我們還是決定出手相助。

于是趁著下場會議還有 15 分鐘，我迅速連上另一位高級管理員，想要快速訪問實時環(huán)境并執(zhí)行查詢。由于對 ElasticSearch 的直接訪問在本質(zhì)上就是對接 REST API，所以我們習(xí)慣性地使用 Postman 來執(zhí)行請求。

這位同事通過遠程屏幕共享向我開放了操作平臺。其實我的工作習(xí)慣還好，一般會對實時操作先進行一番代碼審查。所以我想先測試一下連接，確保自己拿到的 URL 正確無誤。于是我復(fù)制了實時端點和索引名稱（類似于我們前文討論過的 cluster_endpoint/index_name），并提交了一條 GET 請求。如果大家熟悉 Postman 界面，應(yīng)該會記得在下拉列表中選擇 HTTP 操作的過程：

圖二：在 Postman 界面中選擇 HTTP 操作

很遺憾，我在提交了請求之后，才注意到自己把操作錯選成了 DELETE，而不是 GET。操作的結(jié)果根本不是檢索索引信息，而是直接將其刪除。

這條請求要花幾秒鐘才會確認(rèn)，所以我立刻按下了取消按鈕。取消操作立即提示成功，我的心里又涌起一絲希望，天真地認(rèn)為事情已經(jīng)過去、剛剛那些都是幻覺。

圖三：Postman 界面似乎可以取消尚未完成的請求

但很遺憾，知道我要取消的就只有 Postman 的客戶端；實際操作仍然一路狂奔，抵達了 ElasticSearch 服務(wù)器端。我試著用不加過濾條件的常規(guī)搜索確認(rèn)了索引總數(shù)，而期待中的 1700 萬結(jié)果并沒有出現(xiàn)，查詢返回的結(jié)果只有幾百條（我們的服務(wù)每秒大約發(fā)生 70 個事件，剩下的這幾百條應(yīng)該是刪除同時發(fā)生的產(chǎn)品創(chuàng)建 / 編輯操作）。

情況就是這么個情況，我不小心把產(chǎn)品目錄里 1700 萬條產(chǎn)品記錄、來自整個平臺數(shù)十項微服務(wù)的信息還有自己的職業(yè)聲譽，全都搞砸了……

事情仍有轉(zhuǎn)機

跟老板通話之后，我們很快組織起作戰(zhàn)指揮室，處理各個服務(wù)區(qū)上報的問題。由于這套系統(tǒng)的本質(zhì)就是個讀取模型，而非任何特定信息的真實來源，所以我們“只需要”從其他服務(wù)那邊獲取信息就行。

所以擺在面前的選項就只有：

ElasticSearch 無法在發(fā)生重大變更時隨之調(diào)整 schema，它的基本策略還是將所有信息重新導(dǎo)入新的索引當(dāng)中。為此，我們設(shè)計了一款組件，能夠同步 REST API 以從其他微服務(wù)處獲取數(shù)據(jù)，重新構(gòu)建每款產(chǎn)品。在它的幫助下，我們能夠解決上游服務(wù)發(fā)生的錯誤，應(yīng)對突發(fā)事件引起的一致性沖突。但是，獲取全部 1700 萬種產(chǎn)品的所有數(shù)據(jù)大概要花六天時間。管不了那么多了，我們決定馬上跑起來。

圖四：Catalog Updater 架構(gòu)——目錄重建組件

另外一個選擇就是使用事件流。大多數(shù)服務(wù)都能在必要時重新發(fā)布事件，某些關(guān)鍵區(qū)域還具備數(shù)據(jù)重播功能，這些數(shù)據(jù)可以跟正常使用中的變更順暢合流、為用戶服務(wù)。

而最大的希望也在于這里。在此之前的幾天，我們剛剛在 schema 當(dāng)中做了一次重大變更，所以需要創(chuàng)建新的索引版本來重新索引全部信息。因為需要同時在新舊兩個版本中接納新近變更，所以重新索引過程相當(dāng)漫長。我們此前已經(jīng)對舊索引做好了分析，而需要進行重大變更的新功能其實不怎么重要，就是說現(xiàn)在我們手頭已經(jīng)有了一套完全可以接受的舊索引版本。雖然數(shù)據(jù)還是延遲了幾天，但畢竟要比空空如也好得多。所以在綜合討論了幾種方案之后，我們最終成功解決了這場突發(fā)危機。

經(jīng)驗教訓(xùn) 備份與重建速度

備份的必要性已經(jīng)無需多言。我們的大多數(shù)數(shù)據(jù)庫都有備份，但卻沒有給 ElasticSearch 數(shù)據(jù)庫做好相應(yīng)的保護。另外，該數(shù)據(jù)庫本身屬于讀取模型，所以根據(jù)定義并不作為任何真實來源。理論上，讀取模型就不該需要備份，因為可以快速重建，確保在發(fā)生重大事件時也不會造成太過嚴(yán)重的影響。由于讀取模型所容納的基本都是從其他來源推斷出的信息，所以很難確定到底值不值得做定期備份。但在實踐中，我們發(fā)現(xiàn)要在不影響用戶體驗的同時重建模型，絕對是個令人頭痛的大麻煩。如果是只有幾百或幾千條記錄的小模型還好，但像我們這種覆蓋幾十個不同來源、承載上千萬條信息的讀取模型就完全是另一碼事了。

我們最終決定把兩種選項結(jié)合起來，成功將重建流程從六天縮短到了幾個小時。但由于這套數(shù)據(jù)庫太過重要，所以這幾個小時的宕機還是會給用戶造成重大影響，特別是在銷售季等特定活動期間。我們也可以想辦法進一步縮短重建時長，但具體方案感覺有點過度設(shè)計，而且會產(chǎn)生大量額外的基礎(chǔ)設(shè)施成本。所以我們決定只在風(fēng)險較高的時段內(nèi)進行備份，例如在促銷季活動或其他關(guān)鍵業(yè)務(wù)執(zhí)行期間。

橫向擴展根本指望不上

大家常說，選擇微服務(wù)的一大核心優(yōu)勢就是良好的橫向擴展能力。但從圖四能夠看到，這種擴展只能依賴于同步 API，所以橫向擴展可以說根本指望不上。負責(zé)重建讀取模型的組件需要整整六天才能執(zhí)行完成，雖然理論上可以通過橫向擴展把時間大大縮短，但問題是它仍然要靠 REST API 來檢索信息。它通過 REST 請求從其他各項微服務(wù)處請求數(shù)據(jù)，構(gòu)建起非規(guī)范化視圖和持久化狀態(tài)。所以直接橫向擴展會觸發(fā)大量指向其他服務(wù)的請求，而那些服務(wù)并沒有做好處理高強度額外負載的準(zhǔn)備，所以可能還需要再各自擴展。這必然引發(fā)連鎖反應(yīng)，最終令整個平臺走向崩潰的邊緣。另外，其中大多數(shù)微服務(wù)還高度依賴數(shù)據(jù)庫，所以微服務(wù)的擴展又會引發(fā)相應(yīng)數(shù)據(jù)庫的擴展。

我們確實進行了擴展，只是把擴展量控制在很保守的水平。而即使是這樣，其他服務(wù)也有點招架不住，出現(xiàn)了可以感知到的影響?，F(xiàn)在來看，整個微服務(wù)架構(gòu)并不像我們想象中那樣高度解耦，反而很像是當(dāng)初的單體架構(gòu)。更要命的是，它沒有分布式的優(yōu)勢、卻得了分布式的病，管理起來異常麻煩。

所以在重建組件時，我們選擇了純事件流的方法。這種方式雖然也有問題，但至少能讓系統(tǒng)真正具有解耦性。就是說組件的擴展只影響對應(yīng)資源，這才是真正具備橫向擴展能力的設(shè)計。這里還有另一個設(shè)計難題，就是事件應(yīng)該大一些還是小一些。至少對讀取模型來說，事件還是越大越好。我們還用到一項有趣的策略，就是使用了帶有 Kafka 壓縮主題的文檔，借此大大提升速度和擴展能力。這種方法能把重建策略從批處理轉(zhuǎn)化成流處理。與通過 HTTP 請求獲取數(shù)據(jù)不同，事件流上的數(shù)據(jù)有著更低的獲取難度和更快的獲取速度，原因就是它的網(wǎng)絡(luò)延遲更低，而且不用靠中間服務(wù)從數(shù)據(jù)庫內(nèi)獲取數(shù)據(jù)，一切就在事件流上。另外，事件流的真解耦性也讓整個過程實現(xiàn)了橫向擴展，再不用擔(dān)心對其他服務(wù)產(chǎn)生意外影響。

基于角色的訪問機制

事件發(fā)生之后，我們開始全力推行基于角色的訪問控制。之前我們使用的是舊版 ElasticSearch，它只提供非常基礎(chǔ)的用戶身份驗證，而更靠譜的 XPack 在這個版本里是要收費的。不過在后續(xù)更新中，XPack 也被加入了免費許可證套餐，真正是好用又不貴了。

所以，我們遷移到了 ElasticSearch 版本 7 并創(chuàng)建了不同的讀寫角色。最終，只有應(yīng)用程序能夠定期直接寫入數(shù)據(jù)庫，用戶最多只能直接讀取。

責(zé)任不在人，而在流程

每當(dāng)出現(xiàn)問題，我總會向技術(shù)團隊強調(diào)，最大的責(zé)任不在于人，而在于糟糕的流程。我們需要分析流程中的哪個環(huán)節(jié)出了問題并找到解決辦法，避免任何人——無論是剛剛?cè)肼毜男聠T工，還是經(jīng)驗豐富的老伙伴——再犯同樣的錯誤。

我一直秉持這樣的管理思路，也時時處處用這樣的方式管理工作、處理事件。雖然這事已經(jīng)過去幾年了，雖然我還是會偶爾想起這一切并尷尬地苦笑，但這個契機確實也給我們帶來了更合理的操作流程。我們調(diào)整了實時數(shù)據(jù)的訪問方式，消除了直接進行寫入操作的權(quán)限。甚至對于讀取訪問，我們也開始采取更審慎的態(tài)度，畢竟惡意查詢很可能對 ElasticSearch 資源產(chǎn)生的可怕的影響，某些極端復(fù)雜的查詢（例如高深度分頁）甚至?xí)l(fā)集群崩潰（例如超過客戶端節(jié)點的內(nèi)存上限）。我想再強調(diào)一句，這不是要剝奪團隊的自主權(quán)，而是幫助大家盡量少犯錯。

臨時請求會被提交給專管這類請求的實時工程團隊，所以正常來講大家根本不需要直接訪問數(shù)據(jù)庫。手動重復(fù)任務(wù)已經(jīng)被整合進對應(yīng)服務(wù)的功能當(dāng)中，并通過應(yīng)用層加以適當(dāng)驗證，這就消除了出現(xiàn)意外刪除或大量查詢的可能性?？傮w來講，我們的調(diào)整就是要確保人們能夠用適當(dāng)?shù)墓ぞ咄瓿晒ぷ?、響?yīng)業(yè)務(wù)請求，而且始終保持安全穩(wěn)定。

寫在最后

其實在鬧出這事之前，我在很多文章里都讀到過類似的情景，但從沒想過有一天自己會成為故事的主角。那時候我的想法很簡單，“我做事是講套路的，絕對不會輕易下手?！钡袝r候，難以挽回的錯誤可能只需要一瞬間的分心、一瞬間的疏忽。這段經(jīng)歷教會了我要永遠保持謙卑，我也大大方方把這個故事講給每位團隊成員聽，讓他們知道技術(shù)負責(zé)人也一樣可能會犯低級錯誤。所以最重要的還是給自己加上點約束，避免我們“愚蠢的一面有機可乘”。

審核編輯 ：李倩