Elasticsearch 是一個開源的分布式 RElasticsearchTful 搜索引擎，作為一個分布式、可擴展、實時的搜索與數據分析引擎，它可以快速存儲、搜索和分析大量數據。同時，Elasticsearch 也支持具有負責搜索功能和要求的應用程序的基礎引擎， 因此可以應用在很多不同的場景中。

1Elasticsearch 在京東的使用場景

由于較高的性能和較低的使用門檻，京東內部有很多的場景都在使用 Elasticsearch。

2015 年 6 月，京東著手開發了 Elasticsearch 的托管平臺——杰思 (JElasticsearch)。杰思平臺主要負責 Elasticsearch 集群的部署、運行監控、數據遷移、權限管理、插件開發、集群升級等日常維護工作。

目前杰思平臺管理的集群覆蓋了京東多條業務線，同時也覆蓋了很多應用場景：

補充關系型數據庫的結構化數據查詢

主要應用的業務是商品、促銷、優惠券、訂單、收銀臺、物流、對賬、評論等大數據量查詢。此場景的核心訴求是高性能、穩定性和高可用性，部分場景會有檢索要求，通常用于加速關系型數據庫，業務系統通過 binlog 同步或業務雙寫完成數據同步。

全文檢索功能

主要的應用場景是應用、安全、風控、交易等操作日志，以及京東部分品類商品搜索。此類日志化場景對寫要求很高，查詢性能及高可用等要求相對較低，大的業務寫會達到數千萬 / 秒，存儲以 PB 為單位來計算。

這些場景對磁盤、內存有比較高的要求，因此，京東也做了相應優化，用于減少內存消耗，提升磁盤整體使用率，使用更廉價的磁盤來降低成本等等。

實時數據分析引擎，形成統計報表

主要應用的業務是物流單的各種分析、訂單數據分析、用戶畫像等。因為業務數據分析緯度較多，flink、storm 等流式分析對于某些報表場景不太適用，批處理實時性又成為問題，所以近實時分析的 Elasticsearch 就成為了這些業務的選擇。

Image1：Elasticsearch +ChubaoFS 支持京東商城應用場景

在應用 Elasticsearch 的 5 年時間中，京東從最初的幾個場景應用變成了覆蓋各條業務線，從最初的幾臺機器變成了現在的上千機器和幾千集群的量級，運維壓力也隨之而來了。

目前，京東在日常運維 ELasticsearch 集群時，主要面臨以下幾個問題：

• IO 讀寫不均勻，部分節點 IO 壓力非常大；

• 冷數據節點存儲量受限制于單機的最大存儲；

• close 后的索引節點故障無法進行 recovery，導致數據丟失的風險。

為了解決這些問題，京東應用了 ChubaoFS。ChubaoFS 是京東自研的、為云原生應用提供高性能、高可用、可擴展、 穩定性的分布式文件系統，設計初衷是為了京東容器集群提供持久化存儲方案，同時也可作為通用云存儲供業務方使用，幫助有狀態應用實現計算與存儲分離。

ChubaoFS 支持多種讀寫模型，支持多租戶，兼容 POSIX 語義和 S3 協議。ChubaoFS 設計的每個 pod 可以共享一個存儲卷，或者每個 pod 一個存儲卷，當容器所在的物理機宕機后，容器的數據可以隨著容器被同時調度到其他宿主機上， 保障數據可靠存儲。

Image2: Elasticsearch+ChubaoFS=Decouping Compute from Storage

2Elasticsearch 實例管理演進之路

京東的 Elasticsearch 實例管理也是一個不斷摸索、不斷爬坑的過程。

初始階段

最初，京東 Elasticsearch 集群部署是完全沒有架構可言的，集群配置也都采用默認配置，一臺物理機啟動多個 Elasticsearch 進程，進程間完全共享服務器資源，不同業務之間使用集群進行隔離，這種形式使用服務器 CPU 和內存得到了充分利用。

Image3：物理機部署

當系統運行了一段時間之后，這種部署方式的弊端開始顯現出了。

• 實例容易受到其他節點的影響，重要業務抖動問題沒有有效方式避免。

• 物理機內存被 cache 占用，新創建實例啟動時耗時特別長。

• 實例存儲受單機磁盤容量限制，數據遷移時有發生。

容器隔離階段

由于物理機直接部署 Elasticsearch，無法管理 CPU、內存，各個節點相互影響明顯，甚至會影響到穩定性。所以，針對上述情況，京東做出了改善方案——調研資源隔離方式。

當時比較主流的資源隔離方式有兩種，Docker 容器化和虛擬機。

2016 年時 Docker 容器化技術已成型，但虛擬技術比較成熟有大量工具、生態系統完善。相對于虛擬機的資源隔離，Docker 不需要實現硬件虛擬化，只是利用 cgroup 對資源進行限制，實際使用的仍然是物理機的資源，所以在資源使用率方面效率更高，我們經過測試使用 Docker 化后性能損失相對較小幾乎可以忽略。

Docker 是資源限制，啟動時不需要加載操作系統內核，可以毫秒級啟動。啟動對資源的消耗要低很多，可以做到快速的啟停。另外由于是資源限制類，只限制最大使用量而不隔離最小，這樣又可以做到虛擬化進行資源超買，提升資源使用率。

而在虛擬機的優勢方面，例如安全性，京東采用了內部資源共享平臺，通過流程管理或內部其它設施來彌補。這樣一來，原本的完全資源隔離優勢，反而成為了內部系統資源最大化利用的劣勢。

因此，京東選擇了當時相對不太成熟的容器化部署方式，并進行了服務器上 Elasticsearcht 資源隔離：

