总是有一些事儿触动你去思考，无论你愿意或者不愿意。总有一些事儿让你感触良多，有一些事总是拖延着不愿提上日程，然后突然发生，不得不提上日程。

    选择摆在眼前的时候，是无视还是一种心理煎熬？

    容器的原生网络提供了三种，一种是host模式，一种bridge模式，一种则是none模式，至于第三种模式未使用过，在此掠过不谈，没有具体的使用场景。

    在构建容器集群的时候，有几种选择，一种是直接在物理机上运行docker集群，一种则是在虚拟机上运行docker集群。

    在选择不同的网络的时候，如果选用bridge模式，需要考虑到底层网络的连通性，从而要么使用自定义的桥接网络，要么使用其他的各种网络，主要的目的是为了跨主机网络的构建，但是当使用虚拟机构建集群的时候，可以直接使用host模式，无需考虑底层的网络，从而降低了构建网络的复杂性。

    当直接在物理机上运行的时候，一般使用自定义网络，在进行和外部通信的时候，可以使用一个前端的负载均衡设备，例如nginx来进行提供相关的服务，在一种特殊的情况下，需要使用host网络。

    host网络和bridge网络的本质区别在哪儿？

    使用host网络的时候，主要是为了提供更大的网络IO，从而选择，在这个时候，容器和宿主机共用同一个网络栈，缺点就是可能同一台物理机上的容器可能出现网络IO争抢，发生的概率很小，毕竟现在的云环境其实也是一样的，底层是一个资源池，上层从里面取相关的资源，还有一个缺点就是容器的暴露的端口是直接暴露在宿主机上的，从而如果宿主机上存在很多host模式的容器，那么就要考虑端口冲突的可能。

    host模式的优点就是对于产生大量io容器使用，例如当容器提供监控的时候，需要从很多的主机里面拉取日志，那么这个时候就可以使用host模式。

    桥接网络，在进行练习的时候，一般都是使用默认的桥接网络，当需要暴露端口的时候，直接使用-p参数暴露端口，bridge的缺点就是需要进行一个NAT转换，然后将服务提供出去；当client端访问容器服务的时候，是通过docker-proxy访问，从而也多了一个链路，性能没有host模式的好，在生产中，一般使用自定义的桥接网络，从而可以设定容器的ip等信息，而且如果是微服务架构，内部的服务交互都连接同一个brige虚拟网络设备之中，从而可以内部使用。

    从而，对于直接在宿主机上运行容器来说，可以使用两种模式的结合，一种使用host模式，从而提供更好的网络IO性能，对于内部服务来说，使用自定义的桥接网络。

    当在虚拟机中构建容器集群的时候，可以直接使用host模式，从而将容器进行分散调度，提供了很好的性能，并且不用考虑底层网络，这是一种最简单的方式，简单实用。

    当容器太多的时候，可以直接使用如下命令来统计在不同网络的容器个数：

    查看容器使用的网络模型：

   在不同的选择中，有不同的侧重点，对于产品的构造来说，不需要炫耀技术，采用最复杂的技术，采用最先进的技术，其实都没有必要，稳定压倒一切，而且最重要的是市场的反馈，早日推出产品，才能获取更多的实践性的技能。

    对于很多技术，可能你花费了无数的时间，最后只是充当了炮灰，可能复杂的技术也是一个陷阱，傻傻惹人爱。

    又到了夏天了，又到了同归于尽的季节。。。蚊子没吃饱，我没。。。睡好。