項目背景

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

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

圖一：非規范化讀取模型的簡化架構示意

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

再談 ElasticSearch

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

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

事件回溯

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

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

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

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

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

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

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

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

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

事情仍有轉機

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

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

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

圖四：Catalog Updater 架構——目錄重建組件

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

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

經驗教訓 備份與重建速度

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

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

橫向擴展根本指望不上

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

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

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

基于角色的訪問機制

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

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

責任不在人，而在流程

每當出現問題，我總會向技術團隊強調，最大的責任不在于人，而在于糟糕的流程。我們需要分析流程中的哪個環節出了問題并找到解決辦法，避免任何人——無論是剛剛入職的新員工，還是經驗豐富的老伙伴——再犯同樣的錯誤。

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

臨時請求會被提交給專管這類請求的實時工程團隊，所以正常來講大家根本不需要直接訪問數據庫。手動重復任務已經被整合進對應服務的功能當中，并通過應用層加以適當驗證，這就消除了出現意外刪除或大量查詢的可能性?？傮w來講，我們的調整就是要確保人們能夠用適當的工具完成工作、響應業務請求，而且始終保持安全穩定。

寫在最后

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

審核編輯 ：李倩