那些云中的负载均衡器——Azure、AWS和NetScaler

时间：2018-01-16 18:29:12 阅读：397 评论：0 收藏：0 [点我收藏+]

标签：集合电源 indent cross htm slice web应用 alt 设置

最近做了一些AWS和Azure的功课，准备把一些基础的东西记录下来。正好前几天讲混合云提到了架构纵向和横向的解耦，于是首先理理负载均衡。言者无罪，必有我师，欢迎拍砖。

对于一个应用的架构来说，如果想把业务从单个节点/服务上解耦，负载均衡就是一个不可或缺的组件。负载均衡是做啥的，用wiki来解释估计好点。

“In computing, load balancing improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives.^[1] Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. Load balancing usually involves dedicated software or hardware, such as a multilayer switch or a Domain Name System server process.”

——https://en.wikipedia.org/wiki/Load_balancing_(computing)

按照描述，负载均衡用来为资源分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。此外，负载均衡其实还可以用来Offload流量，阻断客户端到服务端的直接访问。需要注意的是，客户端可能是一个使用Web浏览器的用户，也有可能是前端的服务器；服务端可能是数据库服务器，也有可能是Web服务器。因此，在之前我和NetScaler Team的同事跟用户聊需求的时候，生造了一个词，叫“全栈负载均衡”，意思是在整个应用架构中，其实不同的位置都会需要负载均衡。而NetScaler的功能使得它能够在不同的位置都能工作。

较早的著名的负载均衡的物理形式，我想是都江堰了吧，哈哈。负载均衡所需要的侦听、规则、流向，基本在这个水利工程上都能体现。分水鱼嘴实现的“分四六，平潦旱”、杩槎实现的动态策略调整、宝瓶口实现的监控和防洪/速率控制、飞沙堰实现的策略流量过滤，哈哈哈。古人真的太牛了，有兴趣可以访问：https://zh.wikipedia.org/wiki/%E9%83%BD%E6%B1%9F%E5%A0%B0 膜拜老祖宗。

常见的负载均衡用法很多，按照架构其实有三个维度吧，如果真画在一张图上，就变成了南北向，东西向和前后向，分别是从架构层到应用层、服务之间的连接、服务使用和服务提供之间的连接。我想大致可以从入站方向和出站方向进行分类，更加便于整理。以网站电商等来说，可能更加关心用户如何访问进来，入站方向可能更为优先。而企业有数据网络传输的需求的时候，往往需要评估如何传输能够获得更加稳定高效以及更低的线路成本。

1、入站方向

1.1、DNS引流负载均衡

常见的入站负载均衡，从客户端开始，由外到里，首先可以使用DNS解析进行。最早使用的估计是DNS round-robin的做法，让不同用户轮流获得不同的DNS解析，访问不同的服务地址。DNS服务本身现在也可以结合很多条件，以按照预设给予客户端符合预期的响应。这部分功能，在Azure被称为“流量管理器”，在AWS被称为“Route53”。实现原理可以参考下图：

技术分享图片

基本上，基于DNS的负载均衡会考虑到地理区域以实现特定用户、优先级以实现自由切换、加权以实现灰度迁移、性能以实现自动调整的各种调整方式。需要注意的是，DNS的记录扩散到最终用户查询的DNS（例如宽带使用的默认运营商DNS）需要时间，因此TTL是需要考虑的参数之一。

从我个人体验来说，Route53的管理粒度和容易程度好一点。而很多ADC厂商也提供类似的方案，例如NetScaler的GSLB，根据健康度调整DNS响应，引导用户在不同站点访问服务。当然，其他厂商也有类似的方案，只是我对Citrix的相对熟悉一点而已。

基于加权、健康度、优先级等方式的流量调节，在流量、四层、七层负载均衡上都有所体现。

1.2、四层负载均衡

对于仅使用IP地址和端口进行负载均衡的，视为四层负载均衡器。四层负载均衡通常只在L4的TCP/UDP协议进行操作，对于四层以上的应用数据并不相关联。

Azure的四层负载均衡使用源IP、源端口、目的IP、目的端口和协议五元组进行哈希，决定一个会话会被传递给负载均衡后面的哪个地址。当会话重新建立时，从客户端访问的源地址或者源端口会出现变化，由此新的会话被分往负载均衡器后面不同的节点。

AWS的四层负载均衡使用基于协议、源 IP 地址、源端口、目标 IP 地址、目标端口和 TCP 序列号的流式哈希算法选择目标。

使用负载均衡器，就能够实现端口转发。例如负载均衡器后的服务器组（称为终结点）可能会运行不同的Web服务，使用不同的端口进行侦听。在负载均衡器上，就可以使用不同地址的默认端口（例如80）转发到后面终节点的非默认端口（81），从而减少不必要的终结点数量。

另外，AWS和Azure都支持为终结点启用可变集合（AWS叫Auto Scaling，Azure叫可用性集）以充分利用负载均衡自动重新配置的特点。在需要的时候，终结点的数量可以随负载或者其他要求进行增加减少，同时所有对终结点的访问由负载均衡器转发给终结点，从而实现了访问和服务的解耦。

