去NAT的Bridge网络模式：用管理灵活性换取网络极致性能

Docker默认的桥接网络模型走的是NAT（网络地址转换）路径：容器的veth网卡绑定到宿主机自己的网桥Docker0，宿主机再用iptables配置地址转换、用DHCP服务（如dnsmasq）分配IP——这种方式的好处是配置简单、开箱即用，但NAT转换本身会带来额外的网络处理开销。雪球做了一个更激进的调整：把Bridge模式的NAT去掉，直接把宿主机的IP从物理网卡上移除、改配置到网桥上，并使用静态IP分配策略，让容器的IP可以直接暴露到交换机上，不再需要经过NAT转换这一层，从而拿到接近物理网络的转发性能——这也是为什么团队没有选择端口映射方案，因为端口映射天然不利于做服务发现，和这个追求高性能、易发现的目标相悖。但这个”去NAT”的极致性能方案不是没有代价的：为了避免网络流量出现毛刺风暴问题，宿主机上必须禁用iptables和ip_forward，以及禁用相关内核模块——这意味着放弃了iptables原本提供的很多灵活的网络管理和安全过滤能力，网段规划和IP静态分配也需要投入额外的运维精力去管理，不能再依赖DHCP自动分配这种省心的方式。这个案例体现了一条网络架构设计里常见的取舍：默认的、开箱即用的网络方案（NAT bridge）通常在性能和灵活运维之间选择了偏向后者的平衡点，而如果业务对网络性能有极致要求，往往需要主动放弃一部分默认方案提供的管理便利性（iptables灵活过滤、DHCP自动分配）去换取性能，这类取舍没有绝对正确答案，只能结合自己的业务对性能和运维复杂度的真实容忍度去判断。