Elasticsearch 是基于 Lucene 實(shí)現(xiàn)的分布式搜索引擎，提供了海量數(shù)據(jù)實(shí)時(shí)檢索和分析能力。

Elastic 公司開源的一系列產(chǎn)品組成的 Elastic Stack，可以為日志服務(wù)、搜索引擎、系統(tǒng)監(jiān)控等提供簡單、易用的解決方案。

滴滴 Elasticsearch 簡介

滴滴 2016 年初開始構(gòu)建 Elasticsearch 平臺(tái)，如今已經(jīng)發(fā)展到超過 3500+Elasticsearch 實(shí)例，超過 5PB 的數(shù)據(jù)存儲(chǔ)，峰值寫入 TPS 超過了 2000w/s 的超大規(guī)模。

Elasticsearch 在滴滴有著非常豐富的使用場景，例如線上核心的打車地圖搜索，客服、運(yùn)營的多維度查詢，滴滴日志服務(wù)等近千個(gè)平臺(tái)用戶。

超大的規(guī)模和豐富的場景給滴滴 Elasticsearch 平臺(tái)帶來了極大的挑戰(zhàn)，我們?cè)谶@期間積累了豐富經(jīng)驗(yàn)，也取得了一些成果。本文給大家分享滴滴在 Elasticsearch 多集群架構(gòu)的實(shí)踐。

單集群架構(gòu)瓶頸

介紹單集群架構(gòu)瓶頸前，先來看下滴滴 Elasticsearch 單集群的架構(gòu)。

滴滴 Elasticsearch 單集群架構(gòu)

滴滴在單集群架構(gòu)的時(shí)候，寫入和查詢就已經(jīng)通過 Sink 服務(wù)和 Gateway 服務(wù)管控起來。

①Sink 服務(wù)

滴滴幾乎所有寫入 Elasticsearch 的數(shù)據(jù)都是經(jīng)由 Kafka 消費(fèi)入到 Elasticsearch。

Kafka 的數(shù)據(jù)包括業(yè)務(wù) log 數(shù)據(jù)、MySQL Binlog 數(shù)據(jù)和業(yè)務(wù)自主上報(bào)的數(shù)據(jù)，Sink 服務(wù)將這些數(shù)據(jù)實(shí)時(shí)消費(fèi)入到 Elasticsearch。

最初設(shè)計(jì) Sink 服務(wù)是想對(duì)寫入 Elasticsearch 集群進(jìn)行管控，保護(hù) Elasticsearch 集群，防止海量的數(shù)據(jù)寫入拖垮 Elasticsearch。

之后我們也一直沿用了 Sink 服務(wù)，并將該服務(wù)從 Elasticsearch 平臺(tái)分離出去，成立滴滴 Sink 數(shù)據(jù)投遞平臺(tái)，可以從 Kafka 或者 MQ 實(shí)時(shí)同步數(shù)據(jù)到 Elasticsearch、HDFS、Ceph 等多個(gè)存儲(chǔ)服務(wù)。

有了多集群架構(gòu)后，Elasticsearch 平臺(tái)可以消費(fèi)一份 MQ 數(shù)據(jù)寫入多個(gè) Elasticsearch 集群，做到集群級(jí)別的容災(zāi)，還能通過 MQ 回溯數(shù)據(jù)進(jìn)行故障恢復(fù)。

②Gateway 服務(wù)

所有業(yè)務(wù)的查詢都是經(jīng)過 Gateway 服務(wù)，Gateway 服務(wù)實(shí)現(xiàn)了 Elasticsearch 的 HTTP Restful 和TCP協(xié)議。

業(yè)務(wù)方可以通過 Elasticsearch 各語言版本的 SDK 直接訪問 Gateway 服務(wù)，Gateway 服務(wù)還實(shí)現(xiàn)了 SQL 接口，業(yè)務(wù)方可以直接使用 SQL 訪問 Elasticsearch 平臺(tái)。

Gateway 服務(wù)最初提供了應(yīng)用權(quán)限的管控，訪問記錄，限流、降級(jí)等基本能力，后面隨著平臺(tái)演進(jìn)，Gateway 服務(wù)還提供了索引存儲(chǔ)分離、DSL 級(jí)別的限流、多集群災(zāi)備等能力。

③Admin 服務(wù)