更重要的是，云中的负载均衡能够跨越不同的物理服务器放置位置，例如AWS的可用区（Available Zone）和Azure的容错域（使用相同物理电源和物理网络开关）及更新域（使用相同维护计划）（Azure貌似也开始使用区域了？）。这样就可以保证在出现电源、更新、网络设备故障甚至是局部火灾等不可控故障时，整个架构的服务不会受到影响。

负载均衡避免不了一种场景，即用户希望保持相同会话连接到相同终结点上。在四层负载均衡器上，Azure使用源IP、目的IP的二元组，或者源IP、目标IP和端口的三元组，来实现会话粘连（或者叫会话保持、持久连接…）。

在七层负载均衡中，同样也有这个需求。

1.3、七层负载均衡

每次我讲架构session的时候都会来一句，“抛开应用谈架构就是耍流氓”。应用是ITaaS栈中最靠近业务的，自底而上终将为业务服务。因此，越来越多的负载均衡需求从L7提出也就不是一件奇怪的事情了。

Azure用了一张图来说明流量管理器和应用程序网关配合，把不同类型流量分布到不同中节点集群。

技术分享图片

而AWS用了一张图来说明，流量是如何通过不同的侦听器，匹配到不同的策略/规则，通过检测终结点健康，把流转发到可用的终结点的。

技术分享图片

因此，七层负载均衡的工作就非常好理解了。根据我们对应用的定义和需求，以HTTP为例，访问的资源例如URL到达L7负载均衡后，按照预先设置的侦听器，匹配协议和端口，在此基础上，可以根据访问请求的主机名，或者访问请求的路径，进行策略/规则的匹配，转发往后端指定的终结点。

这样，也就实现了URL的内容路由。根据请求的URL不同，使用不同的服务器、服务处理不同的流量。对于电商来说，查询和购买，表现的资源消耗可能是不一样的，这种方式就能够把不同的应用需求导流到不同的应用群集。

对于七层的负载均衡，由于需要精细、效率地控制应用访问，所以会有很多的功能需求。例如，为了减轻终结点不必要的，除了满足业务逻辑之外的计算压力，通常会把一些工作卸载（Offload）到负载均衡上，例如，SSL的卸载，能够让终结点不需要计算验证密钥，并且简化证书的管理；TCP的卸载，能够让负载均衡负责建立连接，并且让多个请求使用一个连接，使得终结点减少建立大量连接消耗的资源。

在七层上同样也有会话保持、会话粘连或者称之持久性的需求。比较常见的做法是使用负载均衡替换的cookie，或者会话数据缓存等，每种方式都有其优缺点，需要综合评估选择。

Azure和AWS都结合负载均衡提供了一些针对DDoS和应用恶意访问的防护。AWS的Shield和WAF能过提供DDoS的防护，并且在WAF上能够实现简单的连接速率控制。Azure的WAF提供了OWASP核心规则集的2.2.9或者3.0的规则，AWS则提供专门的DDoS响应服务。

技术分享图片

我一直认为不应该让应用开发的人来解决架构上的安全需求，在DevOps大行其道的今天，架构人员了解应用，并且为应用提供合适的安全防护，应该是职责之内的本份。所以，学习一下WAF并没有什么坏处。最常见的WAF需求，例如XSS跨站脚本攻击、SQL injection查询注入攻击等等，都是需要被WAF阻挡在应用终结点之外的。至于防爬、限制恶意访问、协议攻击等等，其实都可以通过WAF规则来了解和学习。这部分可以参考Azure的核心规则集：https://docs.microsoft.com/zh-cn/azure/application-gateway/application-gateway-crs-rulegroups-rules

安全的另外一部分是审计。因此Azure和AWS都提供了日志和监控服务。

2、出站方向

相对入站方向，出站方向的负载均衡需求感觉就简单多了。最常被提及的需求莫过于把出站的流量分摊到不同的互联网连接上。对于和入站流量匹配的方式，在四层和七层上分别可以使用源网络地址翻译 SNAT和WebSocket等。同样，都可以使用Azure的网络安全组 NSG或AWS的安全组 SG来进行限制。

更为常见的是对不同的连接线路做策略路由。传统方式可能需要根据目标IP做选路路由，而NetScaler可以把出站规则通过Local DB保存的策略驱动Content Switch来匹配策略路由，从而实现根据来源IP决定选择哪一条线路。这样，就能够同样的服务根据请求来源的不同使用最为优质的线路（例如，相同ISP）进行响应。

SD-WAN也可以视为一种不同的负载均衡，设备将根据线路的质量，例如抖动、时延、丢包等，自动平衡分配流量的去向。同时也提供在线路失效时提供不中断TCP连接的自动切换。

3、其他

简单来说，NetScaler作为专门的ADC，在云中能做以上的全部负载均衡的工作，并且有更多的功能。在Azure的marketplace（https://azuremarketplace.microsoft.com/zh-cn/marketplace/apps/citrix.netscalervpx-120 ）和AWS的marketplace（https://amazonaws-china.com/marketplace/pp/B00AA01BOE?qid=1516073367752 ）中，都能看到以VPX虚机提供的公有云版本。简单的描述如下：