第1章大型互联网公司的基础架构——1.4 接入层技术的演进

在介绍完客户端如何接入机房后，下一步讨论机房收到客户端请求后的调度处理问题。在互联网发展的早期阶段，很多小型互联网服务的后台架构其实非常简单，几乎只有业务服务器“裸奔”在所谓的“机房”里，如图1-6所示。

从图1-6中可以看出，业务后台HTTP服务器直接绑定公网IP地址与客户端建立网络连接，DNS服务器对其域名的解析结果就是HTTP服务器的一个公网IP地址。

这种架构非常轻量、清晰，但是存在如下问题，并不适合作为互联网公司的后台工业级应用架构。

• 可用性低：如果某个业务服务实例宕机，那么DNS服务器将无法高效地感知到其IP地址已不可用，导致被DNS解析到此IP地址的用户请求均不可用。
• 可扩展性差：当业务服务需要扩容时，总需要额外配置DNS；而且受限于DNS解析的生效周期，扩容后的服务新地址难以实时生效。
• 安全风险高：业务服务的IP地址都是公网IP地址，这相当于后台的所有网络地址都暴露在公网环境中，存在网络安全隐患。

如何解决这些问题呢？在软件架构领域有一句很经典的话：“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”。

没错，我们也可以在客户端和业务服务的连接之间引入一个中间层：

• 一方面，它需要负责提高业务服务的可用性和可扩展性，这要求中间层有丰富的功能；
• 另一方面，它还要充当客户端访问业务服务的总代理，将用户流量按规则转发到某个业务服务实例上，这又要求中间层有非常高的性能。

那什么样的服务器可以充当中间层呢？那就是大名鼎鼎的Nginx，一个被各大互联网公司广泛用作用户流量接入中间层的多功能、高性能的服务器。接下来对Nginx做一些必要的功能性介绍。

1.4.1 Nginx

Nginx是一种自由的、开源的、高性能的HTTP服务器和反向代理服务器，同时也是IMAP, POP3、SMTP的代理服务器。Nginx既可以作为HTTP服务器进行网站的发布处理，也可以作为反向代理实现负载均衡功能。

代理的含义非常简单。比如我们需要做某件事但是又不想亲自去做，这时可以找另一个人帮我们去做，这个人就是我们做某件事的代理；再比如租房中介公司就是我们租房的代理。在网络接入层，代理分为正向代理和反向代理。

在我们的日常工作中，正向代理很常见，比如很多公司为了自身的网络安全，不允许居家的员工使用互联网直接访问公司的办公网络环境，而是必须手动配置公司VPN（虚拟专用网络）后才能接入访问。这里VPN充当的就是正向代理的角色，即代理客户端去访问网络。

反向代理的运行方式是代理服务器对外接收互联网上的客户端请求，然后将请求转发到内部网络的目标服务器，并将目标服务器的执行结果返回给客户端。反向代理对外表现得就像目标服务器一样，客户端并不会知道自己访问的其实是一个代理。

总结起来，正向代理与反向代理的核心区别就是：正向代理代理的是客户端，反向代理代理的是服务器，就像图1-7展示的那样。

Nginx能很好地充当反向代理，是因为它有强大的基于域名和HTTP URL的路由转发功能，我们只需要对配置文件nginx.conf做一些简单配置就能轻易搭建出一台反向代理服务器。下面举一个例子。

假设Friendy应用内置了内容推荐、点赞和评论功能，这三个功能在服务端对应于三个HTTP业务服务：feed服务、like服务、comment服务。每个HTTP业务服务都有两个服务器实例，如表1-1所示。

​ 表1-1

服务名	服务器实例地址列表
feed服务	10.1.0.1:8080, 10.1.0.2:8080
like服务	10.2.0.1:8081, 10.2.0.2:8081
comment服务	10.3.0.1:8082, 10.3.0.2:8082

Friendy应用的内容推荐、点赞、评论功能与后台服务器的HTTP通信接口URL分别为/feed、/like、/comment，且均以api.friendy.com作为域名。

因为Nginx服务器作为三个后台服务的反向代理，提供公网IP地址122.14.229.192, 对域名api.friendy.com进行DNS解析会得到这个IP地址，所以Friendy客户端在进行内容推荐、点赞、评论操作时，用户请求将通过网络被传递到这台Nginx服务器。

这台Nginx服务器的配置文件nginx.conf的内容如下：

worker_processes 3;