整個(gè) Elasticsearch 平臺(tái)由 Admin 服務(wù)統(tǒng)一管控起來。Admin 服務(wù)提供了索引的生命周期管理，索引容量自動(dòng)規(guī)劃，索引健康分，集群監(jiān)控等豐富的平臺(tái)能力，以及為 Sink、Gateway 服務(wù)提供索引、權(quán)限等元數(shù)據(jù)信息。

Elasticsearch 單集群瓶頸

隨著滴滴 Elasticsearch 平臺(tái)規(guī)模的快速發(fā)展，Elasticsearch 集群越來越大，***的時(shí)候，是由幾百臺(tái)物理機(jī)組成集群，當(dāng)時(shí)集群共 3000+ 的索引，超過了 50000 個(gè) Shard，集群總?cè)萘窟_(dá)到了 PB 級(jí)別。

超大的 Elasticsearch 集群面臨了很大的穩(wěn)定性風(fēng)險(xiǎn)，這些風(fēng)險(xiǎn)主要來自于以下三個(gè)方面：

• Elasticsearch 架構(gòu)瓶頸
• 索引資源共享風(fēng)險(xiǎn)
• 業(yè)務(wù)場景差異大

Elasticsearch 架構(gòu)瓶頸

Elasticsearch 架構(gòu)在集群變大到一定的規(guī)模會(huì)遇到瓶頸，瓶頸主要跟 Elasticsearch 任務(wù)處理模型有關(guān)。

Elasticsearch 看起來是 P2P 架構(gòu)，但實(shí)際上，仍然是中心化的分布式架構(gòu)。

整個(gè)集群只有一個(gè) Active Master。Master 負(fù)責(zé)整個(gè)集群的元數(shù)據(jù)管理。

集群的所有元數(shù)據(jù)保存在 ClusterState 對(duì)象中，主要包括全局的配置信息、索引信息和節(jié)點(diǎn)信息。只要元數(shù)據(jù)發(fā)生修改，都得由 Master 完成。

ElasticsearchMaster 的任務(wù)處理是單線程完成的，每次處理任務(wù)，涉及到 ClusterState 的改動(dòng)，都會(huì)將***的 ClusterState 對(duì)象 Publish 給集群的全部節(jié)點(diǎn)，并阻塞等待全部節(jié)點(diǎn)接受到變更消息，處理完變更任務(wù)后，才完成本次任務(wù)。

這樣的架構(gòu)模型導(dǎo)致在集群規(guī)模變大的時(shí)候出現(xiàn)很嚴(yán)重的穩(wěn)定性風(fēng)險(xiǎn)：

• 如果有節(jié)點(diǎn)假死，比如 JVM 內(nèi)存被打滿，進(jìn)程還存活著，響應(yīng) Master 任務(wù)時(shí)間會(huì)很長，影響單個(gè)任務(wù)的完成時(shí)間。
• 有大量恢復(fù)任務(wù)的時(shí)候，由于 Master 是單線程處理的，所有任務(wù)需要排隊(duì)處理，產(chǎn)生大量的 pending_tasks。恢復(fù)時(shí)間變得很長。
• Elasticsearch 的任務(wù)分了優(yōu)先級(jí)，例如 put-mapping 任務(wù)優(yōu)先級(jí)低于創(chuàng)建、恢復(fù)索引，如果一些業(yè)務(wù)上低優(yōu)先級(jí)索引在恢復(fù)，正常索引有新字段寫入時(shí)會(huì)被阻塞。
• Master 任務(wù)處理模型，在任務(wù)執(zhí)行完成后，會(huì)回調(diào)大量 Listener 處理元數(shù)據(jù)變更。

其中有些回調(diào)邏輯在索引、Shard 膨脹后，會(huì)出現(xiàn)處理緩慢的問題，當(dāng) Shard 膨脹到 5-6w 時(shí)，一些任務(wù)處理需要 8-9s 的時(shí)間，嚴(yán)重影響了集群的恢復(fù)能力。

針對(duì)這些問題，Elasticsearch 也在不斷優(yōu)化，針對(duì)相同類型的任務(wù)，比如 put-mapping 任務(wù)，Master 會(huì)一次性處理所有堆積在隊(duì)列里的相同任務(wù)。

ClusterState 對(duì)象只傳遞 diff 內(nèi)容，優(yōu)化回調(diào) Listener 模塊的處理耗時(shí)環(huán)節(jié)等等。