Image4 Docker 部署圖

?1. 內存完全隔離

• 數據 / 主數節點：默認按 jvm50%，預留一半給 Lucene 做 cache 使用。

• 網關 / 主節點：內存容量 -2 做為 jvm 內存，預留 2G 給監控及其它服務。

?2. CPU 隔離

• 重要業務直接綁定 CPU，完全避免資源搶占。

• 一般業務通過調整 cpu-sharElasticsearch、cpu-period、cpu-quota 進行 CPU 比例分配。

?3. IO 隔離

• 由于生產環境機器的多樣性，磁盤 IO 本身差別很大，另外對 IO 的限制會造成 Elasticsearch 讀寫性能嚴重下降，出于只針對內部業務的考慮，京東并未對 IO 進行隔離。

• 通過簡單的容器隔離，CPU 搶占現象明顯改善。內存完全隔離之后，生產環境中節點之間相互影響很少發生 (IO 差的機器會有 IO 爭用)，部署方式改造產生了應用的收益。

無狀態實例階段

隨著業務的不斷增長，集群數量及消耗的服務器資源成比例上升，京東 Elasticsearch 實例上升為上萬個，維護的集群快速增長為上千個，集群規模從幾個到幾十個不等。

但是整體資源的利用率卻相對較低，磁盤使用率僅為 28% 左右，日常平均讀寫 IO 在 10~20M/ 秒（日志分區 IO 在 60-100M / 秒）。造成資源浪費的原因是集群規模普遍較小，為保證突發情況下，讀寫請求對 IO 的要求，我們一般會為集群分配較為富余的資源，物理機分配的容器也會控制在一定量級。

我們做個假設，如果大量的服務器 IO 都可以共享，那么某個集群突發請求對 IO 的影響其實可以忽略的。基于這種假設以及對提高磁盤使用率的迫切需要，我們考慮引入了公司內部部署的 ChubaoFS 作為存儲，將 Elasticsearch 作為無狀態的實例進行存儲計算分離。

得益于 ChubaoFS 是為大規模容器集群掛載而設計的通用文件系統，我們幾乎是零成本接入的，只需在物理機上安裝相應的客戶端，就可以將 ChubaoFS 當成本地文件系統來用。集成之后我們對 ChubaoFS 的性能進行了一系列對比。

我們使用 elasticsearch benchmark 測試工具 Elasticsearchrally 分別對 Elasticsearch 使用本地磁盤和 ChubaoFS 進行 benchmark 測試，測試使用了 7 個 elasticsearch 節點，50 個 shard。

Elasticsearchrally 測試參數如下：

Elasticsearchrally --pipeline=benchmark-only \--track=pmc \ --track- params="number_of_replicas:${REPLICA_COUNT},number_of_shards:${SHARD_COUNT}" \--target-hosts=${TAR GET_HOSTS} \--report-file=${report_file}

其中 REPLICA_COUNT 0、1、2 分別 代表不同的副本數；SHARD_COUNT 為 50。

從測試結果可以看出，Elasticsearch 集成 ChubaoFS 之后，在不同副本數情況下， index benchmark 性能和本地磁盤差距在 110%~120% 左右，僅有略微的下降；merge benchmark 性能在 replica > 0 時，Elasticsearch 使用 ChubaoFS 優于本地磁盤。refrElasticsearchh 和 flush benchmark 性能 ChubaoFS 不及本地磁盤。

3目前使用效果

集成 ChubaoFS 之后，我們先是灰度運行了一段時間，效果表現良好之后，我們將京東日志所有的 Elasticsearch 集群底層全部切換為 ChubaoFS。切換之后，我們在這些方面獲得了更好的效果：

1. 節約資源

在采用 ChubaoFS 之前，我們使用了 500 臺物理機器，并且每個機器平時大概有 80% 的磁盤 IO 能力處于閑置狀態。采用 ChubaoFS 之后，ChubaoFS 的集群規模約為 50 臺，Elasticsearch 托管到公司的容器平臺，實現彈性可擴展。

2. ?管理和運維更加簡單便捷

采用 ChubaoFS 之后，我們不用再擔心某個機器的硬盤故障，或者某個機器的讀寫負載不均衡的問題。

3. GC 頻率明顯降低

由于 ChubaoFS 底層對文件作了副本支持，業務層 Elasticsearch 將副本置為 0，原先 segment 擠占堆內存導致 FullGC 現象明顯，接入 ChubaoFS 后，GC 頻率明顯降低。

4參考資料

ChubaoFS 京東開源云原生應用分布式文件系統

https://github.com/chubaofs/chubaofs

ChubaoFS 網站：

https://www.chubao.io/

ChubaoFS 設計相關論文，收錄在 ACM SIGMOD 2019

CFS: A Distributed File System for Large Scale Container Platforms.

https://dl.acm.org/citation.cfm?doid=3299869.3314046 ?

文檔

https://chubaofs.readthedocs.io/zh_CN/latElasticsearcht/

https://chubaofs.readthedocs.io/en/latElasticsearcht/

ChubaoFS 社區交流：

Twitter：@ChubaoFS

Mailing list: chubaofs-maintainers@groups.io

Slack: chubaofs.slack.com

5作者簡介

王行行，京東零售計算存儲平臺架構部架構師，杰思平臺 (京東 Elasticsearch) 團隊負責人，2015 年加入京東，目前主要負責京東商城智能監控平臺底層、杰思平臺等基礎設施建設。

張麗穎，CNCF Ambassador，京東零售計算存儲平臺產品經理， 開源項目 ChubaoFS 的 contributor。

總結

以上是生活随笔為你收集整理的Elasticsearch 实例管理在京东的使用场景及演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。