events {
    worker_connections 1024;
}

http {
    keepalive_timeout 60;
    
    upstream api_friendy_feed {
        server 10.1.0.1:8080;
        server 10.1.0.2:8080;
    }
    
    upstream api_friendy_like {
        server 10.2.0.1:8081;
        server 10.2.0.2:8081;
    }
    
    upstream api_friendy_comment {
        server 10.3.0.1:8082;
        server 10.3.0.1:8082;
    }
    
    server {
        listen 80;
        serverename api.friendy.com;
        
        location /feed {
            proxy_pass http: //api_friendy_feed;
        }
        
        location /like {
            proxy_pass http://api_friendy_like;
        }
        
        location /comment {
            proxy_pass http://api_friendy_comment;
        }
    }
}

接下来对配置文件的内容进行简单解释（注意，这里仅聚焦于Nginx如何配置反向代理而有选择地介绍一些配置项，更多关于Nginx配置的解释可以参考Nginx官网）。

在配置文件中：

• worker_processes配置项表示Nginx将启动几个工作进程来处理用户请求；
• events配置块中的worker_connections配置项表示每个工作进程允许同时最多建立多少个网络连接。

这些都是与TCP高性能服务器相关的配置，并非本书重点。我们需要重点关注的是http配置块，其中有两个子配置块：server和upstream。

server配置块中的配置项代表Nginx实际启动的HTTP服务器所需的各种参数。

• listen： HTTP服务器监听的端口号。
• server_name：用于设置虚拟主机服务名称，用户请求的HTTP请求头会根据Host字段与server_name进行匹配，如果匹配成功，则用户请求被对应的server配置块处理。这里的匹配支持正则表达式。
• location：这是Nginx作为反向代理最重要的配置项之一，每个location都用于指定一个HTTP URL相对路径的处理规则。上面的nginx.conf文件配置了/feed、/like以及/comment请求的处理规则。

location配置块中的proxy_pass是反向代理的另一个重要的配置项，它决定了某个HTTP URL需要被谁代理，代理者可以是一个明确的网络地址，也可以是一个服务池名称。对于本节的Nginx配置而言，/feed、/like、/comment的location配置块分别指定了这三类请求应该被代理到服务池api_friendy_feed、api_friendy_like和api friendy comment。

upstream配置块表示一个服务池，其中的server配置项表示这个服务池中有哪些服务器实例，以及这些服务器实例的地址。上面的nginx.conf文件分别为feed服务、like服务、comment服务配置了对应的服务池。当用户请求被代理到某个服务池后，Nginx会默认以轮询的方式从服务池中选择一个服务器实例作为目标服务器来转发请求。

综上所述，Nginx服务器先以80端口启动对外服务，当收到请求头Host为api.friendy.com的HTTP请求后，根据请求的HTTP URL相对路径做进一步处理。

• 如果相对路径是/feed，则在api_friendy_feed服务池中选择一个服务器实例作为目标服务器转发请求。
• 如果相对路径是/like，则在api_friendy_like服务池中选择一个服务器实例作为目标服务器转发请求。
• 如果相对路径是/comment，则在api_friendy_comment服务池中选择一个服务器实例作为目标服务器转发请求。

至于Nginx会在服务池中选择哪一个服务器实例作为目标服务器，就是Nginx的负载均衡功能的职责了。Nginx常见的负载均衡策略如下。

• 轮询：将每个请求按时间顺序逐一分配到不同的后端服务器，如果某台后端服务器死机，则自动剔除故障系统，使用户访问不受影响。这是Nginx默认的负载均衡策略。
• 加权轮询：为服务器实例配置引入访问权重（weight），权重值越大的服务器实例越容易被访问。例如，在如下服务池配置中，为每个服务器实例设置了不同的权重。

upstream backend {
    server 192.168.1.5:80 weight=10;
    server 192.168.1.6:81 weight=1;
    server 192.168.1.7:82 weight=3;
}

• ip_hash：为每个用户请求按照IP地址的哈希结果分配服务器实例，使得来自同一个IP地址的请求一直访问同一个服务器实例。Nginx使用ip_hash配置项指定此策略。需要说明的是，此策略不保证服务器实例的负载均衡，可能存在个别服务器实例的访问量很大或很小的情况。

upstream backend {
    ip_hash;
    server 192.168.1.6:81;
    server 192.168.1.7:82;
}