但是由于整個(gè)集群的任務(wù)都集中在一個(gè) Master 的一個(gè)線程中處理，在線程中需要同步元數(shù)據(jù)變更給集群的每個(gè)節(jié)點(diǎn)，并阻塞等待全部節(jié)點(diǎn)同步完成。這個(gè)模型在集群規(guī)模不斷膨脹時(shí)，穩(wěn)定性會(huì)不斷下降。

①索引資源共享風(fēng)險(xiǎn)

Elasticsearch 索引是由多個(gè) Shard 組成，Master 會(huì)動(dòng)態(tài)給這些 Shard 分配節(jié)點(diǎn)資源。不同的索引會(huì)存在資源混部的情況。

Elasticsearch 通過 Shard Allocation Awareness 的設(shè)計(jì)，可以將集群的節(jié)點(diǎn)按集合劃分成不同的 Rack。

在分配索引時(shí)可以指定 Rack 列表，這樣索引就只會(huì)分配在指定 Rack 對(duì)應(yīng)的節(jié)點(diǎn)列表中，從而做到物理資源的隔離。

但是實(shí)際使用中，很多容量小的索引由于占用資源有限，會(huì)混部在一些節(jié)點(diǎn)中。

這種情況下，會(huì)因?yàn)閭€(gè)別索引的查詢、寫入量飆升，而影響到其他索引的穩(wěn)定性。如果出現(xiàn)了節(jié)點(diǎn)故障，就會(huì)影響到整個(gè)集群的穩(wěn)定性。

整個(gè)集群 Master、Clientnode 資源是共享的，Master 風(fēng)險(xiǎn)前面已經(jīng)單獨(dú)提及，Clientnode 共享帶來的 GC、抖動(dòng)、異常問題都會(huì)影響到集群內(nèi)的全部索引。

②業(yè)務(wù)場景差異大

Elasticsearch 適用的業(yè)務(wù)場景差異特別大：

• 針對(duì)線上核心的入口搜索，一般按城市劃分索引后，索引容量不大，數(shù)據(jù)沒有實(shí)時(shí)寫入或者實(shí)時(shí)寫入 TPS 很小。
• 比如地圖 POI 數(shù)據(jù)采用離線更新的方式，外賣商家、菜品寫入量也很小。但是查詢的 QPS 很高，查詢對(duì) RT 的平均時(shí)間和抖動(dòng)情況要求很高。
• 針對(duì)日志檢索的場景，實(shí)時(shí)寫入量特別大，有些索引甚至超過了 100w/s 的 TPS，該場景對(duì)吞吐量要求很高，但對(duì)查詢 QPS 和查詢 RT 要求不高。
• 針對(duì) Binlog 數(shù)據(jù)的檢索，寫入量相比日志會(huì)小很多，但是對(duì)查詢的復(fù)雜度、QPS 和 RT 有一定的要求。
• 針對(duì)監(jiān)控、分析類的場景，聚合查詢需求會(huì)比較多，對(duì) Elasticsearch 內(nèi)存壓力較大，容易引起節(jié)點(diǎn)的抖動(dòng)和 GC。

這些場景各異，穩(wěn)定性、性能要求各不相同的場景，一個(gè) Elasticsearch 集群即使使用各種優(yōu)化手段，很難全部滿足需求，***的方式還是按業(yè)務(wù)場景劃分 Elasticsearch 集群。

多集群挑戰(zhàn)

正是單集群面臨了非常大的穩(wěn)定性風(fēng)險(xiǎn)，我們開始規(guī)劃多集群的架構(gòu)。我們?cè)谠O(shè)計(jì)多集群方案的時(shí)候，期望對(duì)業(yè)務(wù)方是零感知的。

寫入還是經(jīng)過 Kafka，Sink 服務(wù)可以將不同 Topic 的數(shù)據(jù)入到不同的 Elasticsearch 集群。

查詢繼續(xù)通過 Gateway 服務(wù)，而且業(yè)務(wù)方仍然像之前一樣傳遞索引名稱，而無需感知到平臺(tái)內(nèi)部的索引分布。所有的索引在不同集群的分布細(xì)節(jié)，均由 Gateway 服務(wù)屏蔽。

整個(gè)改造***的挑戰(zhàn)在于查詢方式的兼容。Elasticsearch 查詢索引的方式非常靈活，可以支持 * 號(hào)作為通配符匹配。

