一个庞大的高访问量的业务系统，需要高性能、可靠的服务器框架支撑。高性能要求服务器在巨大压力下仍然高速运行，读写返回正确的业务信息，前端用户体验良好。可靠性要求服务器出现宕机、罢工等情况，可以及时恢复服务器正常工作状态，支持业务系统24小时健康运行。使用缓存、读写分离技术提高服务器访问资源速度，解决大访问量资源拥堵问题；使用负载均衡与高可用技术提高服务器响应速度以及服务器稳定性，解决服务器处理大用户量请求问题以及服务器宕机的及时恢复能力。同时，需要部署运维监控平台，监控服务器上服务程序与资源使用情况。

这样一个业务系统基础架构可以划分下面几个模块：负载均衡与代理、Web主站服务、APP接口服务、图片服务器、数据库与缓存服务。这里负载均衡和代理主要是两个作用：实现多台机器按照算法轮流工作，分担服务压力，当一台机器宕机或者罢工，其他机器也可以继续运行；代理隐藏服务内部真实结构，多台对外提供统一地址，运行相同业务系统，后文会详细介绍负载均衡。

主站框架是一个Web服务器（apache、tomcat、nginx等）集群，集群中全部机器运行相同业务系统。通过负载均衡代理与客户端通讯，每一次通讯只有一台机器为当前客户端服务。需要解决session共享问题，否则将会丢失用户的登录状态，在用户体验方面有逻辑错误。常见的共享session方法有数据库共享、cookie共享、内存共享。使用最多的是memcache共享方式，memcache把多个服务器的共享内存拼接成一块大的内存使用，保存用户的session信息。Tomcat服务集群可以简单配置memcache共享内存，PHP中也可以直接配置设置memcache共享内存。

Nginx负载解决session的方式：ip_hash、sticky。ip_hash根据IP保存响应服务器，在一张存储表单中，IP对应上次访问的服务器，以后来自于该IP的访问都使用这个这台服务器，解决session问题，存在局限性影响负载均衡的功能。Sticky使用cookie的方式解决session共享问题，其实是避开session共享。Sticky把cookie与服务器绑定，存储于客户端缓存当中，客户端再次访问时直接进入到cookie绑定的服务器，关闭客户端session也随之消失。

缓存服务可以提高服务的响应速度，处理及时性要求高的数据时，数据首先进入缓存，然后通过消息队列写入到数据库。从数据库查询出来的实时数据也可以保存在缓存中，在缓存中直接提供用户访问，执行用户操作数据请求，再把数据返回数据库。

Redis是一款出色的缓存服务器，内存级别的键值对数据库，支持丰富数据结构，数据库操作命令也是很齐全。最重要是Redis操作速度非常快，满足缓存服务器需求。Redis提供单机的分片集群，单机硬件性能要求比较高。Redis也可以进行分布式部署，搭建分布式缓存服务。

安全配置：隐藏常见系统服务信息、配置用户权限、开启防火墙、关闭无用系统服务、定期更新系统
风险评估：进行渗透测试、漏洞扫描
安全防御：配置IDS\IPS、进行源代码审计、DDOS防御、恶意代码检测

配置运维监控平台，实时监控服务器的健康状况。CPU、内存、磁盘、输入输出、网络性能等参数，配置报警规则，触发报警是立即调用API接口或者第三方回调，发送报警信息到邮箱、微信等。同时，自定监控数据项，检测Web服务、数据库服务、后台程序等运行状态，连续出现拒绝服务行为立刻报警，通知管理员。

负载均衡介绍

负载均衡（Load Balance）是建立在现有网络结构之上，提供一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。就是分摊任务到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

负载均衡，核心就是网络流量分发，服务器负载均衡根据LB设备处理到的报文层次，分为四层服务器负载均衡（TCP，UDP）和七层负载均衡（HTTP，HTTPS等），四层处理到IP包的IP头，不解析报文四层以上载荷（L4 SLB），基本就是根据连接信息（TCP）或者本身的特征（源IP，目标IP）等做；七层处理到报文载荷部分，比如HTTP，RTSP，SIP报文头，有时也包括报文内容部分，可以用域名（HTTP头里的Host），URL，Cookie，Header这些信息来做。四层LB可以说是作为路由进行流量转发，七层LB常称作代理。

负载均衡根据所采用的设备对象（软硬件负载均衡），应用的OSI网络层次（网络层次上的负载均衡），及应用的地理结构（本地/全局负载均衡）等来分类。负载均衡现在比较新的做法是用dpdk这种内核bypass方案做的负载均衡，绕过了linux内核比较复杂的网络协议栈，因此性能会有明显的提升（轻松跑满万兆网卡）。