• least_conn：此策略将请求转发给连接数最少的服务器实例。轮询、加权轮询的策略会把请求按照一定的比例分发到各服务器，但是有些请求响应时间长，如果把这些响应时间长的请求大比例地发送到某台服务器，那么随着时间的推移，这台服务器的负载会比较大。在这种情况下，适合采用least_conn策略，它能实现更好的负载均衡。
• url_hash：来自第三方模块nginx-upstream-hash，此策略与ip_hash类似，不同之处是它需要对请求URL做哈希运算。这种策略可以有效提高同一个用户请求的缓存命中率。
• fair：来自第三方模块nginx-upstream-failr，此策略根据每个服务器实例的请求响应时间、请求失败数、当前总请求量，综合选择一台最为空闲的服务器。

Nginx的负载均衡功能决定了一个HTTP请求最终被路由到哪个服务器实例，而HTTP位于OSI七层模型的第七层（应用层），所以Nginx作为反向代理也常被称为“七层负载均衡器”。

综上所述，nginx.conf配置文件描述的机房接入层架构如图1-8所示。

• Nginx服务器作为feed服务、like服务、comment服务的反向代理服务器，是后台服务器机房的总入口，通过公网IP地址直接与客户端进行通信。
• Nginx根据收到的HTTP请求的URL相对路径，决定将请求转发到哪个服务以及哪个服务器实例，最后完成客户端与后台服务器中业务服务的交互。

需要注意的是，Nginx服务器需要将每个业务服务的网络地址设置在nginx.conf配置文件中，才能实现与业务服务的通信。但是业务服务会频繁地迭代与扩容，这意味着Nginx upstream服务池中的服务器实例地址列表会频繁地变更。频繁地更新nginx.conf配置文件并不现实，所以我们需要找到一种Nginx实时感知业务服务地址列表变更的方案（具体参见1.5节介绍的服务注册与服务发现，现在仅需知道可以从服务注册中心获取每个服务的最新可用地址列表即可）。

好在Nginx拥有足够多功能强大的模块可以帮助解决这个问题。下面先介绍两个Nginx模块。

• ngx_lua：这个模块将Lua语言嵌入Nginx，从而允许开发人员编与Lua脚本并部署到Nginx中执行。
• ngx_http_dyups_module：这个模块使得Nginx不用重新启动就能热更新upstream配置并生效。

Nginx使用Lua脚本实现服务发现的流程如下所述，如图1-9所示。

1. 每隔一段时间（如3s）就从服务注册中心获取一次nginx.conf配置文件中所有upstream配置的服务地址列表。
2. 获取服务地址列表成功，生成最新的upstream配置，通过ngx_http_dyups_module模块将其更新到Nginx工作进程中。

使用Nginx作为业务服务器的反向代理有如下优势。

1. DNS服务器指向Nginx服务器，业务服务器网络地址切换无须配置DNS。
2. 在用户请求和业务服务器之间实现了负载均衡，更便于控制业务服务流量调度。
3. 对外只暴露一个公网IP地址，节约了有限的IP资源。Nginx服务器与业务服务器之间通过内网通信。
4. 对业务服务器起到了保护作用，外网看不到业务服务器，只能看到不涉及业务逻辑的Nginx反向代理服务器。
5. 增强了系统的可扩展性，业务服务器扩容能做到准实时生效。
6. 提高了业务服务器的可用性。任何一个业务服务实例挂掉，Nginx服务器都可以将用户请求迁移到其他服务实例。

1.4.2 LVS

Nginx是一种高性能的服务器，其性能远高于业务服务器。但是Nginx毕竟是一个应用层软件，单台Nginx服务器能承载的用户请求也是有上限的，当日活用户发展到一定规模后，就需要Nginx集群才能顶住压力。既然是集群，那么势必需要引入一个中间层作为协调者，其负责决定将用户请求转发到哪台Nginx服务器。这个协调者需要有比Nginx更高的性能，它就是本节的主角：LVS。LVS （ Linux Virtual Server, Linux虚拟服务器）是一个虚拟的服务器集群系统，从Linux 2.6版本开始它已经成为Linux内核的一部分，即LVS运行于操作系统层面。

下面先介绍一下LVS和Nginx在转发请求时的区别。