這樣一個(gè)索引 Query 可能查詢的是多個(gè)索引，比如有如下 3 個(gè)索引：

• index_a
• index_b
• index_c

使用 index* 查詢的時(shí)候，可以同時(shí)查詢到 index_a、index_b、index_c 三個(gè)索引。

Elasticsearch 這種實(shí)現(xiàn)方式非常簡單，由于一次 Query 最終查詢的是多個(gè) Shard 的數(shù)據(jù)。

所以無論對(duì)于具體的索引，還是模糊的索引，都是先根據(jù)索引名稱得到 Shard 列表，再將多個(gè) Shard 的 Query 結(jié)果 Merge 到一起返回。

這樣的使用方式，對(duì)于多集群方案就會(huì)遇到問題，比如 index_a 在 A 集群，index_b 在 B 集群、index_c 在 C 集群，對(duì)于 index* 的 Query，就無法在一個(gè)集群上完成。

Tribenode 介紹

經(jīng)過調(diào)研，我們發(fā)現(xiàn) Elasticsearch Tribenode 特性可以很好的滿足多集群查詢的特性。

Tribenode 的實(shí)現(xiàn)非常巧妙。org.elasticsearch.tribe 包下只有三個(gè)文件，核心類是 TribeService。

Tribenode 的核心原理就是 Merge 每個(gè)集群的 ClusterState 對(duì)象成一個(gè)公共的 ClusterState 對(duì)象，ClusterState 包含了索引、Shard 和節(jié)點(diǎn)數(shù)據(jù)分布表。

而 Elasticsearch 的工作邏輯都是基于 ClusterState 元數(shù)據(jù)驅(qū)動(dòng)的，所以對(duì)外看起來就是一個(gè)包含全部索引的 Clientnode。

Tribenode 通過配置多個(gè) Elasticsearch 集群地址，然后以 Clientnode 角色分別連接每個(gè)集群，每個(gè)集群看起來會(huì)多了一個(gè) Clientnode。

Tribenode 通過該 Clientnode 角色獲取到集群的 ClusterState 信息，并綁定 Listener 監(jiān)聽 ClusterState 變化。

Tribenode 將獲取的所有集群的 ClusterState 信息 Merge 到一起，形成一個(gè)對(duì)外部訪問使用的 ClusterState 對(duì)象，對(duì)外提供服務(wù)。

Tribenode 除了注冊(cè) Listener 和 Merge ClusterState，其他的所有邏輯都是復(fù)用了 Clientnode 的代碼。

可以看到 Tribenode 的優(yōu)點(diǎn)：

• 能夠滿足多集群訪問的需求，對(duì)外使用是透明的。
• 實(shí)現(xiàn)的簡單、優(yōu)雅，可靠性有保證。

同時(shí) Tribenode 有些不足的地方：

• Tribenode 必須以 Clientnode 加入到每個(gè) Elasticsearch 集群，Master 的變更任務(wù)必須等待 Tribenode 的回應(yīng)才能繼續(xù)，可能影響到原集群的穩(wěn)定性。
• Tribenode 不會(huì)持久化 ClusterState 對(duì)象，重啟時(shí)需要從每個(gè) Elasticsearch 集群獲取元數(shù)據(jù)。

而在獲取元數(shù)據(jù)期間，Tribenode 就已經(jīng)能夠提供訪問，會(huì)導(dǎo)致查詢到還在初始化中的集群索引訪問失敗。

• Tribenode 連接的集群多了，初始化會(huì)變得很慢。針對(duì)該缺陷，我們平臺(tái)在重啟某個(gè) Tribenode 集群時(shí)，將 Gateway 訪問該集群的全部流量切到備份 Tribenode 集群解決。
• 如果多個(gè)集群有相同的索引名稱，Tribenode 只能設(shè)置一種 Perfer 規(guī)則：隨機(jī)、丟棄、Prefer 指定集群。這可能帶來查到不符合預(yù)期的異常。
• 滴滴 Elasticsearch 平臺(tái)通過統(tǒng)一管控索引，避免了同一個(gè)索引名稱出現(xiàn)在 Tribenode 連接的多個(gè)集群中。

正是 Tribenode 有了這些瑕疵，Elasticsearch 在高版本引入了 Cross ClusterSearch 的設(shè)計(jì)，Cross Cluster 不會(huì)以節(jié)點(diǎn)的形式連接到其他集群，只是將請(qǐng)求代理。

