云计算时代-选择适合业务的云负载均衡

随着云计算的普及，越来越多的业务选择上云，云上的业务场景也越来越多样化，如何更好的使用云产品来助力多样化的业务场景，加持自身业务，提升业务整体能力与质量，已成为大家探索关注的重点。

业务上云发展过程中，大家会选择使用负载均衡（ELB）产品来提升业务的高可用性与并发能力，但部分业务在使用云上负载均衡后，发现原本业务中需要长时间保持的连接，隔一段时间就会自动断开，客户端登录页面输入账号密码正确，但却反复跳转到登录页面等。这也许是业务场景与选择的负载均衡器（ELB）类型不匹配导致。

接下来带你详细了解云上负载均衡（ELB）到底有哪些类型，不同的类型有什么区别，不同业务场景又该如何选择。

云上负载均衡（ELB）根据应用的网络层次不同（指OSI参考模型）主要分为两类：

一类是传统型负载均衡，具备较强四层处理能力的同时也具备基础的七层处理能力，支持TCP、UDP、HTTP和HTTPS协议类型的应用，也称之为（4层）负载均衡，即在OSI第四层传输层工作。

另一类是应用型负载均衡，专门面向HTTP、HTTPS应用层负载场景的负载均衡服务，具备较强的应用层流量处理能力，支持基于HTTP或应用程序cookie的会话保持，可以根据URL或域名策略做转发，同时可以监控服务内部故障，也称之为（7层）负载均衡，即在OSI参考模型的第七层应用层工作。

云上4层负载均衡，大部分是基于开源LVS（Linux Virtual Server）服务二次开发实现的，请求通过LVS服务器转发至后端RS（rel server）主机，期间只做请求转发。

LVS有几种工作模式：

DR（直接路由模式）、NAT（路由转发模式）、Tunnel（隧道模式）。

但DR 和 NAT 模式因技术设计的要求 LVS服务器和后端RS需要在同一VLAN网络环境下才能正常接入，跨VLAN的RS无法接入，这导致部署成本过高。Tunnel模式虽可以跨VLAN，但后端RS需要部署ipip模块，配置上较为复杂不易运维。

为了解决上述问题，LVS增加了一个新的转发方式：

Full-NAT 模式

与NAT模式转发方式类似，但相比NAT模式引入了本地IP地址的概念，请求从LVS转发到RS过程中，客户端IP被替换成了LVS的内网IP，内网IP之间可以通过多个交换机跨VLAN通信，RS处理完请求返回时，会将请求发送至LVS的内网IP（无VLAN限制），LVS再将内网IP替换成原客户端IP发送回客户端完成请求，至此解决了夸VLAN通讯的问题。

采用Full-NAT模式，在节约部署成本的同时还极大提高了运维便利性。因此，云上4层负载均衡均采用Full-NAT模式部署。

云上7层负载均衡，大部分是基于开源Nginx服务二次开发实现的，请求会先通过4层LVS服务器转发至Nginx服务器，由Nginx服务器代为与客户端建立三次握手连接，三次握手成功后，Nginx再与后端RS建立连接转发客户端报文。

因为会代为响应客户端请求，并且在HTTPS请求时还可以将域名证书配置在7层LB上，所以7层LB可以有效的降低后端RS的负载，提高后端业务处理能力。

协议限制：

云负载均衡（ELB）仅支持 TCP/UDP（4 层）和HTTP/HTTPS（7 层）这四种协议。

连接限制：

4层负载均衡，支持长连接。一般内部会有全局超时时间设置，以光大云为例，4层LB连接超时时间为300秒。如需长连接，可在系统内配置keepalive超时时间，小于LB默认超时时间即可保持长连接。

7层负载均衡，不支持长连接。7层LB主要应用于HTTP、HTTPS协议类型的Web应用场景，Web应用特点是用户并发访问量大，但单用户请求频率不高，因此7层LB普遍使用短连接模式。

长连接与短连接：

长连接：指业务交互时建立的连接长时间保持不断开，有数据报文发送时复用此连接，当无数据报文发送时，双方发链路检测报文保持连接活跃。

长连接模式，可以省去多次重复的三次握手与四次挥手过程，对于并发连接不多但请求频率较高的业务场景，可以极大提高业务请求的处理效率，节约服务器使用的资源，但如果业务并发连接较多，则会对服务器造成较大的压力。

长连接多用于并发连接不多，但请求频率较高的业务，例如：数据库类业务。

短连接：指在有业务交互时，新建一个连接，当数据报文发送完成后断开连接，下次业务交互再次建立新的连接使用。

短连接模式，存在的连接都是在用连接，在并发较高但请求频率不高的业务场景中，请求结束后及时释放连接避免长时间占用，可以有效的节约服务器资源，但如果业务并发较低，请求频率较高，在每次新建连接时的重复握手与挥手过程，会导致服务器压力过大。

短连接多用于并发连接较多，但请求频率较低的业务，例如：Web网站类业务。