• Nginx是基于OSI参考模型的第七层（应用层）协议开发的，采用了异步转发形式。Nginx在保持客户端连接的同时新建一个与业务服务器的连接，等待业务服务器返回响应数据，然后再将响应数据返回给客户端。Nginx选择异步转发的好处是可以进行失败转移（failover），即：如果与某台业务服务器的连接发生故障，那么就可以换另一个连接，提高了服务的稳定性。Nginx主要强调的是“代理”。
• LVS是基于OSI参考模型的第四层（网络层）协议开发的，采用了同步转发形式。当LVS监听到有客户端请求到来时，会直接通过修改数据包的地址信息将流量转发到下游服务器，让下游服务器与客户端直接连接。LVS主要强调的是“转发”。

由于LVS基于OSI参考模型的网络层，免去了请求到应用层的层层解析工作，而且LVS工作于操作系统层面，所以LVS相比于Nginx有更高的性能。LVS用于网络接入层时也被称为四层负载均衡器。既然LVS四层负载均衡器做的主要工作是转发，那么就需要讨论一下转发模式。目前，LVS主要有4种转发模式：NAT模式、FULLNAT模式、TUN 模式、DR模式。

为了便于描述，在正式介绍这4种转发模式之前，下面介绍一下LVS常用的名词概念。

1. DS（Director Server）：四层负载均衡器节点，也就是运行LVS的服务器。DS和LVS作为角色时是一个意思。
2. RS (Real Server)：DS请求转发的目的地，即真实的工作服务器。
3. VIP( Virtual Server IP)：客户端请求的目的IP地址，实际指的是DS的公网IP地址。
4. DIP (Director Server IP)：用于DS与RS通信的IP地址，实际指的是DS的内网IP地址。
5. RIP (Real Server IP)：后端服务器的IP地址。
6. CIP (Client IP)：客户端 IP 地址。

这里讨论的转发模式实际上就是指客户端向DS公网VIP发起请求，然后DS负责将请求转发给RS的过程。

（1）NAT模式

NAT模式是指通过修改请求报文的目标IP地址和目标端口号实现DS到某个RS的请求转发。在此模式下，网络报文的请求与响应都要经过DS的处理，DS是RS的网关。在NAT模式下进行请求转发的整个过程如下所述，如图1-10所示。

1. 客户端发送请求到LVS的VIP，请求到达DS。
2. DS选择一个RS作为请求转发的目的地，然后修改客户端请求的目的IP地址为对应RS的RIP，将请求从DIP发送给所选择的RS。
3. RS收到请求后，发现请求的目的IP地址是自己的IP地址（RIP），于是处理请求，然后返回响应数据，其中源IP地址为RIP，目的IP地址为CIP。
4. DS作为RS的网关会收到响应数据，然后修改响应数据的源地址为VIP。
5. 客户端收到响应数据。

配置LVS NAT模式需要满足如下条件：

• DS需要两块网卡，其中一块网卡面向公网提供VIP，另一块网卡面向内部网络提供DIP。
• DS需要和所有的RS处于同一个局域网内，并将DS设置为局域网的网关，否则RS的响应数据将无法传输到DS。

NAT模式的缺点也显而易见：客户端请求和服务器响应都会经过DS重写，而服务器响应数据的长度一般远大于客户端请求的长度，响应数据会对DS造成网络带宽压力，成为性能瓶颈。

（2）FULLNAT模式

FULLNAT模式是NAT模式的优化版，它不要求DS与RS处于同一个局域网内且作为网关。DS在NAT模式的基础上又做了一次源IP地址转化，这样一来，当RS返回响应数据时，根据IP地址即可将其正常路由到DS，而不需要强行指定DS为网关。FULLNAT模式的主要缺点是请求到达RS后会丢失客户端IP地址。

在FULLNAT模式下进行请求转发的整个过程如下所述，如图1-11所示。

1. 客户端发送请求到LVS的VIP，请求到达DS。
2. DS选择一个RS作为请求转发的目的地，然后分别修改客户端请求的目的IP地址为对应RS的RIP，源IP地址为DIP，然后将请求从DIP发送给所选择的RS。
3. RS收到请求后，发现请求目的IP地址是自己的IP地址（RIP）,于是处理请求， 然后返回响应数据，其中源IP地址为RIP，目的IP地址为DIP。
4. DS通过数据传输层收到RS响应数据，然后分别修改响应数据的源IP地址为 VIP，目的IP地址为CIP。
5. 客户端收到响应数据。

（3）TUN（IP隧道）模式

