Elasticsearch 是一個開源的分佈式 RElasticsearchTful 搜索引擎，作爲一個分佈式、可擴展、實時的搜索與數據分析引擎，它可以快速存儲、搜索和分析大量數據。同時，Elasticsearch 也支持具有負責搜索功能和要求的應用程序的基礎引擎， 因此可以應用在很多不同的場景中。
1Elasticsearch 在京東的使用場景
由於較高的性能和較低的使用門檻，京東內部有很多的場景都在使用 Elasticsearch。
2015 年 6 月，京東着手開發了 Elasticsearch 的託管平臺——傑思 (JElasticsearch)。傑思平臺主要負責 Elasticsearch 集羣的部署、運行監控、數據遷移、權限管理、插件開發、集羣升級等日常維護工作。
目前傑思平臺管理的集羣覆蓋了京東多條業務線，同時也覆蓋了很多應用場景：
補充關係型數據庫的結構化數據查詢
主要應用的業務是商品、促銷、優惠券、訂單、收銀臺、物流、對賬、評論等大數據量查詢。此場景的核心訴求是高性能、穩定性和高可用性，部分場景會有檢索要求，通常用於加速關係型數據庫，業務系統通過 binlog 同步或業務雙寫完成數據同步。
全文檢索功能
主要的應用場景是應用、安全、風控、交易等操作日誌，以及京東部分品類商品搜索。此類日誌化場景對寫要求很高，查詢性能及高可用等要求相對較低，大的業務寫會達到數千萬 / 秒，存儲以 PB 爲單位來計算。
這些場景對磁盤、內存有比較高的要求，因此，京東也做了相應優化，用於減少內存消耗，提升磁盤整體使用率，使用更廉價的磁盤來降低成本等等。
實時數據分析引擎，形成統計報表
主要應用的業務是物流單的各種分析、訂單數據分析、用戶畫像等。因爲業務數據分析緯度較多，flink、storm 等流式分析對於某些報表場景不太適用，批處理實時性又成爲問題，所以近實時分析的 Elasticsearch 就成爲了這些業務的選擇。
在應用 Elasticsearch 的 5 年時間中，京東從最初的幾個場景應用變成了覆蓋各條業務線，從最初的幾臺機器變成了現在的上千機器和幾千集羣的量級，運維壓力也隨之而來了。
目前，京東在日常運維 ELasticsearch 集羣時，主要面臨以下幾個問題：
-
IO 讀寫不均勻，部分節點 IO 壓力非常大；
-
冷數據節點存儲量受限制於單機的最大存儲；
-
close 後的索引節點故障無法進行 recovery，導致數據丟失的風險。
爲了解決這些問題，京東應用了 ChubaoFS。ChubaoFS 是京東自研的、爲雲原生應用提供高性能、高可用、可擴展、 穩定性的分佈式文件系統，設計初衷是爲了京東容器集羣提供持久化存儲方案，同時也可作爲通用雲存儲供業務方使用，幫助有狀態應用實現計算與存儲分離。
ChubaoFS 支持多種讀寫模型，支持多租戶，兼容 POSIX 語義和 S3 協議。ChubaoFS 設計的每個 pod 可以共享一個存儲卷，或者每個 pod 一個存儲卷，當容器所在的物理機宕機後，容器的數據可以隨着容器被同時調度到其他宿主機上， 保障數據可靠存儲。
2Elasticsearch 實例管理演進之路
京東的 Elasticsearch 實例管理也是一個不斷摸索、不斷爬坑的過程。
初始階段
最初，京東 Elasticsearch 集羣部署是完全沒有架構可言的，集羣配置也都採用默認配置，一臺物理機啓動多個 Elasticsearch 進程，進程間完全共享服務器資源，不同業務之間使用集羣進行隔離，這種形式使用服務器 CPU 和內存得到了充分利用。
當系統運行了一段時間之後，這種部署方式的弊端開始顯現出了。
-
實例容易受到其他節點的影響，重要業務抖動問題沒有有效方式避免。
-
物理機內存被 cache 佔用，新創建實例啓動時耗時特別長。
-
實例存儲受單機磁盤容量限制，數據遷移時有發生。
容器隔離階段
由於物理機直接部署 Elasticsearch，無法管理 CPU、內存，各個節點相互影響明顯，甚至會影響到穩定性。所以，針對上述情況，京東做出了改善方案——調研資源隔離方式。
當時比較主流的資源隔離方式有兩種，Docker 容器化和虛擬機。
2016 年時 Docker 容器化技術已成型，但虛擬技術比較成熟有大量工具、生態系統完善。相對於虛擬機的資源隔離，Docker 不需要實現硬件虛擬化，只是利用 cgroup 對資源進行限制，實際使用的仍然是物理機的資源，所以在資源使用率方面效率更高，我們經過測試使用 Docker 化後性能損失相對較小几乎可以忽略。
Docker 是資源限制，啓動時不需要加載操作系統內核，可以毫秒級啓動。啓動對資源的消耗要低很多，可以做到快速的啓停。另外由於是資源限制類，只限制最大使用量而不隔離最小，這樣又可以做到虛擬化進行資源超買，提升資源使用率。
而在虛擬機的優勢方面，例如安全性，京東採用了內部資源共享平臺，通過流程管理或內部其它設施來彌補。這樣一來，原本的完全資源隔離優勢，反而成爲了內部系統資源最大化利用的劣勢。
因此，京東選擇了當時相對不太成熟的容器化部署方式，並進行了服務器上 Elasticsearcht 資源隔離：
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: [email protected]
Slack: chubaofs.slack.com
5作者簡介
王行行，京東零售計算存儲平臺架構部架構師，傑思平臺 (京東 Elasticsearch) 團隊負責人，2015 年加入京東，目前主要負責京東商城智能監控平臺底層、傑思平臺等基礎設施建設。
張麗穎，CNCF Ambassador，京東零售計算存儲平臺產品經理， 開源項目 ChubaoFS 的 contributor。