微服务启动的时候，会自动向服务注册中心报告自己的ip和端口。但是服务是在docker容器内运行的，注册的ip就成了172开头的docker内部ip, 这个地址是无法被其它机器访问的。
这种情况是不是必须手动将服务注册的地址改成宿主机的地址和端口呢，有其它好方案没
----- update -----docker 1.12版本以后engine有了swarm模式，经测试使用swarm的overlay网络可解决跨主机通讯问题，这种方案是否合适呢
docker swarm 提供的overlay network可以提供跨主机的容器内网络通讯，本机内容器可以在启动时指定network来组成内部网络，然后可以在swarm主机上用host模式部署nginx，使用etcd，consul等动态注册服务和更新nginx的反向代理配置来达到动态服务发现的目的。不过overlay目前是所有跨主机通讯方式中性能损耗最大的，达到60%。网上有人做过测试，你可以找来看看。因此就目前来说，生产环境还是要考虑kubernetes或者mesos
对网络方面不是很懂，请google docker跨主机通信能搜到一些方案。
用host加内部dns
有几个思路：1、在启动服务的时候由宿主设备报告 ip2、启动服务的时候向容器环境变量中注入宿主 ip 信息3、注册中心收到注册请求时，从网络层拿 ip
因为容器是动态的，通常情况下IP地址随机分配的。当使用容器调度系统自动启动一些容器后，可以通过服务注册把这些容器的访问地址记录到服务注册中心。这样当外部服务想要访问这些容器时，就可以通过服务发现(service discovery)访问这些容器
非常简单啊，各种跨主机docker网络通信方案。
kubernetes就在用flannel。
可以考虑其他方式1.使用kubernetes等服务编排工具(对docker方面有较大改变)2.使用consul等注册中心(对注册中心代码方面有较大改变)
如果微服务使用的是spring cloud,则更推荐第二种,可以完美解决此问题
docker swarm 提供的overlay network可以提供跨主机的容器内网络通讯，本机内容器可以在启动时指定network来组成内部网络，然后可以在swarm主机上用host模式部署nginx，使用etcd，consul等动态注册服务和更新nginx的反向代理配置来达到动态服务发现的目的。
不过overlay目前是所有跨主机通讯方式中性能损耗最大的，达到60%。网上有人做过测试，你可以找来看看。因此就目前来说，生产环境还是要考虑kubernetes或者mesos
对网络方面不是很懂，请google docker跨主机通信能搜到一些方案。
用host加内部dns
有几个思路：
1、在启动服务的时候由宿主设备报告 ip
2、启动服务的时候向容器环境变量中注入宿主 ip 信息
3、注册中心收到注册请求时，从网络层拿 ip
因为容器是动态的，通常情况下IP地址随机分配的。当使用容器调度系统自动启动一些容器后，可以通过服务注册把这些容器的访问地址记录到服务注册中心。这样当外部服务想要访问这些容器时，就可以通过服务发现(service discovery)访问这些容器
非常简单啊，各种跨主机docker网络通信方案。
kubernetes就在用flannel。
可以考虑其他方式
1.使用kubernetes等服务编排工具(对docker方面有较大改变)
2.使用consul等注册中心(对注册中心代码方面有较大改变)
如果微服务使用的是spring cloud,则更推荐第二种,可以完美解决此问题