DS通过IP隧道加密技术将请求报文封装到一个新的数据包中，并选择一个RS的IP地址作为新数据包的目的IP地址，然后将它发送到对应的RS；RS基于IP隧道解密技术解析出原数据包的内容，查看RS本地是否绑定了原数据包的目的IP地址，如果是，则处理请求并将响应结果通过网关返回给客户端。在TUN模式下进行请求转发的整个过程如下所述，如图1-12所示。

1. 客户端发送请求到LVS的VIP，请求到达DS。
2. DS选择一个RS作为请求转发的目的地，并将数据包封装到一个新的数据包中，其中新数据包的源IP地址为DIP，目的IP地址为对应RS的RIP，然后通过IP隧道发送新数据包。
3. RS对IP隧道的数据包进行解析，得到原数据包。
4. RS看到原数据包的目的IP地址是VIP，而RS本地lo网卡也配置了此VIP，于是RS处理数据包。
5. RS返回响应数据，其中源IP地址为VIP，目的IP地址为CIP。响应数据通过网关到达客户端。

配置LVS TUN模式的特点如下：

• DIP和RIP不一定非要在同一个网络环境中，IP隧道技术可以根据IP地址找到RS。
• RS和DS所在的网络环境必须支持IP隧道技术。
• 除了DS，RS也需要配置VIP，这样一来，RS只有解析出原数据包的内容后才能确认数据包的目的IP地址是自己。另外，需要将VIP绑定到RS的lo网卡，这样才能防止对ARP（地址解析协议）进行响应。
• DS仅负责将请求转发到RS，但是RS的响应数据不通过DS转发，而是直接发往客户端，所以TUN模式的性能高于NAT模式。

（4）DR模式

与TUN模式类似（DS仅转发请求并不转发响应数据），DR模式通过改写请求报文的MAC地址将请求转发到RS，然后RS将响应数据通过网关返回给客户端。假设客户端MAC地址、DS的地址和3个RS的MAC地址分别为M1~M5，在DR模式下进行请求转发的过程如下所述，如图1-13所示。

1. 客户端发送请求到LVS的VIP，请求到达DS。
2. DS选择一个RS作为请求转发的目的地，并将数据包的目的MAC地址改为RS对应的MAC地址，然后通过局域网DIP发出数据包。
3. RS读取数据包，看到目的IP地址是VIP，已被绑定到RS本地的lo网卡，然后RS处理数据包。
4. RS返回响应数据，并将数据包的源MAC地址改为M3，将目的MAC地址改为客户端MAC地址M1，然后RS通过网关将响应数据直接发送给客户端。

配置LVS DR模式的特点如下：

• 由于DS经过数据链路层（OSI参考模型的第二层），所以需要把RS的RIP和DS的DIP配置到同一个物理网络中。
• 除了 DS，RS也需要在lo网卡上配置VIP，理由与TUN模式的一致。
• 所有的响应数据都不经过DS转发，与TUN模式一样，但是TUN模式涉及加密/解密IP隧道，性能不如DS模式。

通过对LVS的4种转发模式的介绍，我们大致可以了解它们的优劣势，如表1-2所示。

​ 表1-2

转发模式	优势	劣势
NAT	RS无须配置VIP	DS需要作为网关；性能一般
FULLNAT	RS无须配置VIP；对网络环境要求较低	丢失客户端IP地址；性能一般
TUN	性能好	服务器需要支持IP隧道协议；RS需要配置VIP
DR	性能好	DS和RS需要在同一个物理网络中；RS需要配置VIP

如果我们希望LVS有更强的网络环境适应性，则可以选择FULLNAT模式，这也是笔者推荐的模式；而如果希望LVS有更高的性能，则可以选择DR模式。

1.4.3 LVS+Nginx接入层的架构

机房接入层使用LVS与Nginx的配合可以发挥这两种负载均衡器的优势：

• LVS的性能更高，便于Nginx构建集群，LVS作为Nginx集群的四层负载均衡器，可以有效提高 Nginx的可扩展性；
• 而Nginx的功能更为强大，用它作为业务HTTP服务器的七层负载均衡器，能将不同的HTTP URL调度到不同的业务服务并提高业务服务的高可用性和可扩展性。

LVS+Nginx的机房接入层架构如图1-14所示。

将机房配置的LVS的公网IP地址（即VIP）作为域名，客户端请求经过DNS解析后进入LVS，然后LVS使用如FULLNAT模式将客户端请求转发到任意一台Nginx服务器，Nginx 服务器再根据HTTP URL将客户端请求转发到某个upstream服务池的任意一个服务器实例上。