会话（Session）保持限制：

ELB会话保持功能，是负载均衡轮询调度算法中的一项功能，7层LB支持基于应用程序cookie和HTTP cookie的会话保持，4层LB支持基于源IP地址的会话保持。

开启会话保持功能，可以根据配置的会话保持类型，将同一个用户的访问请求分配到相同的后端云服务器上进行处理。在一些特殊业务场景下，要求客户端和服务器之间保持一个会话，客户端与服务器需要经过多次关联会话后才能完成一个业务交互流程，这就需要客户端发起的多个会话都由同一台服务器来处理。

在这类业务使用负载均衡时，多台后端服务器间就需要有会话信息同步机制的业务逻辑，或使用云负载均衡的会话保持功能。

如果既没有会话信息同步机制，又没有配置会话保持，可能出现如下场景问题：客户端输入了正确的用户名和口令，但却反复跳到登录页面；用户输入了正确的验证码，但是总提示验证码错误等。

因为每个会话都需要分配一定的内存，在高并发场景下如果不活跃的会话持续保留，将耗费大量内存，造成内存不足资源浪费，因此会话保持也需要有超时时间限制。以某公司云平台为例，会话保持默认超时时间2小时，在超时时间范围内，会将同一客户端请求转发至后端同一台服务器，如果超时则会重新选择后端服务器。

会话（Session）与连接（Connection）：

在很多时候大家很容易将连接（Connection）与会话（Session）的概念混淆。

下面我们了解下两者的概念与区别：

连接是一个物理的概念，指客户端与服务器间建立的一条网络连接通道，既物理路径。而会话是一个逻辑的概念，它是存在于应用实例中，一个连接可以拥有多个会话也可以没有会话，同一个连接上多个不同的会话之间也不会相互影响。

下面我们用一个生动形象的例子来为大家讲解说明：

小明和小红两个工具人分别要从家出发去图书馆租借一本《云计算》图书来学习（图书分为上下两册），但因图书管有规定，每次只能租借一本图书，所以需要分两次租借学习。

有以下两种情况：

在上面的例子中，小明和小红租借图书的过程可以看做是会话，而出行的路径和方式可以看做是连接。同一个大巴上或同一条路上，小明和小红都可以走（一个连接可以拥有多个会话），小明和小红互相不认识，在大巴车上也没有交集（不同会话之间不会相互影响）。小明和小红，也可以分别选择不同的出行路径去图书馆（一个会话也可以不依赖于某个连接）。

那为什么需要会话保持呢？

我们还以上面例子为例。首先小明和小红看完《云计算》两册图书才算学习完整，那第一次两人租完第一册后，去了另一家图书馆（会话未保持，转发到了另一个服务器），这时就会出现问题，第一册图书不是在这家图书馆租的，无法归还第一册图书（两次会话有关联关系），只有去原来的图书馆（原服务器）才能正常归还图书，租借第二册完成学习。因此要想完成学习任务，就需要会话保持。

现在我们了解了云上ELB的底层实现与相关技术限制，结合综上应用于实践才是关键。

接下来我们来聊下何选择适合自身业务场景的ELB，来更好的助力业务发展。并非只要 Web 网站就必须使用7层LB，还需根据业务场景的特定需求，例如是否需要长连接、会话保持等多种需求因素来选择。

负载均衡类型的步骤大致归纳如下：

1）判断业务是否有长连接需求

2）判断业务场景是否有会话保持需求

实际上，会话保持机制与负载均衡的基本功能是有矛盾的。负载均衡希望将客户端的连接、请求均衡的转发至后端的多台服务器，以达到负载均衡的目的，避免单台服务器负载过高，而会话保持机制却要求将某些关联请求转发至同一台服务器进行处理，这可能导致LB后端服务器负载失衡不均。因此，在实际的部署环境中，我们还需根据具体应用特性与业务实际需要来适当的选择是否开启会话保持。

3）选择负载均衡类型

无长连接需求，使用HTTP/HTTPS提供Web服务的业务场景下，可以使用7层负载均衡（HTTP/HTTPS监听器）提供服务。

有长连接需求的业务场景下，则建议直接选择4层负载均衡（TCP监听器）提供服务。

当业务场景为UDP时，可以选择4层负载均衡（UDP监听器）提供服务。

某公司云平台负载均衡（ELB）支持创建 TCP/UCP/HTTP/HTTPS 这 4 种协议的监听器，可参考以下表格在该公司云上选择适合应用场景的监听器：

负载均衡是业务快速发展的一个必然选择，随着云计算的发展，云上负载均衡的应用也会越来越广泛，越来越频繁。更好的理解云上负载均衡技术原理，对我们业务的使用甚至架构设计都可以起到很好助力。

本篇以负载均衡底层实现逻辑与技术限制角度出发，通过对比举例的方式使大家对云上负载均衡的底层技术与类型选择有了进一步的理解，希望通过本篇的分享，大家可以结合业务场景更好的使用云上负载均衡为业务增彩。