从内网访问外网

这种服务的网络结构如图3-4所示。与前两种网络结构不同，SNAT服务的发起方（用户）来自IDC内部，访问对象是外部网络服务。因此，也可以把SNAT看作“反向”的负载均衡。出于对内部设备硬件配置、IP利用、安全控制等因素的考虑，一般不允许IDC内部的设备直接访问外部网络（外网）。常用的做法是在IDC防火墙后面使用负载均衡器构建能直接访问外网的SNAT服务器集群，然后将需要访问外网的设备通过路由或其他形式把数据包引入该SNAT服务器集群，SNAT服务器会根据负载均衡转发规则把外网访问请求转发到外部网络；外部网络的响应数据也会在穿过IDC防火墙后传到SNAT服务器，然后由SNAT服务器转给发起请求的内部用户。

从外网访问内网

负载均衡器作用：

提供外网VIP和流量均衡

我们把多台应用服务器配置在负载均衡器后端，当用户访问时，目标地址不是使用某台应用服务器的IP地址，而是使用负载均衡器上的IP地址。这样，用户访问的目标就由应用服务器变成了负载均衡器，然后由负载均衡器决定把该用户访问交由哪一台应用服务器处理。需要注意的是，前文说的是“负载均衡器上的IP地址”，而非“负载均衡器的IP地址”。这是因为在负载均衡器上，我们一般使用虚拟IP地址（VIP）作为用户访问应用服务的入口地址。使用虚拟IP地址而非负载均衡器的真实IP地址的主要原因如下。

● 负载均衡器的高可用性（High Availability，HA）要求：回顾3.1.1节介绍的负载均衡器的网络结构，负载均衡器位于一个网段的流量入口位置，如果负载均衡器发生故障，则可能会导致整个网络的服务不可用。因此负载均衡器在实际生产环境中都是需要做到HA的。HA要求单台负载均衡器设备发生故障时，业务流量能自动切换到其他负载均衡器上，也就是要求作为应用服务访问入口的IP地址切换到其他负载均衡器上，或者同时配置在多台负载均衡器上。如果想要实现IP地址在多台设备之间的转移，或者同时配置在多台设备上而不发生地址冲突，则只能使用虚拟IP地址。

● 业务隔离的需要：我们在后面会知道，采用负载均衡模式提供的服务性能是远高于单台应用服务器的性能的。在这种情况下，我们必然会想到把不同的服务部署在同一台负载均衡器上以实现资源的有效利用。为了做到业务隔离，我们希望每个业务的访问入口IP地址都不相同。这就导致一台负载均衡设备上可能配置很多个IP地址。网络设备的实体IP地址一般是唯一的，我们不可能为每个业务在负载均衡器上配置一个实体IP地址，但在一个网络设备上配置多个虚拟IP地址是很常见的，所以采用虚拟IP地址作为应用服务的入口地址可以兼顾负载均衡器的利用效率和业务隔离。

如何将请求返回给用户

按照对这个问题的不同处理方式，外网负载均衡器可以分成两类：直接应答式外网负载均衡器和NAT应答式外网负载均衡器。

直接应答式外网负载均衡器的工作原理如图3-5所示。①当外网用户请求穿过内网防火墙访问负载均衡器上的业务VIP时；②负载均衡器按照一定的策略选择一台应用服务器并将用户请求转发给它；③应用服务器处理完用户请求后，将响应数据直接发给外网用户。这种负载均衡器只有入口（inbound）方向的请求流量，没有出口（outbound）方向的响应流量，特别适合用于响应数据量很大的应用服务，如文件下载、CDN视频和图片分发等。这种负载均衡器的缺点是对外网用户暴露了应用服务器，而且应用服务器需要有外网访问权限。让应用服务器获得外网访问权限，一般有两种方法：一种方法是配置独立的外网IP地址；另一种方法是使用SNAT访问外网（从内网访问外网）。显然，使用SNAT访问外网的方法更安全一些，因为在这种情况下对外网用户暴露的IP地址不是应用服务器本身的IP地址，而是SNAT服务器的外网出口地址。

提供内网VIP和IDC内部服务

与外网负载均衡器类似，内网负载均衡器根据应用服务器响应用户请求方式的不同，可以分为直接应答式内网负载均衡器和NAT应答式内网负载均衡器。

直接应答式内网负载均衡器的工作原理如图3-7所示。①当内网用户请求负载均衡器上的业务VIP时；②负载均衡器按照一定的策略选择一台内网应用服务器并将用户请求转发给它；③应用服务器处理完用户请求后，将响应数据直接发送给内网用户。这种负载均衡器只有inbound方向的请求流量，响应数据由应用服务器直接返回给用户，性能比较高。由于在IDC内部网络中向内部用户暴露应用服务器一般不会造成太大的安全隐患，所以这种负载均衡器在IDC内部服务中应用很广泛。需要注意的是，在比较复杂的内网环境（多个不同物理位置的IDC通过内网专线连接构成的一个大的企业内网）中，内部用户和应用服务集群可能不在同一个IP子网中，因此必须保证应用服务器到内部用户的路由可达，否则响应数据将无法返回给用户。

