微服務啟動的時候，會自動向服務註冊中心報告自己的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,則更推薦第二種,可以完美解決此問題