那些云中的负载均衡器——Azure、AWS和NetScaler
最近做了一些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. 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虚机提供的公有云版本。简单的描述如下：
当然，云中用作负载均衡的方法和厂商很多，例如Apache、Nginx以及F5等其他产品，限于个人了解的深度和广度，无法一一列举。
之所以想起写下这些学习过程中接触到的东西，下面这张图也是原因之一。我们处在一个将各种资源和服务解耦以实现更高利用和更灵活组合的时代。看看Azure和AWS提供的各种服务，用户也许只需要连接不同的组件，就能够实现以前复杂架构所提供的资源能力。负载均衡作为横向解耦的重要手段，必然在架构中越来越重要。
同时，容器和Serverless的未来，服务乃至微服务之间的东西向解耦连接，也对负载均衡提出了新的要求。我猜Nginx应该也有容器版本了吧，而NetScaler也已经有了容器版本CPX。
未来的检测、管理、策略什么的，也会渐渐引入机器学习和AI吧。
对Azure和AWS负载均衡相关的比较关键信息引用如下：
Azure 负载均衡器比较
AWS Elastic Load Balancing 比较
参考：
负载均衡Wiki：https://en.wikipedia.org/wiki/Load_balancing_(computing)
Azure-流量管理器：https://docs.microsoft.com/zh-cn/azure/traffic-manager/traffic-manager-overview
AWS-Route53：https://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/Welcome.html
Azure-Azure负载均衡器：https://docs.microsoft.com/zh-cn/azure/load-balancer/load-balancer-overview
AWS-网络负载均衡器：https://docs.aws.amazon.com/zh_cn/elasticloadbalancing/latest/network/introduction.html
Azure-应用程序网关：https://docs.microsoft.com/zh-cn/azure/application-gateway/application-gateway-introduction
AWS-应用程序负载均衡器：https://docs.aws.amazon.com/zh_cn/elasticloadbalancing/latest/application/introduction.html
Azure-Web应用程序防火墙：https://docs.microsoft.com/zh-cn/azure/application-gateway/application-gateway-web-application-firewall-overview
AWS-AWS WAF和AWS Shield：https://docs.aws.amazon.com/zh_cn/waf/latest/developerguide/what-is-aws-waf.html
一篇非常好的blog：https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236
页:
[1]