NAT应答式内网负载均衡器的工作原理如上图所示。①当内网用户请求负载均衡器上的业务VIP时；②负载均衡器按照一定的策略选择一台内网应用服务器并将用户请求转发给它；③应用服务器处理完用户请求后，将响应数据发回到负载均衡器；④负载均衡器将响应数据转发给内网用户。这种负载均衡器请求流量和响应流量都经过了内网接口的inbound和outbound两个方向，性能比直接应答式内网负载均衡器要差一些。但是，由于进行了NAT模式或FullNAT模式转换，这种负载均衡器对IDC内部网络环境要求较低，在部署和管理上相对有优势，所以在性能要求不高且IDC网络比较复杂的内网服务中有很多应用。从结构上来看，NAT应答式内网负载均衡器两侧连接的是同一个内网，我们称这种负载均衡器为“单臂（one-arm）”负载均衡器。从用户角度上来看，NAT应答式内网负载均衡器也是一种反向代理服务器。最后，需要指出的一点是，NAT应答式内网负载均衡器可以实现四层端口的变换，配置时允许VIP和应用服务器的四层端口不同，当负载均衡器转发用户请求时会把VIP对应的TCP/UDP四层端口转换为应用服务器对应的服务器端口，从而为通过VIP端口细分不同应用服务提供了可能。比如，用户访问HTTP服务时使用标准的80端口，而负载均衡器后端的应用服务器真正的服务器端口可能是8080。

使用SNAT集群提供外网访问

常见的负载均衡器

一、四层

硬件实现

硬件实现的负载均衡器是直接在服务器和外部网络之间安装负载均衡设备，这种设备通常是一个独立于系统的硬件。目前，常见的四层负载均衡器是F5，硬件实现使得F5能够独立于系统被使用。相对于软件实现的负载均衡器，F5的整体性会更高，能够实现智能流量管理。但是，该硬件实现的负载均衡器的缺点是成本高，无开源代码，无法进行二次开发。

软件实现

四层负载均衡器的软件实现方案的费用较低，如开源的HAProxy和Linux Virtual Server（LVS）。其中，LVS是由章文嵩开源的，因为其高性能、高可用性，目前被广泛应用到实际生产运营中。

LVS主要有以下几个优点：①抗负载能力强、仅分发请求、不产生流量，该特点使其对内存及CPU的消耗较低；②有完整的双机热备方案，如“LVS+Keepalived”，这保证了LVS工作的稳定；③应用范围较广，几乎能对所有应用进行负载均衡，包括HTTP请求、数据库、聊天室等；④配置简单，这既是该技术的优点也是缺点，优点是不会受到过多人为配置的影响，缺点是配置性低，可配置选项单一。

除了上文提到的配置性低的缺点，LVS还有两个缺点是不支持正则表达式处理，不能做动静分离，而且在网站应用时，LVS+Keepalived实施起来比较复杂。

软件实现方案对比

虽然LVS具有很强的抗负载能力，但是在高并发时还是会受到内核协议栈的限制，为此，爱奇艺在DPDK技术的基础上开发了一种性能更高的负载均衡器——DPVS，与基于Linux内核开发的LVS相比，DPVS的特点如下。

● 更高的性能：DPVS的包处理速度很快，单个工作线程的性能可以达到2.3 Mpps，6个并发的工作线程的性能可以达到万兆网卡小包的转发线速（约12Mpps）。这主要是因为DPVS绕过了复杂的内核协议栈，并采用轮询的方式收发数据包，避免了锁、内核中断、上下文切换、内核态和用户态数据复制产生的性能开销。

● 更完善的功能：从转发模式上来看，DPVS支持DR、NAT、Tunnel、FullNAT、SNAT共5种转发模式，可以灵活适配各种网络应用场景；从协议支持上来看，DPVS支持IPv4协议和IPv6协议，且最新版本的DPVS增加了NAT64的转发功能，使用户可以通过IPv6网络访问IPv4服务。

● 更好的维护性：DPVS是一个用户态程序，与内核态程序相比，功能开发周期更短、调试更方便、问题修复更及时。

七层负载均衡器

本节主要介绍现有的七层负载均衡器，除了Nginx，实际上还有很多种类型的七层负载均衡器。下面会简单介绍几种较为常见的七层负载均衡器，同时，针对目前比较流行的F-Stack和Nginx两种实现方案进行性能对比。

硬件实现

硬件负载均衡器通常是将转发逻辑直接放在一个嵌入式设备内。该设备通常是定制化的设备，区别于普通的Linux服务器。

常见的七层负载均衡器是F5。F5不仅可以作为四层负载均衡器，也可以作为七层负载均衡器。F5的功能很强大，除了可以转发HTTP/HTTPS请求，它还可以实现SSL加速、动态Session会话保持、Cookie加密、选择性内容加密等一系列高级功能。但是它的缺点也很明显，成本昂贵、无法获取源代码、无法进行二次开发。

软件实现：HAProxy

HAProxy实际上是一款既支持四层负载又支持七层负载均衡的设备。它采用单一进程的事件驱动模型，在很多场景下都有非常不错的性能表现，但是在多核平台上会出现性能瓶颈，而且它的功能没有Nginx的功能强大，也不如Nginx那样便于开发，所以HAProxy现在越来越多地被Nginx所取代。

实现方案对比：F-Stack与Nginx

F-Stack是一款由腾讯开源的用户态协议栈。该协议栈是基于DPDK和FreeBSD来实现的。由于该协议栈主要是基于FreeBSD来实现的，因此与其他一些自研的轻量级协议栈相比，该协议栈具有很高的稳定性。此外，与内核态的FreeBSD相比，F-Stack实现了无锁化、无中断，从而拥有相当优秀的性能。

基于F-Stack实现的Nginx可以充分利用F-Stack Kernel Bypass的优异性能。Nginx的多进程模型可以使每个Worker都在一个独立的协议栈上，因此可以使吞吐量达到很高的状态。图4-2来源于F-Stack团队给出的数据，其中Nginx表示原生的Nginx，Nginx_si表示在原生Nginx上进行了CPU亲和性。