ES作用超强悍的搜索引擎，除了需要具有齐全的功能支持，超高的性能，还必须要有任意扩展的能力。一定程度上，它是一个大数据产品。而要做扩展性，集群自然少不了。然而单独的集群又是不够的，能够做的事情太少，所以它需要自己组件合适的集群。也就是服务需要自动发现，自动协调集群实例。当然，这只是扩展性的第一步。
那么，ES是如何做到集群间的自动发现的呢？本文就一起来探索探索吧。
0. 前情提要
虽然我们想探究的是es的不用配置就可以自动发现的实现原理，但是当你去看新的es的实现时，会惊奇地发现，它已经不再支持这种功能了。即新版本的es不再支持隐式集群发现了，实际上这个功能是在5.0之后取消掉了。
至于为什么会取消该功能，我想可能和可靠性有比较大的关系。当然，这个问题我们抛却不说，只管从理论上来讨论讨论这事即可。
es的2.1版本中，还有相应的集群自动发现功能，我们就以这为参考吧。事实上，在这些已经有实现的版本中，它也只是作为一个插件式存在，即后续版本不再支持，仅是没有发布该插件而已。
而核心原理，自然是多播或者广播。
1. 自动发现原理概述
其实平时我们会遇到很多自动发现服务的场景，比如RPC的调用，MQ消息的分发，docker的集群管理。。。
所以，自动发现几乎是一个平常的应用场景，那么，一般它都是是怎么解决的呢？通常，就是有一个注册中心，然后各组件启动后，将自身注册到注册中心，然后由注册中心将消息同步给到使用方，从而让使用方感知这一变化，从而完成自动发现。这几乎是一个通用的解决办法，也很容易理解。
但注册中心会引入一个额外的服务，如果不想带这额外的服务，则可能需要各节点间自行协调，或者说让各自节点都成为可能的注册中心。
注册中心，确实是充当了自动发现的角色，然而如何处理发现之后的步骤，则是各具体应用具体分析的了。所以，除了注册中心这么一个邮递员之外，还必须上下游的配合。
做自动发现的初衷，一是为了能够随时扩容，还有一定程度上的高可用。所以，通常注册中本身就不能成为单点。当然，一般的这种组件都是集群高可用的。为场景而生嘛！
还有就是本文标题所说，使用多播实现动发现。具体原理原理如何，且看下文分解。
2. es集群配置样例
es的配置还是比较简化的，绝大部分都是默认值，只做一些简单的配置即可。甚至对于单机的部署，下载下来什么都不用改，立即就可以运行了。下面我们看两个简单的集群配置样例：（elasticsearch.yml）
# 多播配置下，节点向集群发送多播请求，其他节点收到请求后会做出响应。配置参数如下： discovery.zen.ping.multicast.group:224.5.6.7 # 端口 discovery.zen.ping.multicast.port:1234 # 广播消息ttl discovery.zen.ping.multicast.ttl:3 # 绑定的地址，null表示绑定所有可用的网络接口 discovery.zen.ping.multicast.address:null # 多播自动发现禁用开关 discovery.zen.ping.multicast.enabled:true # master 节点数配置 discovery.zen.minimum_master_nodes: 2 discovery.zen.ping_timeout: 3s # 单播配置下，节点向指定的主机发送单播请求，配置如下, 使用单播时可以将多播配置禁用 discovery.zen.ping.multicast.enabled:false discovery.zen.ping.unicast.hosts: ["172.16.0.2:9300","172.16.0.3:9300","172.16.0.5:9300"]