共计 2364 个字符，预计需要花费 6 分钟才能阅读完成。
运维大规模 ES 集群的思考和实际
Elasticsearch 是 一个分布式、RESTful 格调的搜寻和数据分析引擎。 在开源搜寻畛域曾经遥遥领先其余产品。随着近年来 ES 的疾速倒退，ES 曾经逐渐从繁多搜索引擎进化成一个全能型的数据产品。在日志监控，全文检索，数据库减速，大数据分析等很多畛域失去广泛应用。
▲数据库引擎排名，数据起源：https://db-engines.com/en/ran…▲
京东智联云 ES 撑持了私有云，公有云和京东团体外部的大量 ES 集群。京东商城，京东物流，京东金融等各个业务畛域都对 ES 服务有很大量的需要。目前已应用数十万核，上万个节点，数十万亿个文档。
如何利用云厂商的劣势，高效，牢靠，稳固的运维如此大规模的 ES 集群是咱们须要思考和解决的问题。上面我将从几个维度介绍咱们的思考和实际。
一、基础设施和服务编排
云厂商相较于用户自建最大的劣势在于弹性。弹性给用户带来的不仅仅是不便易用，还有降低成本。京东智联云 ES 依靠于云舰的服务编排能力，可能达到疾速，灵便的部署集群，反对对集群程度扩缩，垂直变配，存储扩容等弹性能力。另外京东智联云 ES 还提供了 云硬盘 、 本地盘 、 对象存储 多种存储形式，满足不同场景下的用户需要。
另外服务编排还提供了 故障自愈能力。物理机故障场景，会主动将故障机器上的 es 节点 failover 到其余节点；es 节点故障场景，会主动尝试重启 es 节点如果依然无奈复原则会迁徙 es 节点到其余物理机节点。
二、运维
▲京东智联云 ES 运维能力▲
1，监控正告
如此大规模的集群，须要全局和指标丰盛的运维监控零碎，来保障系统运维的可视化。通过咱们的运维教训积攒，京东智联云的运维监控零碎，曾经可能实时的发现异常集群，并可能通过各个监控指标剖析发现问题的起因。
2，多版本反对
ES 版本特地多，因为历史起因很多旧零碎很难降级，且不同用户上云对版本需要差别较大，所以须要反对很多不同的版本。目前反对的大版本有 2.x，5.x，6.x，7.x。多版本的治理复用同一套编排管理系统，可能疾速反对新 es 版本上线。
3，性能优化
ES 的特点是开箱即用，但 ES 可配置项十分多，对于不同的业务场景和需要，集群须要不同的调优配置，非专业用户往往很难应用的十分正当。上面列举一些常见问题：
4，数据迁徙
5，索引生命周期治理
索引生命周期治理是用户很罕用的一个治理性能。按天或月周期创立索引，保留肯定工夫后删除过期索引，永恒保留指定工夫的索引（例如大促期间的索引）。ES 从 6.6 版本在 x -pack 中开始反对索引生命周期治理性能的测试版本，但低版本不反对该性能。京东智联云 ES 将该性能拓展到所有 ES 版本并提供 UI 化设置，比通过原生 kibana 配置或者 API 配置更加简略实用。
6，摸索智能化运维
摸索智能化运维，咱们的运维常识和教训产品化提供给用户，依据用户的业务场景，综合各项监控指标，给出集群的健康状况和解决倡议。例如节点负载不均，分片设置不合理，堆内存占用太高，GC 工夫太长，filedata 占比太高，集群负载较高，分片数量太大，写入或者查问线程池队列有沉积或者 reject，集群的读写流量异样稳定等。
7，监控指标数据自治零碎
自动化运维或者自治运维是终极目标，随着智能化运维能力的进步，通过监控指标数据自治零碎就可能自主得出决策并执行，齐全不须要人工染指。
三、利用场景优化
ES 的利用场景次要波及日志检索，数据库减速，监控指标，数据分析等畛域。不同的业务场景具备不同的特点，对性能的需要也不尽相同，所以须要针对不同场景有不同的优化计划。
1. 日志检索场景， 并发写入量大，实时性要求不高，存储量大，数据有冷热属性。针对这种场景能够进步索引写入缓存大小来晋升写入性能；减少 refresh interval 工夫距离来缩小 segment 数量；将 translog.durability 应用 HDD 来升高存储老本。
2. 数据库减速场景， 对于没有事务性要求，且须要检索海量数据的结构化查问场景，ES 是代替关系型数据库的不错抉择。京东次要利用的业务有商品，优惠券，订单，对账，物流等。此场景的特点是提早敏感，须要高性能，高可用。
3. 监控指标， 并发写入量大，时序个性，不须要高可用，数据有冷热属性。
4. 数据分析场景， 数据分析维度较多，聚合查问。写入量大，查问量小，但须要聚合查问。京东次要利用的业务有订单交易剖析，用户画像等。
四、服务化
业余的人做业余的事，托管 ES 产品 第一步解决了用户本人搭建集群 ， 治理集群的效率和老本问题，但用户依然须要理解 ES 的原理常识，调优常识，索引配置，集群配置，分片设置等等和业务无间接关系的常识，应用好 ES 依然须要很高的门槛。所以托管 ES 产品的 第二步就是服务化， 用户只须要提出业务的需要，不必再关怀服务前面 ES 集群的参数。例如用户从本身的业务场景动手，提供写入查问性能指标的冀望，另外用户只须要定义索引的 mapping，不须要关怀索引的 settings，分片数量等配置信息。从集群的规格配置到索引的正当设置都由后盾主动设置和优化。
五、将来思考
给用户提供简略牢靠的产品是咱们的终极目标。所以将来咱们会从两个方面晋升优化咱们的产品，一是从用户的角度对外出现产品状态，通过产品服务化更贴近用户的应用习惯，升高用户应用门槛，提供更加简略且实用的应用形式。二是从运维的角度加强后盾的自治运维能力，包含智能检测和修复能力，故障自愈能力，主动弹性能力，数据配置托管能力等，做到从托管产品变成托管服务。
举荐浏览：
- 冲破容量极限：TiDB 的海量数据“无感扩容”秘籍
- ClickHouse 最佳实战之散布表写入流程剖析
- 比 MySQL 快 839 倍！揭开剖析型数据库 JCHDB 的神秘面纱
欢送点击【京东智联云】，理解开发者社区
更多精彩技术实际与独家干货解析
欢送关注【京东智联云开发者】公众号
