摘要：负载均衡支持对多台ECS进行流量分发，以提升应用系统的服务能力，长期以来都是关键业务系统的入口。淘宝，天猫，阿里云等无不依赖负载均衡产品，双11的流量洪峰也依赖负载均衡的调度和处理能力。

负载均衡SLB简单介绍

下图是负载均衡的简单示意图，用户的访问请求经过SLB实例的一个监听（端口），再被转发到后端的ECS上。SLB实例对应一个IP地址，监听就是实例上IP地址的一个端口，流量调度是基于监听（端口）进行的，ECS是真正处理服务请求的。


负载均衡SLB架构

下图是从流量转发路径来看的负载均衡SLB的架构图，可以称为一个负载均衡SLB的集群，这个集群部署在华东1的两个可用区，每个可用区都部署了LVS集群和Tengine集群，其中LVS集群负责接收所有流量的请求，包括TCP/UDP/HTTP/HTTPS，对于TCP和UDP请求，LVS集群会直接将流量转发到后端ECS，对于HTTP/HTTPS 请求会将流量转发给Tengine集群，再转发到后端ECS上。


负载均衡SLB高可用的四个层次

为了便于理解和说明，可以将负载均衡SLB高可用划分为四个层次，如图上图所示，第1层是应用处理层，即真正处理请求的ECS层。第2层是集群转发层，即在集群转发层面要保证高可用，第3层是跨可用区容灾层，在出现可用区级别的故障时可以切换，第4层是跨地域容灾层，上图未标示。下面分别从这4个层次进行分析和说明。

特别要说明的是，产品设计上SLB会尽可能做到高可用，但如果用户系统没有高可用设计，最终也不可能实现真正的高可用，而且除了负载均衡，还有数据库等的高可用问题，因此产品设计的高可用和用户系统设计高可用必须结合起来。下面4个层次的说明也会分别从产品设计和用户使用两个角度进行分析和解读。

第一层 应用处理层

应用处理层是真正处理用户请求的，一般将应用部署在ECS上。

从产品设计角度看：
应用处理层的高可用主要有下面两点，一是要保证ECS出现故障时能及时屏蔽，避免将流量转发到故障节点从而影响用户访问，SLB产品是通过健康检查功能实现的。二是SLB实例能够添加多台ECS，特别是可以添加不同可用区的ECS，从而避免一个可用区的ECS均不可用时影响用户访问。这两点目前SLB产品都可以做到。

从用户使用角度看：
首先，用户一定要开启并正确配置健康检查。SLB支持TCP/UDP/HTTP/HTTPS 四种协议，其中对TCP协议提供了TCP和HTTP两种健康检查方式，用户可以根据需要选择。对UDP协议，用户可以定义UDP健康检查端口，还可以根据自己定义健康检查请求和返回值来判断健康检查结果。对于HTTP和HTTPS协议，默认使用HTTP健康检查，用户可以定义一个健康检查URL，负载均衡的健康检查模块会通过HTTP HEAD来探测获取状态。
关于健康检查详细信息可以参考健康检查原理说明

其次，用户要考虑到单可用区ECS都不可用的情况，选择多个可用区的ECS添加到负载均衡SLB的实例中。用户可能有疑问，如果一个可用区的ECS不可用了，那这个可用区的负载均衡是不是也会不可用？这个问题在稍后的第三层来说明。

第二层 集群转发层
集群转发层指的是负载转发用户请求的SLB集群，包括LVS 集群和Tengine集群，不管是机器故障还是集群升级，都要保障用户请求尽可能不中断，

从产品设计角度看：
首先，必须避免单点故障，如果采用传统的主备切换模式一方面在切换的时候可能影响用户请求，另一方面主备切换还是依赖单机的处理能力，无法很好的横向扩充，因此，转发层不管是LVS还是Tengine集群都集群部署，并通过上层交换机的ECMP等价路由还实现用户请求到集群多台机器的流量转发。看上面的架构图可能用户有疑问，TENGINE集群是接在LVS集群后面的，上层交换机的ECMP如何起作用呢？其实LVS集群对Tengine集群也是有健康检查机制的，即如果Tengine集群的机器出现异常，LVS健康检查发现后会将这台异常的Tengine机器从集群中摘除。

其次，在集群中机器出现down机等异常时尽可能不影响用户请求。有了集群部署后，集群中的机器出现软硬件故障还是难以避免的，有可能机器彻底不可用了或者有异常了需要通过运维手段将这台机器从集群中移出并维修，这个时候这台机器上的用户请求要尽可能做到不中断。

SLB集群是通过Session同步来实现集群中有机器故障时尽可能不影响用户请求的。如下图所示，当用户的访问请求经过集群中的一台LVS时，集群会根据预设的规则将Session同步到其它LVS机器，从而实现LVS集群所有机器都有该Session，当如下图中的LVS1机器出现故障或需要维护时，用户请求就会通过其它LVS机器进行流量转发并且用户基本不感知。但是有Session同步不代表就解决了所有问题，Session同步能解决大部分长连接的问题，但是对于短链接，连接未建立（三次握手未完成）或者已建立连接但是还没有触发Session同步规则时，机器故障还是可能会影响用户请求。因此，需要用户的系统和程序进行配合。


从用户使用角度看，一定要在代码中加上相应的重试机制！ 这样在上述情况出现时，会进一步降低对用户访问影响。

第三层 跨可用区容灾层
上面说的是在一个可用区内负载均衡转发集群的高可用，跨可用容灾层则要解决的是当一个可用区都不可用时，还能继续使用另外一个可用区的负载均衡继续提供服务。

