以下文章来源于微信公众号InfoQ Pro ，作者王行行 张丽颖

Elasticsearch 是一个开源的分布式 RElasticsearchTful 搜索引擎，作为一个分布式、可扩展、实时的搜索与数据分析引擎，它可以快速存储、搜索和分析大量数据。同时，Elasticsearch 也支持具有负责搜索功能和要求的应用程序的基础引擎， 因此可以应用在很多不同的场景中。

1 Elasticsearch 在京东的使用场景

由于较高的性能和较低的使用门槛，京东内部有很多的场景都在使用 Elasticsearch。 2015 年 6 月，京东着手开发了 Elasticsearch 的托管平台——杰思 (JElasticsearch)。杰思平台主要负责 Elasticsearch 集群的部署、运行监控、数据迁移、权限管理、插件开发、集群升级等日常维护工作。

目前杰思平台管理的集群覆盖了京东多条业务线，同时也覆盖了很多应用场景：

1.1 补充关系型数据库的结构化数据查询

主要应用的业务是商品、促销、优惠券、订单、收银台、物流、对账、评论等大数据量查询。此场景的核心诉求是高性能、稳定性和高可用性，部分场景会有检索要求，通常用于加速关系型数据库，业务系统通过 binlog 同步或业务双写完成数据同步。

1.2 全文检索功能

主要的应用场景是应用、安全、风控、交易等操作日志，以及京东部分品类商品搜索。此类日志化场景对写要求很高，查询性能及高可用等要求相对较低，大的业务写会达到数千万 / 秒，存储以 PB 为单位来计算。

这些场景对磁盘、内存有比较高的要求，因此，京东也做了相应优化，用于减少内存消耗，提升磁盘整体使用率，使用更廉价的磁盘来降低成本等等。

1.3 时数据分析引擎，形成统计报表

主要应用的业务是物流单的各种分析、订单数据分析、用户画像等。因为业务数据分析纬度较多，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

2 Elasticsearch 实例管理演进之路

京东的 Elasticsearch 实例管理也是一个不断摸索、不断爬坑的过程。

2.1 初始阶段

最初，京东 Elasticsearch 集群部署是完全没有架构可言的，集群配置也都采用默认配置，一台物理机启动多个 Elasticsearch 进程，进程间完全共享服务器资源，不同业务之间使用集群进行隔离，这种形式使用服务器 CPU 和内存得到了充分利用。

Image3：物理机部署

当系统运行了一段时间之后，这种部署方式的弊端开始显现出了。

• 实例容易受到其他节点的影响，重要业务抖动问题没有有效方式避免。

• 物理机内存被 cache 占用，新创建实例启动时耗时特别长。

• 实例存储受单机磁盘容量限制，数据迁移时有发生。

2.2 容器隔离阶段

由于物理机直接部署 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 争用)，部署方式改造产生了应用的收益。

2.3 无状态实例阶段

随着业务的不断增长，集群数量及消耗的服务器资源成比例上升，京东 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=${TARGET_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。切换之后，我们在这些方面获得了更好的效果：

3.1 节约资源

在采用 ChubaoFS 之前，我们使用了 500 台物理机器，并且每个机器平时大概有 80% 的磁盘 IO 能力处于闲置状态。采用 ChubaoFS 之后，ChubaoFS 的集群规模约为 50 台，Elasticsearch 托管到公司的容器平台，实现弹性可扩展。

3.2 管理和运维更加简单便捷

采用 ChubaoFS 之后，我们不用再担心某个机器的硬盘故障，或者某个机器的读写负载不均衡的问题。

3.3 GC 频率明显降低

由于 ChubaoFS 底层对文件作了副本支持，业务层 Elasticsearch 将副本置为 0，原先 segment 挤占堆内存导致 FullGC 现象明显，接入 ChubaoFS 后，GC 频率明显降低。

4 参考资料：

• ChubaoFS 京东开源云原生应用分布式文件系统Github地址：https://github.com/chubaofs/chubaofs 欢迎点Star~

• ChubaoFS 网站：https://www.chubao.io/

• ChubaoFS 设计相关论文，收录在 ACM SIGMOD 2019 CFS: A Distributed File System for Large Scale Container Platforms. 论文链接>>

• ChubaoFS 中文文档 >> ChubaoFS Document in English >>

5 ChubaoFS 社区交流：

• Twitter: @ChubaoFSMailing

• list: chubaofs-maintainers@groups.io

• Slack: chubaofs.slack.com

6 作者简介：

1. 王行行: 京东零售计算存储平台架构部架构师，杰思平台 (京东 Elasticsearch) 团队负责人，2015 年加入京东，目前主要负责京东商城智能监控平台底层、杰思平台等基础设施建设。

2. 张丽颖: CNCF Ambassador，京东零售计算存储部产品经理， 开源项目 ChubaoFS 的 contributor。

1.基于Kafka, MySQL, Elasticsearch, Kibana,Flink构建流式应用

http://t.cn/A67GyRIX

2.如何创建易维护和可复用的Logstash管道？

http://t.cn/A67VjiCg

3.Hive 与 ElasticSearch 的数据交互

http://t.cn/A67VjiCn

• 编辑：bsll
• 归档：https://ela.st/cn-daily-all
• 订阅：https://ela.st/cn-daily-sub
• 沙龙：https://ela.st/cn-meetup

• 负责社区活动规划和设计，包括活动的主题策划、内容统筹、人员沟通、现场执行等运营工作
• 负责社区内容的搭建策划，产出针对不同阶段的运营机制和策略，构建社区氛围，包括内容编辑、发布、维护、管理、互动、提高影响力和关注度
• 负责社区产品的线上推广，制定增长策略，综合运用各类手段达成增长目标，为用户数负责
• 负责用户调研，运营数据分析，根据调研结果和运营数据持续进行产品分析及优化

• 全日制本科或以上学历，良好的英语读写能力
• 有NGINX基本知识
• 2年互联网公司工作经验，熟悉互联网社区的特性，有社区运营成功案例者优先，有B端运营经验者优先
• 具备强烈的用户思维，具有良好的沟通协作能力和内容原创、编辑能力
• 擅长使用 PhotoShop 等图片和视频制作工具
• 思维活跃，执行力强，注重细节，具有较强的表达与理解能力，积极热情。
• 有强烈的好奇心和学习能力，善于总结思考，自驱力强
• 有高校、机构学术合作经验，或者企业内部大型技术团队运营经验。