基于 Elasticsearch 的通用搜索是螞蟻內部最大的搜索產品，目前擁有上萬億文檔，服務了上百個業務方。而通用搜索的發展主要分為兩個階段：平臺化和中臺化。

[[249346]]

本文作者將從以下幾個方面介紹在這兩個階段的發展中為業務解決了哪些痛點以及是如何去解決這些痛點的：

• 源動力

• ES 平臺

• 回看業務

• 搜索中臺

 

源動力：架構復雜、運維艱難

 

 

和大多數大型企業一樣，螞蟻內部也有一套自研的搜索系統，我們稱之為主搜。

 

但是由于這種系統可定制性高，所以一般業務接入比較復雜，周期比較長。而對于大量新興的中小業務而言，迭代速度尤為關鍵，因此難以用主搜去滿足。

 

主搜不能滿足，業務又實際要用，怎么辦呢？那就只能自建了。在前幾年螞蟻內部有很多小的搜索系統，有 ES，也有 Solr，甚至還有自己用 Lucene 的。

 

 

業務痛點

 

 

業務由于自身迭代速度很快，去運維這些搜索系統成本很大。就像 ES，雖然搭建一套很是簡單，但是用在真實生產環境中還是需要很多專業知識的。

 

作為業務部門很難去投入人力去運維維護。并且由于螞蟻自身的業務特性，很多業務都是需要高可用保證的。

 

而我們都知道 ES 本身的高可用目前只能跨機房部署了，先不談跨機房部署時的分配策略，光是就近訪問一點，業務都很難去完成。

 

因為這些原因，導致這類場景基本都沒有高可用，業務層寧愿寫兩套代碼，準備一套兜底方案。他們覺得容災時直接降級也比高可用簡單。

 

 

架構痛點

 

從整體架構層面看，各個業務自行搭建搜索引擎造成了煙囪林立，各種重復建設。

 

并且這種中小業務一般數據量都比較小，往往一個業務一套三節點集群只有幾萬條數據，造成整體資源利用率很低。

 

而且由于搜索引擎選用的版本，部署的方式都不一致，也難以保證質量。在架構層面只能當做不存在搜索能力。

 

 

低成本，高可用，少運維的 Elasticsearch 平臺應運而生

 

 

基于以上痛點，我們產生了構建一套標準搜索平臺的想法，將業務從運維中解放出來，也從架構層面統一基礎設施，提供一種簡單可信的搜索服務。

 

架構圖如下：

如何做低成本，高可用，少運維呢？我們先來一起看一下整體架構，如上圖。

 

首先說明一下我們這兩個框框代表兩個機房，我們整體就是一種多機房的架構，用來保證高可用：

• 最上層是用戶接入層，有 API，Kibana，Console 三種方式，用戶和使用 ES 原生的 API 一樣可以直接使用我們的產品。

• 中間為路由層（Router)，負責將用戶請求真實發送到對應集群中，負責一些干預處理邏輯。

• 下面每個機房中都有隊列（Queue），負責削峰填谷和容災多寫。

• 每個機房中有多個 ES 集群，用戶的數據最終落在一個真實的集群中，或者一組對等的高可用集群中。

• 右邊紅色的是 Meta，負責所有組件的一站式自動化運維和元數據管理。

• 最下面是 Kubernetes，我們所有的組件均是以容器跑在 K8S 上的，這解放了我們很多物理機運維操作，使得滾動重啟這些變得非常方便。

 

低成本：多租戶

看完了整體，下面就逐點介紹下我們是怎么做的，第一個目標是低成本。在架構層面，成本優化是個每年必談的話題。

 

那么降低成本是什么意思？實際上就是提高資源利用率。提高資源利用率方法有很多，比如提高壓縮比，降低查詢開銷。但是在平臺上最簡單有效的方式則是多租戶。

 

今天我就主要介紹下我們的多租戶方案：多租戶的關鍵就是租戶隔離，租戶隔離分為邏輯隔離和物理隔離。

 

邏輯隔離

首先介紹下我們的邏輯隔離方案，邏輯隔離就是讓業務還是和之前自己搭 ES 一樣的用法，也就是透明訪問。

 

但是實際上訪問的只是真實集群中屬于自己的一部分數據，而看不到其他人的數據，也就是保證水平權限。

 

而 ES 有一點很適合用來做邏輯隔離，ES 的訪問實際上都是按照 Index 的。因此我們邏輯隔離的問題就轉化為如何讓用戶只能看到自己的表了。

 

