Docker早期版本中，是不支持跨主机通信网络驱动的，也就是说明如果容器部署在不同的节点上面，只能通过暴露端口到宿主机上，再通过宿主机之间进行通信。随着docker swarm集群的推广，docker也有了自家的跨主机通信网络驱动，名叫overlay，overlay网络模型是swarm集群容器间通信的载体，将服务加入到同一个网段上的overlay网络上，服务与服务之间就能够通信。
不同主机间的容器之间通信方式，大概有三种：
使用端口映射：直接把容器的服务端口映射到主机上，主机直接通过映射出来的端口通信。
把容器放到主机所在的网段：修改 docker 的 ip 分配网段和主机一致，还要修改主机的网络结构。
第三方项目：flannel，weave 或者 pipework 等，这些方案一般都是通过 SDN 搭建 overlay 网络达到容器通信的。
docker swarm， 这是 docker 开发的容器集群管理工具，和 docker API 兼容性很好。
注意： docker overlay 网络可以单独使用，不是必须和 swarm 绑定在一起的。这里使用 swarm，是因为它的简单易用，并且更容易说明问题。
容器之间的通信
overlay网络模型在docker集群节点间的加入了一层虚拟网络，它有独立的虚拟网段，意味着docker容器发送的内容，会先发送到虚拟子网，再由虚拟子网包装为宿主机的真实网址进行发送。
这也意味着在overlay网络模型上，docker不会暴露端口给宿主机，所有有关网络的事情都交给overlay去处理了，这样的好处就是在同一台服务器，不会引起端口冲突（例如启动两个不同的容器，监听的端口相同），理解这点非常重要。
在早期使用docker进行微服务部署时，你肯定干过将docker容器所在宿主机的ip作为注册地址，因为如果你将容器内的ip作为注册地址，其他服务将不可访问你的服务，只有一条路，就是将宿主机的ip挂在容器内部处理，或者在容器内部添加ip地址环境变量来处理。
当使用docker swarm进行集群服务部署时，这个问题自然也就随之解决了，当服务已加入到overlay网络中，服务容器内会获得一个overlay网络的一个地址。
dubbo默认会拿eth0的ip作为注册地址，因此服务只需要将docker容器的ip地址作为注册地址就行了，只要服务与服务之间在同一个ovelay网段下，就可以进行通信。
提供者和消费者同时部署了2个实例，在相同overlay网段下，相互之间是可通信的。
负载均衡特性
服务的端口会交给overlay网络去处理。在Overlay网络下，即使该节点并没有部署指定服务，也会监听该服务的端口，docker通过这个特性实现了访问任意一个节点+服务对应端口，就可以访问服务，而且还具备负载均衡特性。
基于该特性，把服务的网关加入集群后，无需关心网关被分配在哪个节点上，只需要在集群再上一层nginx层配置若干个节点ip+网关服务端口，就可实现双层负载均衡，即nginx访问网关时的负载均衡，访问集群时的负载均衡。
如果此时你正在搭建docker swarm集群，我建议你把网关项目同时加入到集群中，再通过nginx做双层负载均衡。
Compose编排文件的网络选择
编排文件有个不太灵活的地方， 初次使用它来创建swarm集群的人可能会犯一些错误：
1.如果你没有指定网络，它会给你默认创建一个网络，如：stackname_default
2.假如两个stack栈分别属于不同的overlay网络，那么不同stack栈的服务是不可以进行通信的
3.如果你指定一个网络，没有写name属性的，那么它会在你指定的网络名字前面加个stackname
4.如果该网络已存在，在部署时还会报错，不会智能将该stack服务地加入该网络中
为防止overlay的网络会跟其它网络有冲突，更严谨的做法是自定义overlay网段：
# cat create_docker_gwbridge.sh
#################################################
#!/bin/bash
docker_bip: "172.17.0.1/16"
gwbridge_subnet: "172.18.0.0/16"
gwbridge_gateway: "172.18.0.1"
docker network create \
--driver=bridge \
--subnet="${gwbridge_subnet}" \
--gateway="${gwbridge_gateway}" \
--opt "com.docker.network.bridge.name"="docker_gwbridge" \
--opt "com.docker.network.bridge.enable_icc"="false" \
--opt "com.docker.network.bridge.enable_ip_masquerade"="true" \
docker_gwbridge
#################################################
在编排文件的networks上配置defualt属性，在defualt属性下面添加external属性，在其下面填写刚刚生成的网络的名称。
这么做的好处是可以灵活地将不同stack服务栈加入到相同网络下，也可避免上面提到的几个坑。
Swarm有Service的概念。
一个Service是指使用相同镜像、同时运行的多个容器，多个容器同时一起对外提供服务，多个容器之间负载均衡。每个Service会有一个浮动IP（VIP），各个容器还有自己的物理IP。
创建基于Swarm的Overlay网络，将Service挂载到此网络上。然后Service中的各个容器便可以通过Service名称（同时也是一个DNS名称）和IP地址实现网络互通。
同一个Service内，多个容器之间的负载均衡有两种方案：
云环境限制
由于docker原生的overlay网络使用的是标准的vxlan协议，使用的端口也是标准的vxlan端口（UDP 4789）。
各个云环境，如阿里云，腾讯云，也都是使用的vxlan，所以会有冲突，UDP 4789网络是被占用的。
目前也没有找到变通的办法，docker目前为止还不支持自定义vxlan端口。
参考
docker swarm 集群及多主机overlay网络测试
http://www.huilog.com/?p=1038
docker 跨主机网络：overlay 简介
https://cizixs.com/2016/06/13/docker-overlay-network
Docker Overlay网络的一些总结
https://objcoding.com/2019/02/21/docker-swarm-networks
Swarm使用原生的overlay网络
https://www.cnblogs.com/bigberg/p/8779302.html
Docker 三剑客之 Docker Swarm（基于 overlay 组网通信）
https://www.cnblogs.com/xishuai/p/docker-swarm-overlay.html
