基於 Elasticsearch 的通用搜索是螞蟻內部最大的搜索產品，目前擁有上萬億文檔，服務了上百個業務方。而通用搜索的發展主要分為兩個階段：平臺化和中臺化。
源動力：架構複雜、運維艱難
和大多數大型企業一樣，螞蟻內部也有一套自研的搜索系統，我們稱之為主搜。
但是由於這種系統可定製性高，所以一般業務接入比較複雜，週期比較長。而對於大量新興的中小業務而言，迭代速度尤為關鍵，因此難以用主搜去滿足。
主搜不能滿足，業務又實際要用，怎麼辦呢？那就只能自建了。在前幾年螞蟻內部有很多小的搜索系統，有 ES，也有 solr，甚至還有自己用 lucene 的。
業務痛點
然而業務由於自身迭代速度很快，去運維這些搜索系統成本很大。就像 ES，雖然搭建一套很是簡單，但是用在真實生產環境中還是需要很多專業知識的。作為業務部門很難去投入人力去運維維護。
並且由於螞蟻自身的業務特性，很多業務都是需要高可用保證的。而我們都知道 ES 本身的高可用目前只能跨機房部署了，先不談跨機房部署時的分配策略，光是就近訪問一點，業務都很難去完成。
因為這些原因，導致這類場景基本都沒有高可用，業務層寧願寫兩套代碼，準備一套兜底方案。覺得容災時直接降級也比高可用簡單。
架構痛點
從整體架構層面看，各個業務自行搭建搜索引擎造成了煙囪林立，各種重複建設，並且這種中小業務一般數據量都比較小，往往一個業務一套三節點集群只有幾萬條數據，造成整體資源利用率很低，而且由於搜索引擎選用的版本，部署的方式都不一致，也難以保證質量。在架構層面只能當做不存在搜索能力。
『低成本，高可用，少運維』的 Elasticsearch 平臺應運而生
基於以上痛點，我們產生了構建一套標準搜索平臺的想法，將業務從運維中解放出來，也從架構層面統一基礎設施。提供一種簡單可信的搜索服務。
架構：
如何做『低成本，高可用，少運維』呢？
我們先來一起看一下整體架構，如上圖。
1.首先說明一下我們這兩個框框代表兩個機房，我們整體就是一種多機房的架構，用來保證高可用；
2.最上層是用戶接入層，有 API，Kibana，Console 三種方式，用戶和使用 ES 原生的 API 一樣可以直接使用我們的產品；
3.中間為路由層（Router)，負責將用戶請求真實發送到對應集群中，負責一些干預處理邏輯；
4.下面每個機房中都有隊列（Queue），負責削峰填谷和容災多寫；
5.每個機房中有多個 ES 集群，用戶的數據最終落在一個真實的集群中，或者一組對等的高可用集群中；
6.右邊紅色的是 Meta，負責所有組件的一站式自動化運維和元數據管理；
7.最下面是 kubernetes， 我們所有的組件均是以容器跑在 k8s 上的，這解放了我們很多物理機運維操作，使得滾動重啟這些變得非常方便；
低成本：多租戶
看完了整體，下面就逐點介紹下我們是怎麼做的，第一個目標是低成本。
在架構層面，成本優化是個每年必談的話題。那麼降低成本是什麼意思？實際上就是提高資源利用率。提高資源利用率方法有很多，比如提高壓縮比，降低查詢開銷。但是在平臺上做簡單有效的方式則是多租戶。
今天我就主要介紹下我們的多租戶方案：
多租戶的關鍵就是租戶隔離，租戶隔離分為邏輯隔離和物理隔離。
邏輯隔離
首先介紹下我們的邏輯隔離方案，邏輯隔離就是讓業務還是和之前自己搭 ES 一樣的用法，也就是透明訪問，但是實際上訪問的只是真實集群中屬於自己的一部分數據，而看不到其他人的數據，也就是保證水平權限。而 ES 有一點很適合用來做邏輯隔離，ES 的訪問實際上都是按照 index 的。因此我們邏輯隔離的問題就轉化為如何讓用戶只能看到自己的表了。
我們是通過 console 保存用戶和表的映射關係，然後在訪問時通過 router，也就是前面介紹的路由層進行干預，使得用戶只能訪問自己的 index。具體而言，我們路由層採用 OpenResty+Lua 實現，將請求過程分為了右圖的四步，Dispatch,Filter,Router,Reprocess
在 Dispatch 階段我們將請求結構化，抽出其用戶，app，index，action 數據，
然後進入 Filter 階段，進行寫過濾和改寫，filter 又分為三步：
1.Access 進行限流和驗權這類的准入性攔截，
2.Action 對具體的操作進行攔截處理，比如說 DDL , 也就是建表, 刪表, 修改結構這些操作，我們將其轉發到 Console 進行處理，一方面方便記錄其 index 和 app 的對應信息，另一方面由於建刪表這種還是很影響集群性能的，我們通過轉發給 console 可以對用戶進行進一步限制，防止惡意行為對系統的影響。
3.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 語法非常靈活，並且有許多大代價的操作，比如上千億條數據做聚合，或者是用通配符做箇中綴查詢，寫一個複雜的>
高可用：對等多集群
講完了低成本，那麼就來到了我們第二個目標，高可用。
正如我之前提到那樣，ES 本身其實提供了跨機房部署的方案，通過打標就可以進行跨機房部署，然後通過 preference 可以保證業務就近查詢。我這裡就不再詳細說了。但是這種方案需要兩地三中心， 而我們很多對外輸出的場景出於成本考慮，並沒有三中心，只有兩地兩中心，因此雙機房如何保證高可用就是我們遇到的一個挑戰。下面我主要就給大家分享下我們基於對等多機房的高可用方案，我們提供了兩種類型，共三種方案分別適用於不同的業務場景。
我們有單寫多讀和多寫多讀兩種類型：
單寫多讀我們採用的是跨集群複製的方案，通過修改 ES，我們增加了利用 translog 將主集群數據推送給備的能力。就和 6.5 的 ccr 類似，但是我們採用的是推模式，而不是拉模式，因為我們之前做過測試，對於海量數據寫入，推比拉的性能好了不少。容災時進行主備互換，然後恢復後再補上在途數據。由上層來保證單寫，多讀和容災切換邏輯。這種方案通過 ES 本身的 t ranslog 同步，部署結構簡單，數據也很準確，類似與數據庫的備庫，比較適合對寫入 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 平臺將業務從運維中解脫出來，然後又進一步構建了搜索中臺，通過降低業務學習成本，下沉通用業務邏輯來加速業務迭代，賦能業務。 當然，這裡介紹的搜索中臺只是最基礎的中臺能力，我們還在進一步探索些複雜場景下如何抽象來降低業務成本，也就是垂直化的搜索產品。
閱讀更多 儒雅程序員 的文章