我們是通過 Console 保存用戶和表的映射關系，然后在訪問時通過 Router，也就是前面介紹的路由層進行干預，使得用戶只能訪問自己的 Index。

 

具體而言，我們路由層采用 OpenResty+Lua 實現，將請求過程分為了右圖的四步：Dispatch，Filter，Router，Reprocess。

 

①在 Dispatch 階段我們將請求結構化，抽出其用戶，App，Index，Action 數據。

 

②然后進入 Filter 階段，進行寫過濾和改寫。

 

Filter 又分為三步：

• Access 進行限流和驗權這類的準入性攔截。

• Action 對具體的操作進行攔截處理，比如說 DDL，也就是建表，刪表，修改結構這些操作，我們將其轉發到 Console 進行處理。

  一方面方便記錄其 Index 和 App 的對應信息；另一方面由于建刪表這種還是很影響集群性能的，我們通過轉發給 Console 可以對用戶進行進一步限制，防止惡意行為對系統的影響。

• Params 則是請求改寫，在這一步我們會根據具體的 Index 和 Action 進行相應的改寫。

  比如去掉用戶沒有權限的 Index；比如對于 Kibana 索引將其改為用戶自己的唯一 Kibana 索引以實現 Kibana 的多租戶；比如對 ES 不同版本的簡單兼容。

  在這一步我們可以做很多，不過需要注意的有兩點：一是盡量不要解析 Body，解 Body 是一種非常影響性能的行為，除了特殊的改寫外應該盡力避免，比如 Index 就應該讓用戶寫在 URL 上，并利用 ES 本身的參數關閉 Body 中指定 Index 的功能，這樣改寫速度可以快很多。

  二是對于 _all 和 getMapping 這種對所有 Index 進行訪問的，如果我們替換為用戶所有的索引會造成 URL 過長，我們采用的是創建一個和應用名同名的別名，然后將其改寫成這個別名。

 

③進行完 Filter 就到了真實的 Router 層，這一層就是根據 Filter 的結果做真實的路由請求，可能是轉發到真實集群也可能是轉發到我們其他的微服務中。

 

④最后是 Reprocess ,這是拿到業務響應后的最終處理，我們在這邊會對一些結果進行改寫，并且異步記錄日志。

 

上面這四步就是我們路由層的大致邏輯，通過 App 和 Index 的權限關系控制水平權限，通過 Index 改寫路由進行共享集群。

 

物理隔離

做完了邏輯隔離，我們可以保證業務的水平權限了，那么是否就可以了呢？

 

顯然不是的，實際中不同業務訪問差異還是很大的，只做邏輯隔離往往會造成業務間相互影響。

 

這時候就需要物理隔離了。不過物理隔離我們目前也沒有找到非常好的方案，這邊給大家分享下我們的一些嘗試。

 

首當其沖，我們采用的方法是服務分層，也就是將不同用途，不同重要性的業務分開，對于關鍵性的主鏈路業務甚至可以獨占集群。

 

對于其他的，我們主要分為兩類：寫多查少的日志型和查多寫少的檢索型業務，按照其不同的要求和流量預估將其分配在我們預設的集群中。

 

不過需要注意的是申報的和實際的總會有差異的，所以我們還有定期巡檢機制，會將已上線業務按照其真實流量進行集群遷移。

 

做完了服務分層，我們基本可以解決了低重要性業務影響高重要性業務的場景，但是在同級業務中依舊會有些業務因為比如說做營銷活動這種造成突發流量。

 

對于這種問題怎么辦？一般而言就是全局限流，但是由于我們的訪問都是長連接，所以限流并不好做。

 

如右圖所示，用戶通過一個 LVS 訪問了我們多個 Router，然后我們又通過了 LVS 訪問了多個 ES 節點，我們要做限流，也就是要保證所有 Router 上的令牌總數。

 

一般而言全局限流有兩種方案：

• 一是以限流維度將所有請求打在同一實例上，也就是將同一表的所有訪問打在一臺機器上。

  但是在 ES 訪問量這么高的場景下，這種并不合適，并且由于我們前面已經有了一層 LVS 做負載均衡，再做一層路由會顯得過于復雜。

• 第二種方案就是均分令牌，但是由于長連接的問題，會造成有些節點早已被限流，但是其他節點卻沒有什么流量。

 

那么怎么辦呢？

既然是令牌使用不均衡，那么我們就讓其分配也不均衡就好了唄。所以我們采用了一種基于反饋的全局限流方案，什么叫基于反饋呢？

 

就是我們用巡檢去定時采集用量，用的多就多給一些，用的少就少給你一點。

 

