大部分的国外企业和公有云都是采用的非FNAT的方式，比较少用DR，大部分都是DNAT和SNAT的方案。

网络入口的位置做DNAT的大好处是客户端可以拿到CIP（Client IP），而做DNAT的过程同时就是一个负载均衡的过程。因为DNAT的目的就是为了选择一个RS，当然可以只配置一个RS，这样做就是相当于一个外网IP的入口处的绑定。但是更多的情况是用在企业的负载均衡的核心入口的位置，DNAT收敛外网IP，并且选择一个内部RS的内网IP。

但是这个架构就带来另外一个问题，就是出去的时候，由于目标地址已经被改变了，所以就需要再做SNAT。在哪里做SNAT这个事情是一个非常严肃的问题。因为DNAT集群是只管进入的流量的，而SNAT是只管出去的流量的，一个很容易想到的方案是DNAT和SNAT采用单独的分开的集群。这样两个集群同时管理两份流表。并且CIP发起的连接，由于DNAT选择了RS，在回复的时候如何把RS的RIP转变为DNAT入口的VIP就是一个需要解决的问题。

如果交给单独的集群解决，就需要和DNAT集群同步VIP和RS的映射关系。这个同步并不难，所以这也是一种不错的方案。事实上，这种方案被大量的采用。刚说的是CIP主动发起连接的情况，但是如果是RIP主动发起连接的情况，首先执行的就是SNAT，但是从DNAT进来的时候就不知道该选择哪个RIP。因为SNAT之后，对客户端发送数据使用的是VIP，而客户端回复的也是VIP，在DNAT集群那里就看不到VIP和RS的对应关系，就不知道该如何的选择。

微软AZURE的方案使用DNAT集群作为入口，但是流量出去的时候是在本机做SNAT，并没有使用单独的SNAT集群。虽然可以很方便的解决CIP主动发起连接的情况，但是对于RIP主动发起连接的情况，仍然会面临同样的返回如何选择RS的问题。但是，微软做了同步，也就是在本地做SNAT决策的时候，会选择一个VIP和一个端口，这个VIP:VPORT，RIP,RPORT和CIP:CPORT的对应信息会被同步到DNAT的入口集群，以此完成一个DNAT集群对于SNAT出扣感知的操作。显然这个操作是非常的损耗性能的，但是考虑到SNAT的数据量不会太大，大部分的主机都是用作服务器从外部接受连接，所以同步的方案也是可以接受的。

事实上，单独的SNAT集群也许要同步同样的信息。

这样的方案还有一个大的问题是，DNAT和SNAT双方被割裂。安全上比较难做。需要两边配合的事情比较难做，但是实际上，这种需求也不大，所以很多企业就是直接用的DNAT集群。

比DNAT集群在管理上方便的是Tunnel集群，从入口到RIP的数据包是打Tunnel的，相当于在入口处创建了一个Overlay的网络。Overlay网络的意思是在物理网络上组建一个虚拟的网络，虚拟网络依托于物理网络，但是又有自己的路由能力。Tunnel作为网络的入口的特点是非常简单，在RS的主机上可以拿到完整的CIP和VIP的信息，所以RS服务器的流量出去的时候，也是直接填写了CIP，使用自己的VIP信息，不需要经过SNAT节点，因为Tunnel操作需要在RS的主机上配置一个管道，管道里面就是一模一样的CIP发送而来的数据包，所以Tunnel方案是不需要做SNAT的。Tunnel的缺点也很明显，需要在每个主机上配置一个Tunnel设备，这在很多服务器环境是比较难推动的。而且，Tunnel由于添加了IP头部，所以MTU必定要对应的减小，也就是CIP发送来的数据就不能采用大的MTU。相当于总体浪费了大于10%的吞吐能力。

Tunnel模型如果主动对外发起连接，就是完全不经过入口的，即使是回复也不能经过入口，因为它面临的问题与DNAT一样。入口负载均衡设备不知道该如何选择RS。Tunnel模式在配置上的特殊性在于每个RS需要配置一个拥有VIP的网卡设备和一个拥有内网IP的Tunnel设备。而这个拥有VIP得网卡设备在不同的RS机器上竟然可以是一样的。因为这个网卡是Tunnel解了包装之后得到的目的IP，这个目的IP就必须在本地有对应的网卡设备。

对于国内阿里和腾讯使用的FNAT的模式，负载均衡没有太好的办法。因为FNAT的模式要求每个节点是可路由的，也就是从哪里出去，从哪里回来。这个要求就使得每个节点的位置不一样，也就是不是ECMP下的完全对等的节点，而是有IP地址的普通网络设备。但是也正是因为如此，所以FNAT的模式不需要讲默认路由指向它，所以FNAT和其他的网关设备可以同时存在。