根据负载均衡所作用在 OSI 模型的位置不同，负载均衡可以大概分为以下几类：

二层负载均衡（mac）

根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应。

三层负载均衡（ip）

一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应。

四层负载均衡（tcp）

在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。

七层负载均衡（http）

根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。反向代理，就是通过代理来做（Nginx）。由于流量都会过LB，因此可以做到比较精细的流量分发（比如各种权重，七层的各种转发规则）。坏处就是代理本身可能成为瓶颈，以及过了一层代理造成网络延时的增加，而代理本身也会有一定成本，因此实现成本较高。

在实际应用中，比较常见的就是四层负载及七层负载。这里也重点说下这两种负载。

一、四层负载均衡（基于IP+端口的负载均衡）

所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

  1. 在三层负载均衡的基础上，通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

  2. 以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

  3. 对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等）
    要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

  4. 实现四层负载均衡的软件有：
    F5：硬件负载均衡器，功能很好，但是成本很高。
    lvs：重量级的四层负载软件
    nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
    haproxy：模拟四层转发，较灵活

二、七层负载均衡（基于虚拟的URL或主机IP的负载均衡）

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

  1. 在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

  2. 以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。

  3. 对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议。

  4. 实现七层负载均衡的软件有：
    haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；
    nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；
    apache：功能较差
    Mysql proxy：功能尚可

四层和七层负载均衡的区别，举个例子形象的说明：四层负载均衡就像银行的自助排号机，每一个达到银行的客户根据排号机的顺序，选择对应的窗口接受服务；而七层负载均衡像银行大堂经理，先确认客户需要办理的业务，再安排排号。这样办理理财、存取款等业务的客户，会根据银行内部资源得到统一协调处理，加快客户业务办理流程。

特征 四层负载均衡 七层负载均衡
基于 基于IP+Port的 基于虚拟的URL或主机IP等
类似 路由器 代理服务器
握手次数 1次 2次
复杂度 低 高
性能 高，无需解析内容 中，需要算法识别 URL，Cookie 和 HTTP head 等信息
安全性 低，无法识别 DDoS等攻击 高， 可以防御SYN cookie以SYN flood等
额外 无 会话保持，图片压缩，防盗链等

总结：从上面的对比看来四层负载与七层负载最大的区别就是效率与功能的区别。四层负载架构设计比较简单，无需解析具体的消息内容，在网络吞吐量及处理能力上会相对比较高，而七层负载均衡的优势则体现在功能多，控制灵活强大。在具体业务架构设计时，使用七层负载或者四层负载还得根据具体的情况综合考虑。

以下介绍下四层七层负载均衡实现方式

一、http重定向

当http代理（比如浏览器）向web服务器请求某个URL后，web服务器可以通过http响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理需要继续请求这个新的URL，完成自动跳转。

性能缺陷：
1、吞吐率限制
主站点服务器的吞吐率平均分配到了被转移的服务器。现假设使用RR（Round Robin）调度策略，子服务器的最大吞吐率为1000reqs/s，那么主服务器的吞吐率要达到3000reqs/s才能完全发挥三台子服务器的作用，那么如果有100台子服务器，那么主服务器的吞吐率可想而知得有大？相反，如果主服务的最大吞吐率为6000reqs/s，那么平均分配到子服务器的吞吐率为2000reqs/s，而现子服务器的最大吞吐率为1000reqs/s，因此就得增加子服务器的数量，增加到6个才能满足。

2、重定向访问深度不同
有的重定向一个静态页面，有的重定向相比复杂的动态页面，那么实际服务器的负载差异是不可预料的，而主站服务器却一无所知。因此整站使用重定向方法做负载均衡不太好。

我们需要权衡转移请求的开销和处理实际请求的开销，前者相对于后者越小，那么重定向的意义就越大，例如下载。你可以去很多镜像下载网站试下，会发现基本下载都使用了Location做了重定向。

二、DNS负载均衡

DNS负责提供域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程中，DNS服务器完成了域名到IP地址的映射，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了负载均衡调度器，它就像http重定向转换策略一样，将用户的请求分散到多台服务器上，但是它的实现机制完全不同。