从产品设计角度看：
还是如看SLB架构图，首先，负载均衡集群要实现跨可用区部署。另外，还需要一种机制能及时发现其中某个可用区，如可用区A都出现了故障然后切换到另外一个可用区B继续服务。从技术上讲，使用了路由探测和路由优先级机制来实现，即可用区A的一段地址（对应一批SLB实例1-N）除了在本可用区的集群上配置外，其实底层还在可用区B的集群上也有这段地址（对应一批SLB实例1-N），只不过在正常情况下，由于可用区A的这段地址路由优先级更高，所以流量都从可用区A的集群进行转发，如果路由探测到整个可用区A不可用（路由不可达）或者可用区A的某段地址不可用（路由不可达），则路由到可用区B的集群进行流量转发。

从用户对产品形态的感知上来说，就是主可用区和备可用区，但实例上的这个主备可用区用户选择后就无法更改了，用户也无法自行切换主备关系。也就是说主备可用区是底层的机制，用户一旦选择无法干预了。暴露主备可用区概念的原因一方面希望用户在使用SLB和其它有可用区属性的产品进行组合的时候，能做到按需组合，如ECS可用区，RDS的主备可用区等。另一方面也是希望用户更多认知到产品在高可用方面的价值。不过在实际使用时，用户往往存在误区，这些误区使我们考虑是不是要关闭备可用区概念，只对用户暴露主可用区，后面再来解释这些误区。

回过头来说跨可用区高可用，其实，最理想的情况是一个可用区的一个SLB实例出现异常（路由不可达）时，系统就能够自动切换或者用户能手动切换到另外一个可用区的SLB实例继续服务。但不能这样做的主要原因是需要发布明细路由，即32位路由，而这在云环境中是无法接受的。


从用户使用角度看：
首先，跨可用区容灾需要保证一个SLB实例的后端服务器ECS分布在多个可用区，即避免一个可用区不可用时，SLB后端的ECS都无法使用从而影响用户访问，这点在第一层 应用处理层中已经说明了。当然，如果还使用DB等产品，还需要考虑DB的跨可用区容灾问题，用户可以参考DB相关产品的说明。这里主要谈负载均衡本身以及和负载均衡紧密相关的后端服务器ECS的高可用问题。

其次，对于重要的业务，一定要使用至少两个且主可用区不一样的实例来容灾，这点非常重要。如重要的用户注册系统，如下图所示，在华东1的可用区A和可用区B分布部署一个SLB实例，都挂载了两个可用区的相同ECS。


用户可能会有两个疑问，一是负载均衡SLB产品本身有跨可用区切换能力，为什么注册系统还需要自己在两个可用区建立两个实例进行跨可用区容灾呢？负载均衡SLB产品本身的跨可用区切换是在非常极端的情况下（整个可用区不可用/所有LVS集群上的IP无法路由/某个地址段都无法路由）才切换，而对于比如仅一个可用区的Tengine有部分异常、LVS集群有异常但是IP还可以Ping通等相对不那么极端又会影响用户业务的情况下是不起作用的，因此，重要的业务系统非常有必要用户自己在两个可用区建立实例容灾。

二是注册系统使用的两个SLB实例如何调度，用户可以使用云解析将注册系统的域名解析到上面的两个SLB实例，其它的相关域名解析系统也都支持这样的功能。如果是私网SLB实例，阿里云正在研发私网DNS系统，当前用户可以自己构建一个私网DNS系统或者通过程序来实现调度。

再次强调一下重要业务系统用户自行在两个可用区建立实例容灾的必要性。哪怕正常情况下有一个实例就配置好不使用，虽然需要支付每小时2分钱的公网IP费用，但当出现其中一个实例所在集群异常并且恢复时间较长时，用户也可以自行通过修改DNS解析或者程序调用地址来快速恢复业务。

最后，再来说下用户对于主备可用区可能存在的误区
1) 认为主备可用区就是只要一个实例有异常了负载均衡就能自动切换到备可用区
2) 认为主备可用区切换的异常包括个别实例无法Ping、实例上的服务异常等等很多条件
其实，负载均衡主备可用区切换设计是在极端情况下（整个可用区不可用/所有LVS集群上的IP无法路由/某个地址段都无法路由）才会自动进行的，它既不是某个IP地址无法路由就切换，也不是某个或者某些IP地址可以Ping但这些IP的服务异常就切换。因此，用户系统通过自身在多个可用区建立实例实现跨可用区灾是非常必要的。

第四层 跨地域容灾层
最后来说下跨地域容灾层。随着业务的发展，用户对业务系统的高可用要求越来越高，已经不满足于只能做到跨可用区的容灾，用户希望即使某个地域的系统都不可用了，还可用通过其它地域的系统继续提供服务，这就是跨地域容灾。

跨地域容灾是个非常大的课题，不仅仅涉及到网络层面，更涉及到应用系统的改造和适配，数据的同步和一致性等很棘手的问题。这里仅说明下网络层面的跨地域容灾。从产品角度看，跨可用区容灾一般是通过DNS来实现的，如下图所示

传统的如F5的全局负载均衡（以前叫GTM，现在叫BIG-IP DNS）就有比较完善的解决方案，或者一些提供DNS服务的系统也有类似的功能。负载均衡SLB产品本身没有提供这样的能力，跨地域容灾的能力是通过云解析DNS产品来实现的，云解析DNS产品提供了全局负载均衡的能力，还有如健康检查，路由调度优化等功能，可以参考 全球负载均衡跨地域容灾解决方案

另外，对于跨可用区容灾可能需要使用在不同地域间同步数据或者跨地域私网调用，可以使用高速通道产品构建不同地域的通信链路
从用户角度看，跨可用区容灾网络层面主要通过云解析DNS产品，对于不同地域间通信可以使用高速通道产品，这两个产品不是本文的重点，可以查看阿里云官网的相关产品文档说明。
 
 

作者：云栖社区