在Elasticsearch 7前部署HA Proxy是否属于推荐的最佳实践？

一、开启es.nodes.wan.only是否会导致性能大幅下降 #

官方标注的“严重影响性能”是和原生节点发现模式的对比结果，实际业务场景下的性能损耗远没有描述的夸张，核心影响来自两个原生优化的失效：

• 原生节点发现模式下，Spark连接器可以感知ES集群所有数据节点的分片分布，读写请求会直接发送到对应分片所在的节点，完全避免ES集群内部的跨节点数据转发开销；开启es.nodes.wan.only后所有请求统一走HAProxy转发，会产生少量的跨节点转发损耗，只要HAProxy和ES集群部署在同一可用区，该延迟通常在毫秒级，普通业务基本感知不到差异。
• 原生模式下连接器可以根据ES数据节点数量动态调整并发请求数，开启后你可以主动调整es.batch.size.entries、es.http.timeout、es.thread_pool.size等参数优化并发能力，大部分场景下可以抵消90%以上的性能损失。

二、ES上层部署HAProxy是否为最佳实践 #

该方案属于云托管ES场景下的通用成熟实践，算不上追求极致性能的最优解，但对于大部分业务来说是性价比极高的选择：

方案优势 #

• 统一访问入口，无需暴露所有ES节点到业务网络，大幅降低安全风险
• 自带健康检查能力，ES节点故障时HAProxy会自动摘除故障节点，业务侧不需要处理节点发现、故障转移逻辑，运维成本更低
• 可以在HAProxy层统一做流量控制、权限校验、请求日志采集，不需要在每个ES节点单独配置

方案劣势 #

• 多一层转发会产生少量性能损耗，高并发大流量场景下HAProxy可能成为单点瓶颈，需要提前做好HAProxy集群的性能扩容

适用场景 #

• 公网访问ES的场景
• 云服务商托管ES、不开放ES节点内网地址的场景
• 对运维便捷性要求高于极致性能的普通业务场景

如果你的业务对ES读写性能有极高要求，最优方案还是将Spark集群与ES集群部署在同VPC同可用区，开放所有ES数据节点的内网访问权限，关闭es.nodes.wan.only使用原生节点发现能力，可以实现性能最大化。

内容的提问来源于stack exchange，提问作者Klun