相比http重定向，基于DNS的负载均衡完全节省了所谓的主站点，或者说DNS服务器已经充当了主站点的职能。但不同的是，作为调度器，DNS服务器本身的性能几乎不用担心。因为DNS记录可以被用户浏览器或者互联网接入服务商的各级DNS服务器缓存，只有当缓存过期后才会重新向域名的DNS服务器请求解析。也说是DNS不存在http的吞吐率限制，理论上可以无限增加实际服务器的数量。

特性:
1、可以根据用户IP来进行智能解析。DNS服务器可以在所有可用的A记录中寻找离用记最近的一台服务器。

2、动态DNS：在每次IP地址变更时，及时更新DNS服务器。当然，因为缓存，一定的延迟不可避免。

不足：
1、没有用户能直接看到DNS解析到了哪一台实际服务器，加服务器运维人员的调试带来了不便。

2、策略的局限性。例如你无法将HTTP请求的上下文引入到调度策略中，而在前面介绍的基于HTTP重定向的负载均衡系统中，调度器工作在HTTP层面，它可以充分理解HTTP请求后根据站点的应用逻辑来设计调度策略，比如根据请求不同的URL来进行合理的过滤和转移。

3、如果要根据实际服务器的实时负载差异来调整调度策略，这需要DNS服务器在每次解析操作时分析各服务器的健康状态，对于DNS服务器来说，这种自定义开发存在较高的门槛，更何况大多数站点只是使用第三方DNS服务。

4、DNS记录缓存，各级节点的DNS服务器不同程序的缓存会让你晕头转向。

5、基于以上几点，DNS服务器并不能很好地完成工作量均衡分配，最后，是否选择基于DNS的负载均衡方式完全取决于你的需要。

三、反向代理负载均衡

这个肯定大家都有所接触，因为几乎所有主流的Web服务器都热衷于支持基于反向代理的负载均衡。它的核心工作就是转发HTTP请求。

相比前面的HTTP重定向和DNS解析，反向代理的调度器扮演的是用户和实际服务器中间人的角色：

1、任何对于实际服务器的HTTP请求都必须经过调度器

2、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户（前两种方式不需要经过调度反馈，是实际服务器直接发送给用户）

特性：
1、调度策略丰富。例如可以为不同的实际服务器设置不同的权重，以达到能者多劳的效果。

2、对反向代理服务器的并发处理能力要求高，因为它工作在HTTP层面。

3、反向代理服务器进行转发操作本身是需要一定开销的，比如创建线程、与后端服务器建立TCP连接、接收后端服务器返回的处理结果、分析HTTP头部信息、用户空间和内核空间的频繁切换等，虽然这部分时间并不长，但是当后端服务器处理请求的时间非常短时，转发的开销就显得尤为突出。例如请求静态文件，更适合使用前面介绍的基于DNS的负载均衡方式。

4、反向代理服务器可以监控后端服务器，比如系统负载、响应时间、是否可用、TCP连接数、流量等，从而根据这些数据调整负载均衡的策略。

5、反射代理服务器可以让用户在一次会话周期内的所有请求始终转发到一台特定的后端服务器（粘滞会话），这样的好处一是保持session的本地访问，二是防止后端服务器的动态内存缓存的资源浪费。

四、IP负载均衡(LVS-NAT)

NAT服务器:它工作在传输层，它可以修改发送来的IP数据包，将数据包的目标地址修改为实际服务器地址。

数据的流向：

客户端 –> Load Balancer –> RS –> Load Balancer –> 客户端

从Linux2.4内核开始，其内置的Neftilter模块在内核中维护着一些数据包过滤表，这些表包含了用于控制数据包过滤的规则。可喜的是，Linux提供了iptables来对过滤表进行插入、修改和删除等操作。更加令人振奋的是，Linux2.6.x内核中内置了IPVS模块，它的工作性质类型于Netfilter模块，不过它更专注于实现IP负载均衡。

IPVS的管理工具是ipvsadm，它为提供了基于命令行的配置界面，可以通过它快速实现负载均衡系统。这就是大名鼎鼎的LVS(Linux Virtual Server，Linux虚拟服务器)。

1、打开调度器的数据包转发选项

echo 1 > /proc/sys/net/ipv4/ip_forward

2、检查实际服务器是否已经将NAT服务器作为自己的默认网关，如果不是，如添加

route add default gw xx.xx.xx.xx

3、使用ipvsadm配置

ipvsadm -A -t 111.11.11.11:80 -s rr

添加一台虚拟服务器，-t 后面是服务器的外网ip和端口，-s rr是指采用简单轮询的RR调度策略（这属于静态调度策略，除此之外，LVS还提供了系列的动态调度策略，比如最小连接（LC）、带权重的最小连接（WLC），最短期望时间延迟（SED）等）

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m

