DNS、硬件、LVS、Nginx 该如何搭配？

1、为什么要负载均衡？

系统的扩展可分为纵向（垂直）扩展和横向（水平）扩展。纵向扩展，是从单机的角度通过增加硬件处理能力，比如 CPU 处理能力，内存容量，磁盘等方面，实现服务器处理能力的提升，不能满足大型分布式系统（网站），大流量，高并发，海量数据的问题。因此需要采用横向扩展的方式，通过添加机器来满足大型网站服务的处理能力。比如：一台机器不能满足，则增加两台或者多台机器，共同承担访问压力。这就是典型的集群和负载均衡架构，如下图：

应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理，并返回相应数据。

负载均衡设备：将用户访问的请求，根据负载均衡算法，分发到集群中的一台处理服务器（一种把网络请求分散到一个服务器集群中的可用服务器上去的设备）。

负载均衡的作用（解决的问题）：

1、解决并发压力，提高吞吐量。

2、提供故障转移，检测下游服务器状态，实现高可用。

3、利于横向扩展服务器。

4、安全防护，负载均衡设备上做一些过滤，黑白名单等处理。

2、负载均衡种类

2.1 DNS 负载均衡

最早的负载均衡技术，利用域名解析实现负载均衡，在 DNS 服务器，配置多个 A 记录，这些 A 记录对应的服务器构成集群。大型网站总是部分使用 DNS 解析，作为第一级负载均衡。如下图：

优点

1、使用简单：负载均衡工作，交给 DNS 服务器处理，省掉了负载均衡服务器维护的麻烦。

2、提高性能：可以支持基于地址的域名解析，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能。

缺点

1、可用性差：DNS 解析是多级解析，新增/修改 DNS 后，解析时间较长；解析过程中，用户访问网站将失败。

2、扩展性低：DNS 负载均衡的控制权在域名商那里，无法对其做更多的改善和扩展。

3、维护性差：也不能反映服务器的当前运行状态；支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）。

4、更新不及时：DNS 缓存可能会保留较长时间。

实践建议

将 DNS 作为第一级负载均衡，A 记录对应着内部负载均衡的 IP 地址，通过内部负载均衡将请求分发到真实的 Web 服务器上。

2.2 硬件负载均衡

硬件负载均衡通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似。

目前业界典型的硬件负载均衡设备有两款： F5 和 A10 。性能强劲、功能强大，但价格都很昂贵。

优点

1、功能强大：全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。

2、性能强大：对比一下，软件负载均衡支持到 10 万级并发已经很厉害了，硬件负载均衡可以支持 100 万以上的并发。

3、稳定性高：商用硬件负载均衡，经过了良好的严格测试，经过大规模使用，稳定性高。

4、支持安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙、防 DDoS 攻击等安全功能。

缺点

1、价格昂贵：最普通的一台 F5 十多万，好一点近百万元。

2、扩展能力差：硬件设备，可以根据业务进行配置，但无法进行扩展和定制。

实践建议

可以在 DNS 作地理级别负载均衡的情况下，在其下级使用 F5 或 A10 作为低级的负载均衡器，之后将流量转发到下级集群，如下图所示。

2.3 软件负载均衡

软件负载均衡，可以在普通的服务器上运行负载均衡软件，实现负载均衡功能。目前常见的有 Nginx、HAproxy、LVS，其中的区别：

• Nginx：七层（OSI 网络七层模型，第七层应用层）负载均衡，支持 HTTP、E-mail 协议，同时也支持四层负载均衡；

• HAproxy：支持七层规则的，性能也很不错。OpenStack 默认使用的负载均衡软件就是 HAproxy；

• LVS：运行在内核态，性能是软件负载均衡中最高的，严格来说工作在第三层网络层，所以更通用一些，适用各种应用服务。

优点

1、易操作：无论是部署还是维护都相对比较简单。

2、便宜：只需要服务器的成本，软件是免费的

3、灵活：4 层和 7 层负载均衡可以根据业务特点进行选择，方便进行扩展和定制功能。

与硬件负载均衡相比的缺点

1、性能一般，一个 Nginx 大约能支撑 5 万并发。

2、功能没有硬件负载均衡那么强大。

3、一般不具备防火墙和防 DDoS 攻击等安全功能。

3、LVS：专注网络更底层，性能更卓越

前面介绍了负载均衡的种类后，可以看到重点应该在软件负载均衡。Nginx 大家都应该有所耳闻，工作在应用层，配置方便，所有的流量（相应、请求报文）都会经过代理服务器 Nginx，但如果流量较大，势必为成为系统的瓶颈，而工作在传输层和网络层的 LVS 负载均衡器具有更强的负载均衡能力。概括的来说，它能在网络层就实现路由重定向，之后响应报文会直接通过真实服务器发送给原始的客户端，不走 LVS，大大降低了流量；但需要在代理服务器和真实服务器上进行复杂的配置，而且不会有错误检测和重发。

4、DNS+硬件+LVS+Nginx 多级负载均衡

前面咱们提到 DNS 负载均衡的时候就引出了多级负载均衡的概念，LVS 像是在硬件负载均衡器和 Nginx 之间的一种折中的解决方案，由此可以形成一种 DNS —> F5/A10 —> LVS —> Nginx

的负载均衡架构体系了（具体系统具体分析，可以取消任意一层），很像计算机网络的网络层+数据链路层多级架构的模式。

LVS + 多 Nginx 的使用中，既可以避免 LVS 故障检测的短板，又能避免 Nginx 性能瓶颈问题。同时 nginx 还可以作为一个中间环节来减小后端 tomcat 的服务压力，以及做一些业务切换、分流、前置缓存的功能。

5、负载均衡器高可用集群

单点 LVS 或 Nginx 仍然可能存在单点故障（可能概率极小），可以根据业务的关键程度，构建负载均衡器集群，LVS 自身有双机热备机制（主备架构），Nginx 需要额外编写软件来实现主备或主从架构。

6、到底要不要负载均衡？

前面谈论了这么多的负载均衡方案，为什么又回到了第一个问题，做不做负载均衡？或者说，横向扩展真的有必要么？这确实是一个相对的问题，如果只是常规的中小应用，qps 根本达不到单机 Nginx 的峰值 5W (可以参考 20W 用户的应用 qps 只有十几），即使是大型应用，也得分应用类型，并不是每个应用都要设计成秒杀系统，横向扩展了之后意味着需要投入成倍的管理成本。总之，可以先优化算法，分析系统瓶颈，重构单机应用代码，软件实在无法扩展了之后再考虑扩展硬件，而且现在处于云计算时代，弹性云服务器是很方便进行硬件扩展的，最后的最后，再考虑集群架构。切记，不要一味地为了高吞吐量而采用直接集群、分布式，技术架构要跟着业务能力跑。如果只是个人博客网站，做负载均衡可能只是感动自己。

如若转载，请注明出处：开源字节   https://sourcebyte.vip/article/273.html