目前我們還在評(píng)估 Cross Cluster 的方案，這里不展開介紹。

多集群架構(gòu)拓?fù)?/span>

最終改造后，我們的集群架構(gòu)拓?fù)淙缦拢?/p>

按照不同的應(yīng)用場景，平臺(tái)將 Elasticsearch 集群劃分成四種類型：Log 集群、Binlog 集群、文檔數(shù)據(jù)集群、獨(dú)立集群。公共集群一般最多 100 臺(tái) Datanode 為基準(zhǔn)組成一個(gè)集群。

我們利用滴滴云實(shí)現(xiàn)了集群的自動(dòng)化部署和彈性擴(kuò)縮容，可以很方便的水平擴(kuò)展集群。

Elasticsearch 集群前面是多組 Tribenode 集群，主要是為了解決 Tribenode 的穩(wěn)定性問題。

Gateway 會(huì)同時(shí)連接 Tribenode 集群和 Elasticsearch 集群，根據(jù)應(yīng)用訪問的索引列表，配置應(yīng)用訪問的集群名稱。

Gateway 根據(jù)集群名稱，將請(qǐng)求代理到指定集群訪問，如果訪問的是 Tribenode 集群，則該應(yīng)用可以訪問到多個(gè)集群的索引。

Admin 服務(wù)則管控了所有的 Elasticsearch 集群，以及索引和集群的對(duì)應(yīng)關(guān)系。一系列功能都針對(duì)多集群做了改造。

Sink 服務(wù)已經(jīng)從 Elasticsearch 平臺(tái)分離出去，成立 DSink 數(shù)據(jù)投遞平臺(tái)。

DSink Manager 負(fù)責(zé)管理 DSink 節(jié)點(diǎn)，DSink Manager 從 Elasticsearch Admin 服務(wù)獲取索引的元數(shù)據(jù)信息，下發(fā)給對(duì)應(yīng)的 DSink 節(jié)點(diǎn)。

多集群架構(gòu)實(shí)踐總結(jié)

多集群架構(gòu)收益

Elasticsearch 多集群架構(gòu)改造給 Elasticsearch 平臺(tái)帶來了如下收益：

• Elasticsearch 平臺(tái)的隔離性可以從物理節(jié)點(diǎn)級(jí)別上升到 Elasticsearch 集群級(jí)別。對(duì)于核心的線上應(yīng)用，可以使用獨(dú)立的 Elasticsearch 集群支持。
• 不同類型的數(shù)據(jù)按集群劃分，避免相互影響，減小了故障的影響面，對(duì)平臺(tái)穩(wěn)定性帶來極大的提升。
• Elasticsearch 平臺(tái)的擴(kuò)展能力進(jìn)一步提升，通過新增集群可以很好的做到水平擴(kuò)展。
• 多集群架構(gòu)最終做到了對(duì)業(yè)務(wù)方無感知，業(yè)務(wù)看起來，Elasticsearch 平臺(tái)就像一個(gè)***大的 Elasticsearch 集群，而無需感知索引真實(shí)的集群分布。

多集群架構(gòu)實(shí)踐經(jīng)驗(yàn)

滴滴 Elasticsearch 平臺(tái)多集群的架構(gòu)已經(jīng)演進(jìn)了一年半時(shí)間，這期間也遇到一些多集群架構(gòu)帶來的挑戰(zhàn)。

①Tribenode 穩(wěn)定性挑戰(zhàn)

隨著集群數(shù)量越來越多，前面提到的 Tribenode 不足越來越明顯，比如初始化的時(shí)間越來越長等等。

我們采取的應(yīng)對(duì)策略是部署多組 Tribenode 集群，有幾組連接全量的集群，互為災(zāi)備，有幾組只連接核心的一些集群，用作更為重要的跨集群訪問場景。

Tribenode 的 ClusterState 元數(shù)據(jù)包含了太多的索引和 Shard，Elasticsearch 的 Search 邏輯在有些 Case 處理下容易出現(xiàn)耗時(shí)過長的情況。

Elasticsearch 在 Client 接收到 Search 請(qǐng)求時(shí)，是在 Netty 的 IO 線程中完成請(qǐng)求轉(zhuǎn)發(fā)給每個(gè) Shard 的，低版本的 Elasticsearch 還沒有限制一次 Query 的 Shard 數(shù)量。

