項(xiàng)目背景

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

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

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

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

再談 ElasticSearch

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

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

事件回溯

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

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

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

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

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

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

圖三：Postman 界面似乎可以取消尚未完成的請(qǐng)求

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

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

事情仍有轉(zhuǎn)機(jī)

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

所以擺在面前的選項(xiàng)就只有：

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

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

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

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

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

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

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

橫向擴(kuò)展根本指望不上

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

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

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

基于角色的訪問機(jī)制

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

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

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

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

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

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

寫在最后

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

審核編輯 ：李倩