添加两台实际服务器（不需要有外网ip），-r后面是实际服务器的内网ip和端口，-m表示采用NAT方式来转发数据包

运行ipvsadm -L -n可以查看实际服务器的状态。这样就大功告成了。

实验证明使用基于NAT的负载均衡系统。作为调度器的NAT服务器可以将吞吐率提升到一个新的高度，几乎是反向代理服务器的两倍以上，这大多归功于在内核中进行请求转发的较低开销。但是一旦请求的内容过大时，不论是基于反向代理还是NAT，负载均衡的整体吞吐量都差距不大，这说明对于一开销较大的内容，使用简单的反向代理来搭建负载均衡系统是值考虑的。

这么强大的系统还是有它的瓶颈，那就是NAT服务器的网络带宽，包括内部网络和外部网络。当然可以配备千兆交换机或万兆交换机，甚至负载均衡硬件设备，除了这另一个简单有效的办法就是将基于NAT的集群和前面的DNS混合使用，比如５个100Mbps出口宽带的集群，然后通过DNS来将用户请求均衡地指向这些集群，同时，你还可以利用DNS智能解析实现地域就近访问。这样的配置对于大多数业务是足够了，但是对于提供下载或视频等服务的大规模站点，NAT服务器还是不够出色。

五、直接路由(LVS-DR)

NAT是工作在网络分层模型的传输层（第四层），而直接路由是工作在数据链路层（第二层），貌似更屌些。它通过修改数据包的目标MAC地址（没有修改目标IP），将数据包转发到实际服务器上，不同的是，实际服务器的响应数据包将直接发送给客户羰，而不经过调度器。

数据的流向：

客户端 –> Load Balancer –> RS –> 客户端

1、网络设置

这里假设一台负载均衡调度器，两台实际服务器，购买三个外网ip，一台机一个，三台机的默认网关需要相同，最后再设置同样的ip别名，这里假设别名为10.10.120.193。这样一来，将通过10.10.120.193这个IP别名来访问调度器，你可以将站点的域名指向这个IP别名。

2、将ip别名添加到回环接口lo上

这是为了让实际服务器不要去寻找其他拥有这个IP别名的服务器，在实际服务器中运行：

另外还要防止实际服务器响应来自网络中针对IP别名的ARP广播，为此还要执行：

echo “1” > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo “2” > /proc/sys/net/ipv4/conf/lo/arp_announce

echo “1” > /proc/sys/net/ipv4/conf/all/arp_ignore

echo “1” > /proc/sys/net/ipv4/conf/all/arp_announce

配置完了就可以使用ipvsadm配置LVS-DR集群了

ipvsadm -A -t 10.10.120.193:80 -s rr

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g

-g 就意味着使用直接路由的方式转发数据包

LVS-DR 相较于LVS-NAT的最大优势在于LVS-DR不受调度器宽带的限制，例如假设三台服务器在WAN交换机出口宽带都限制为10Mbps，只要对于连接调度器和两台实际服务器的LAN交换机没有限速，那么，使用LVS-DR理论上可以达到20Mbps的最大出口宽带，因为它的实际服务器的响应数据包可以不经过调度器而直接发往用户端啊，所以它与调度器的出口宽带没有关系，只能自身的有关系。而如果使用LVS-NAT，集群只能最大使用10Mbps的宽带。所以，越是响应数据包远远超过请求数据包的服务，就越应该降低调度器转移请求的开销，也就越能提高整体的扩展能力，最终也就越依赖于WAN出口宽带。

总的来说，LVS-DR适合搭建可扩展的负载均衡系统，不论是Web服务器还是文件服务器，以及视频服务器，它都拥有出色的性能。前提是你必须为实际器购买一系列的合法IP地址。

六、IP隧道(LVS-TUN)

基于IP隧道的请求转发机制：将调度器收到的IP数据包封装在一个新的IP数据包中，转交给实际服务器，然后实际服务器的响应数据包可以直接到达用户端。目前Linux大多支持，可以用LVS来实现，称为LVS-TUN，与LVS-DR不同的是，实际服务器可以和调度器不在同一个WANt网段，调度器通过IP隧道技术来转发请求到实际服务器，所以实际服务器也必须拥有合法的IP地址。

总体来说，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，如何从它们中做出选择，取决于你的网络部署需要，因为LVS-TUN可以将实际服务器根据需要部署在不同的地域，并且根据就近访问的原则来转移请求，所以有类似这种需求的，就应该选择LVS-TUN。