旧版（独立的）Swarm需要一个服务注册中心，以便其所有manager可以拥有相同的集群状态视图。在实例化旧的Swarm节点时，我们必须指定服务注册中心的地址。但是，如果你看一下新版Swarm（Docker 1.12中引入的Swarm模式）安装命令的说明，就会注意到里面没有设置Docker Engine之外的任何东西。你不会发现任何提及的外部服务注册中心或键值存储。
这是否意味着Swarm不需要服务发现？ 恰恰相反。服务发现的需求与以往一样强烈，以至于Docker决定将其纳入Docker Engine内部。它和Swarm一样被捆绑在Docker中。服务发现的内部过程在本质上仍然与独立的Swarm所使用的过程非常相似，只是有更少的可移动部件。Docker Engine现在充当Swarm manager、Swarm worker和服务注册中心的角色。
将所有东西都打包在引擎内部的决定引发了不同的反响。有人认为这个决定会导致太多的耦合，并增加Docker Engine的不稳定性。其他人则认为这种捆绑使得引擎更加健壮，并为一些新的可能性打开了大门。虽然双方的论点都能站得住脚，但我更倾向于后者的意见。Docker Swarm模式是一大进步，如果不在引擎中捆绑服务注册中心，能否实现相同的效果就不好说了。(www.xing528.com)
了解了Docker Swarm，尤其是networking的工作方式之后，你可能会想到的问题是我们是否还需要服务发现（除Swarms内部使用外）。在《微服务运维实战（第一卷）》中，我认为服务发现是必须的，并且要求每个人都将Consul（https：//www.consul.io/）或etcd（https：//github．com/coreos/etcd）设置为服务注册中心，Registrator作为在集群内注册更改的机制，以及使用Consul模板或confd（https：//github．com/kelseyhightower/confd）作为模板解决方案。现在我们还需要这些工具吗？
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