那么多給一些少給一點到底是什么樣的標準呢？這時我們就需要決策單元來處理了，目前我們采取的方案是簡單的按比例分配。

 

這邊需要注意的一點是當有新機器接入時，不是一開始就達到終態的，而是漸進的過程。

 

所以需要對這個收斂期設置一些策略，目前因為我們機器性能比較好，不怕突發毛刺，所以我們設置的是全部放行，到穩定后再進行限流。

 

這里說到長連接就順便提一個 Nginx 的小參數：keepalive_timeout。用過 Nginx 的同學應該都見過，表示長連接超時時間，默認有 75s。

 

但是這個參數實際上還有一個可選配置，表示寫在響應頭里的超時時間，如果這個參數沒寫的話就會出現在服務端釋放的瞬間客戶端正好復用了這個連接，造成 Connection Reset 或者 NoHttpResponse 的問題。

 

出現頻率不高，但是真實影響用戶體驗，因為隨機低頻出現，我們之前一直以為是客戶端問題，后來才發現原來是這個釋放順序的問題。

 

至此服務分層，全局限流都已經完成了，是不是可以睡個好覺了呢？ 很遺憾，還是不行，因為 ES 語法非常靈活，并且有許多大代價的操作。

 

比如上千億條數據做聚合，或者是用通配符做個中綴查詢，寫一個復雜的 Script 都有可能造成拖垮我們整個集群，那么對于這種情況怎么辦呢？ 

 

我們目前也是處于探索階段，比較有用的一種方式是事后補救，也就是我們通過巡檢去發現一些耗時大的 Task，然后對其應用的后繼操作進行懲罰，比如降級，甚至熔斷。

 

這樣就可以避免持續性的影響整個集群。但是一瞬間的 RT 上升還是不可避免的，因此我們也在嘗試事前攔截，不過這個比較復雜，感興趣的同學可以一起線下交流一下。

 

高可用：對等多集群

 

講完了低成本，那么就來到了我們第二個目標，高可用。正如我之前提到那樣，ES 本身其實提供了跨機房部署的方案，通過打標就可以進行跨機房部署，然后通過 Preference 可以保證業務就近查詢。

 

我這里就不再詳細說了，但是這種方案需要兩地三中心， 而我們很多對外輸出的場景出于成本考慮，并沒有三中心，只有兩地兩中心，因此雙機房如何保證高可用就是我們遇到的一個挑戰。

 

下面我主要就給大家分享下我們基于對等多機房的高可用方案，提供了兩種類型，共三種方案分別適用于不同的業務場景。

 

我們有單寫多讀和多寫多讀兩種類型：單寫多讀我們采用的是跨集群復制的方案，通過修改 ES，我們增加了利用 Translog 將主集群數據推送給備庫的能力。

 

就和 6.5 的 ccr 類似，但是我們采用的是推模式，而不是拉模式，因為我們之前做過測試，對于海量數據寫入，推比拉的性能好了不少。

 

容災時進行主備互換，然后恢復后再補上在途數據。由上層來保證單寫，多讀和容災切換邏輯。

 

這種方案通過 ES 本身的 Translog 同步，部署結構簡單，數據也很準確，類似于數據庫的備庫，比較適合對寫入 RT 沒有過高要求的高可用場景。

多寫多讀，我們提供了兩種方案：

• 第一種方案比較取巧，就是因為很多關鍵鏈路的業務場景都是從 DB 同步到搜索中的，因此我們打通了數據通道，可以自動化的從 DB 寫入到搜索，用戶無需關心。

  那么對于這類用戶的高可用，我們采用的就是利用 DB 的高可用，搭建兩條數據管道，分別寫入不同的集群。這樣就可以實現高可用了，并且還可以絕對保證最終一致性。

• 第二種方案則是在對寫入 RT 有強要求，有沒有數據源的情況下，我們會采用中間層的多寫來實現高可用。

  我們利用消息隊列作為中間層，來實現雙寫。就是用戶寫的時候，寫成功后保證隊列也寫成功了才返回成功，如果一個不成功就整體失敗。

  然后由隊列去保證推送到另一個對等集群中。用外部版本號去保證一致性。但是由于是中間層，對于 Delete by Query 的一致性保證就有些無能為力了。所以也僅適合特定的業務場景。

 

最后，在高可用上我還想說的一點是對于平臺產品而言，技術方案有哪些，怎么實現的業務其實并不關心，業務關心的僅僅是他們能不能就近訪問降低 RT，和容災時自動切換保證可用。

 