在一些復(fù)雜的模糊索引匹配 Shard 的邏輯中，以及給每個(gè) Shard 發(fā)送 Query 請(qǐng)求時(shí)，會(huì)出現(xiàn)較高的耗時(shí)，可能有超過 1-2s 的 Case，這會(huì)影響到該 Netty Worker 上的其他的請(qǐng)求，造成部分響應(yīng)飆高的情況。

我們優(yōu)化了 Tribenode Search 流程中一些索引、Shard 膨脹之后的耗時(shí)邏輯，解決了該問題。

②多集群配置、版本統(tǒng)一的挑戰(zhàn)

在只有一個(gè)集群的時(shí)候，平臺(tái)只用維護(hù)一份集群的配置和版本。當(dāng)集群數(shù)量增多后，不同集群間的 _cluster settings 信息會(huì)出現(xiàn)部分差異。

這些差異，可能會(huì)導(dǎo)致集群間的負(fù)載不均，恢復(fù)速度過快或者過慢等問題，每個(gè)集群還有一份基礎(chǔ)的索引模板配置，這里面也出現(xiàn)了部分差異。

這個(gè)問題目前我們還在解決中，我們計(jì)劃將 Admin 服務(wù)分離成索引管理服務(wù)和集群管理服務(wù)，集群管理會(huì)專注于集群版本、配置、部署、擴(kuò)容、監(jiān)控等方面對(duì) Elasticsearch 集群進(jìn)行更全面的管控。

我們做的一些 Elasticsearch 源碼優(yōu)化，會(huì)先后在部分集群上線，這樣導(dǎo)致了集群間的版本混亂的問題。

我們的解決方案是在 Elasticsearch 和 Lucene 內(nèi)增加內(nèi)部的版本號(hào)，通過公司內(nèi)部的發(fā)布系統(tǒng)，發(fā)布 Elasticsearch 的更新，后續(xù)集群管理服務(wù)會(huì)將集群的版本管理起來。

③多集群間容量均衡的挑戰(zhàn)

我們主要從跨集群索引遷移和容量規(guī)劃解決集群間容量均衡的挑戰(zhàn)，在單 Elasticsearch 集群的時(shí)候，數(shù)據(jù)遷移可以依賴 Elasticsearch 的 Rebalance 能力完成。

在使用多集群架構(gòu)后，平臺(tái)內(nèi)部的 Elasticsearch 集群會(huì)出現(xiàn)資源分配不均的問題。

例如有些索引容量增長的很快，導(dǎo)致所在集群的資源緊張，有些索引數(shù)據(jù)減少，不需要占用太多資源，導(dǎo)致集群資源空閑。

于是產(chǎn)生了索引跨集群遷移的需求。針對(duì)這個(gè)需求，我們通過給索引添加版本號(hào)，解決了索引跨集群遷移問題。之后我們有文章會(huì)詳細(xì)的介紹該方案。

滴滴 Elasticsearch 平臺(tái)實(shí)現(xiàn)了索引容量的自動(dòng)規(guī)劃，解決了集群間的容量均衡。

Elasticsearch 平臺(tái)可以動(dòng)態(tài)的規(guī)劃索引的容量。當(dāng)一個(gè)集群容量規(guī)劃不足時(shí)，平臺(tái)可以動(dòng)態(tài)的遷移一部分索引到空閑的集群中。

新的索引接入需求會(huì)優(yōu)先接入在空閑的集群資源中。滴滴 Elasticsearch 平臺(tái)是如何實(shí)現(xiàn)索引容量的自動(dòng)規(guī)劃，也請(qǐng)期待后續(xù)的分享。

總結(jié)

滴滴的多集群架構(gòu)，最初是為了解決 Elasticsearch 單集群架構(gòu)的瓶頸。為了支持多集群架構(gòu)，后面的很多組件都需要考慮連接多個(gè)集群的場景，給平臺(tái)架構(gòu)帶來了一定的復(fù)雜性。

但是多 Elasticsearch 集群帶來的穩(wěn)定性和隔離性的提升，它所帶來的收益遠(yuǎn)遠(yuǎn)大于架構(gòu)的復(fù)雜性。

改造成多集群架構(gòu)后，我們扛住了 Elasticsearch 平臺(tái)規(guī)模爆炸式增長，Elasticsearch 平臺(tái)的規(guī)模翻了 5 倍多，多集群架構(gòu)很好的支撐了業(yè)務(wù)的快速發(fā)展。