不过，此架构有一个明显的缺点，即LVS是单点：如果LVS宕机，则整个机房将无法对外提供服务。因此，我们需要解决LVS的高可用问题。

通常，我们可以采用主从热备方案来解决单点的高可用问题。即：为原本单点的节点（主节点）配置一个从节点，在主节点正常对外提供服务期间从节点并不工作，而在主节点发生故障后会自动切换到从节点继续对外提供服务。业界常见的实现主从热备的技术方案是Keepalived+VIP，例如在主节点A和从节点B均安装了Keepalived并启动后，主节点A就会通过ARP响应包告知局域网VIP对应的MAC地址为MAC-A（主节点MAC地址），之后所有收到这个ARP响应包的网络设备在访问VIP时，就会根据MAC-A访问到主节点A。当从节点B监听到主节点A宕机后，它就会代替主节点A向局域网回复ARP响应包：“VIP对应的MAC地址为MAC-B”。于是，之后所有收到ARP响应包的网络设备再次访问VIP时，就会根据MAC-B转而访问到从节点B，从节点B自动代替了主节点 A，如图1-15所示。

为单点LVS引入Keepalived+VIP方案后实现的高可用架构如图1-16所示。

这样的机房接入层架构完美吗？其实并不完美。LVS虽然性能极高，但也是有上限的。假设我们的互联网产品已经拥有亿级用户，那么单台LVS就会遇到性能瓶颈。想要痛快地解决某个系统的高并发性能问题，就要为这个系统增加水平扩展能力。如图1-17所示， 我们可以使用多台LVS对外提供服务。如果有N台LVS对外提供服务，那么就要配置N个VIP，这些VIP都绑定了同一个域名，客户端依赖DNS轮询来决定访问哪台LVS。

对于绝大多数互联网应用来说，做到这一步已经可以解决机房接入层的高可用、高性能、可扩展的问题了。最终机房接入层架构已经趋于完备，此时：

1. 通过DNS轮询方式扩展LVS的性能；
2. 通过 Keepalived 保证 LVS；
3. 通过LVS扩展Nginx的性能；
4. 将Nginx作为业务HTTP服务器的七层负载均衡器，提高了业务服务的高可用性与可扩展性。

总结

正向代理和反向代理的区别？

• 正向代理代理的是客户端。正向代理很常见，比如很多公司为了自身的网络安全，不允许居家的员工使用互联网直接访问公司的办公网络环境，而是必须手动配置公司VPN（虚拟专用网络）后才能接入访问。这里VPN充当的就是正向代理的角色。
• 反向代理代理的是服务器。反向代理的运行方式是代理服务器对外接收互联网上的客户端请求，然后将请求转发到内部网络的目标服务器，并将目标服务器的执行结果返回给客户端。反向代理对外表现得就像目标服务器一样，客户端并不会知道自己访问的其实是一个代理。

为什么会出现LVS呢？

• Nginx是一种高性能的服务器，其性能远高于业务服务器。但是Nginx毕竟是一个应用层软件，单台Nginx服务器能承载的用户请求也是有上限的，当日活用户发展到一定规模后，就需要Nginx集群才能顶住压力。既然是集群，那么势必需要引入一个中间层作为协调者，其负责决定将用户请求转发到哪台Nginx服务器。这个协调者需要有比Nginx更高的性能，这就由此诞生了LVS。

LVS和Nginx在转发请求时的区别？

• Nginx是基于OSI参考模型的第七层（应用层）协议开发的，采用了异步转发形式。Nginx在保持客户端连接的同时新建一个与业务服务器的连接，等待业务服务器返回响应数据，然后再将响应数据返回给客户端。Nginx选择异步转发的好处是可以进行失败转移（failover），即：如果与某台业务服务器的连接发生故障，那么就可以换另一个连接，提高了服务的稳定性。Nginx主要强调的是“代理”。
• LVS是基于OSI参考模型的第四层（网络层）协议开发的，采用了同步转发形式。当LVS监听到有客户端请求到来时，会直接通过修改数据包的地址信息将流量转发到下游服务器，让下游服务器与客户端直接连接。LVS主要强调的是“转发”。

LVS有哪些转发模式？

1. NAT模式
2. FULLNAT模式
3. TUN模式
4. DR模式