因此我們在平臺上屏蔽了這些復雜的高可用類型和這些適用的場景，完全交由我們的后端去判斷，讓用戶可以輕松自助接入。

 

并且在交互上也將讀寫控制，容災操作移到了我們自己系統內，對用戶無感知。

 

只有用戶可以這樣透明擁有高可用能力了，我們的平臺才真正成為了高可用的搜索平臺。

 

少運維

 

最后一個目標，少運維，就簡單介紹一下我們在整體運維系統搭建過程中沉淀出的四個原則：

• 自包含：ES 做的就很不錯了，一個 Jar 就可以啟動，而我們的整套系統也都應該和單個 ES 一樣，一條很簡單的命令就能啟動，沒有什么外部依賴，這樣就很好去輸出。

• 組件化：是指我們每個模塊都應該可以插拔，來適應不同的業務場景，比如有的不需要多租戶，有的不需要削峰填谷。

• 一站到底：是指我們的所有組件，Router，Queue，ES，還有很多微服務的管控都應該在一個系統中去管控，萬萬不能一個組件一套自己的管控。

• 自動化就不說了，大家都懂。

• 右邊就是我們的一個大盤頁面，展現了 Router，ES 和 Queue 的訪問情況。當然，這是 Mock 的數據。

 

回看業務：無需運維，卻依舊不爽

 

 

至此我們已經擁有了一套低成本，高可用，少運維的 Elasticsearch 平臺了，也解決了之前談到的業務痛點，那么用戶用的是否就爽了呢？

 

我們花了大半個月的時間，對我們的業務進行了走訪調研，發現業務雖然已經從運維中解放了出來，但是身上還是有不少搜索的枷鎖。

 

我們主要分為兩類用戶，數據分析和全文檢索的：

• 數據分析主要覺得配置太復雜，它只是想導入一個日志數據，要學一堆的字段配置，而且很久才會用到一次，每次學完就忘，用到再重學，很耽誤事情。

  其次，無關邏輯重，因為數據分析類的一般都是保留多天的數據，過期的數據就可以刪除了，為了實現這一個功能，數據分析的同學要寫很多代碼，還要控制不同的別名，很是麻煩。

• 而全文檢索類的同學主要痛點有三個，一是分詞配置復雜；二是難以修改字段，Reindex 太復雜，還要自己先創建別名，再控制無縫切換；第三點是 Debug 艱難。

  雖然現在有 Explain，但是用過的同學應該都懂，想要整體梳理出具體的算分原因還是需要自己在腦中開辟很大的一塊緩存的。對于不熟悉 ES 的同學就太痛苦了。

 

整理一下，這些痛點歸類起來就兩個痛點：學習成本高和接口過于原子。

 

搜索中臺：抽象邏輯，解放業務

 

 

學習成本高和接口過于原子，雖然是業務的痛點，但是對 ES 本身而言卻反而是優點，為什么學習成本高呢？因為功能豐富。而為什么接口原子呢？為了讓上層可以靈活使用。

 

這些對于專家用戶而言，非常不錯，但是對于業務而言，的確很是麻煩。因此我們開始了我們第二個階段，搜索中臺。

 

什么叫中臺呢，就是把一些通用的業務邏輯下移，來減少業務的邏輯，讓業務專注于業務本身。

 

而為什么業務不能做這些呢？當然也能做。但是俗話說『天下武功，唯快不破』，前臺越輕，越能適應這變化極快的業務訴求。

 

因此我們的搜索中臺的主要目標就是兩點：

• 一是降低業務學習成本，加快上手速度。我們這次介紹的主要是如何降低對于配置類這種低頻操作的學習成本。

• 二是抽象復雜邏輯來加速業務迭代，我們這次主要會介紹抽象了哪兩種業務邏輯。

 

降低學習成本

 

降低學習成本，這個怎么做呢？眾所周知，黑屏變白屏，也就是白屏化。但是很多的白屏化就是把命令放在了 Web 上，回車變按鈕。這樣真的可以降低用戶學習成本么？ 我想毋庸置疑，這樣是不行的。

 

我們在可視化上嘗試了許多方案，也走了許多彎路，最后發現要想真正降低用戶學習成本，需要把握三個要點：

 

①用戶分層，區分出小白用戶和專家用戶，不要讓專家用戶的意見影響整體產品的極簡設計，對于小白用戶一定是越少越好，選擇越少，路徑越短，反饋越及時，效果越好。

 

正如所謂的沉默的大多數，很多小白用戶并不會去主動發聲，只會隨著復雜的配置而放棄使用。

 

下圖就是我們對于專家用戶和小白用戶在配置表結構時不同的頁面，對于專家用戶，基本就是 ES 所有的功能可視化，加快使用速度。對于小白用戶而言，則是完全屏蔽這些功能點，讓其可以直接使用。

 

 

②引導式配置，引導式配置其實也就是加上限制，通過對用戶的上一步輸入決定下一步的可選。

 

要避免一個頁面打開一堆配置項，這樣用戶就會無從下手，更不要談學習成本了。

 

通過引導式配置來減少用戶的選擇，降低用戶的記憶成本。限制不一定就意味著約束用戶，合適的限制更可以降低用戶的理解成本。

 

比如右圖就是我們的一個分詞器配置，很簡單的引導，用戶選擇了中文字典后才可以選擇相應的詞典。

 

③深層次結構打平，什么叫深層次結構打平，就是指像現在的分詞器，相似度這些都是在 Index 級別下的，我們將其抽象出來，變為全局的。

 

用戶可以自行創建全局的分詞器，相似度，并且還可以共享給其他人，就像一個資源一樣。然后在 Index 中則是引用這個分詞器。

 

雖然這邊做的僅僅是將分詞器從 Index 級別變為了全局，但是卻真正的減少了很多業務操作，因為在一個業務場景中，往往存在多張表，而多張表往往會使用同一套分詞器。

 

通過這種全局性的分詞器用戶僅需修改一處即可作用于所有位置。

 

抽象復雜邏輯

 

好的，說完了白屏化的一些經驗，這邊給大家分享我們對于復雜邏輯的抽象封裝的兩種新型表結構。

 

這兩種分別是數據分析類場景，我們抽象出了日志型表，另一種是全文檢索類場景，我們抽象出了別名型表。

 

日志型表的作用顧名思義就是存日志，也就是之前說的對于數據分析類業務，往往只保留幾天。

 

比如我們現在有個業務場景，有張 ES 的日志表，只想保留 3 天，于是我們就給它按天創建索引。

 

然后寫入索引掛載到今天，查詢索引掛載所有的，用 Router 去自動改寫別名，用戶還是傳入 ES，但是執行寫入操作時實際就是在 es_write 執行，查詢就是在 es_read 執行。

 

當然實際中我們并不是按天建的索引，我們會利用 Rollover 創建很多的索引來保證海量寫入下的速度。但是整體邏輯還是和這個是一樣的。

 

而對于全文檢索類場景，主要的痛點就是表結構的變更和分詞器，字典類的變更，需要重建索引。

 

所以我們抽象了一個叫別名表的表結構，用戶創建一張表 ES，實際創建的是一個 ES 的別名，我們會把它和我們真實的 Index 一一對應上。這樣利用這個別名，我們就可以自動幫用戶完成索引重建的操作。

 

而索引重建，我們有兩種方式，一是用戶配置了數據源的，我們會直接從數據源進行重建，重建完成后直接切換。

 

另外對于沒有數據源，直接 API 寫入的，目前我們是利用了 ES 的 Reindex  再配合我們消息隊列的消息回放實現的。

 

具體而言，我們就是首先提交 Reindex，同時數據開始進 Queue 轉發，然后待 Reindex 完成后，Queue 再從 Reindex 開始時進行回放，追平時切別名即可。

 

總結

 

 

總結一下這次分享的內容，我們首先構建了一個低成本，高可用，少運維的 ES 平臺將業務從運維中解脫出來，然后又進一步構建了搜索中臺，通過降低業務學習成本，下沉通用業務邏輯來加速業務迭代，賦能業務。 

 

當然，這里介紹的搜索中臺只是最基礎的中臺能力，我們還在進一步探索些復雜場景下如何抽象來降低業務成本，也就是垂直化的搜索產品。

 

作者：善仁

編輯：陶家龍、孫淑娟

出處：轉載自金融級分布式架構（ID：Antfin_SOFA）微信公眾號，本文根據他在 2018 Elastic 中國開發者大會的分享整理。

完整PPT：http://www.sofastack.tech/posts/2018-11-12-01

[[249348]]

善仁，螞蟻金服通用搜索產品負責人，通用搜索目前擁有上萬億文檔，服務了上百個業務方，是螞蟻內部最大的搜索產品。其所在的螞蟻中間件搜索團隊專注于構建簡單可信的搜索產品，是阿里經濟體中最大的搜索服務提供商。目前專注于抽象各種復雜場景下的搜索解決方案，力求讓搜索人人可用，人人會用。