目录
概述
传统负载均衡器（Classic Load Balancer）
DNS解析
健康检查（Health Check)
监听器（Listeners）
连接耗尽（Connection Draining）
粘性会话/会话关联（Sticky Sessions/Session Affinity）
应用程序负载均衡器（Application Load Balancer）
网络负载均衡器（Network Load Balancer）
弹性伸缩（Auto Scaling）
启动配置（Launch Configuration）
弹性伸缩组（Auto Scaling Group）
扩展选项
默认的实例终止策略
EC2置放群组（Placement Group）
Placement Group的特点
使用Placement Group的最佳实践
应用场景
概述
ELB
我们在AWS控制台创建负载均衡器类型时，会发现有三个选项可以选择，分别是应用负载均衡器（ALB），网络负载均衡器（NLB），经典负载均衡器（CLB）。
弹性负载均衡器（Elastic Load Balancer）。Amazon 将 ELB 分成三种不同类型
1、ALB
应用程序负载均衡器（Application Load Balancer）
应用程序级别（第 7 层）
支持基于内容的路由和在容器中运行的应用程序。
2、NLB
网络负载均衡器（Network Load Balancer）
在连接级别运行（第 4 层）
适合实现传输控制协议 (TCP) 流量负载均衡，且能够在每秒处理数百万请求的同时保持超低延迟。
3、CLB
经典负载均衡器（Classic Load Balancer）
CLB是AWS的上一代负载均衡器，支持TCP、SSL/TLS、HTTP、HTTPS协议，是AWS的三种负载均衡器支持协议最多的。
在应用程序级别（第 7 层）和连接级别（第 4 层）运行
非常适合内置于 Amazon EC2-Classic 网络的应用程序。
传统负载均衡器（Classic Load Balancer）
- Class Load Balancer可以将入向流量自动分布到多个健康的EC2实例上
- ELB是最终用户的唯一接触点
- ELB本身就是一个绝对高可用，永不宕机的分布式软件，用户不需要考虑ELB的高可用性，不需要为其设计高可用的架构设计。而且ELB不是单点故障
- ELB具有弹性，能自动对自身进行性能的提升，即可以理解为ELB能处理无穷无尽的数据请求
- 但ELB的弹性不是立马生效的，如果应用程序在某个时间点有爆发性的流量发生（比方说淘宝双11），那么ELB是不会马上进行扩容的，扩容的过程需要一定的时间（1到7分钟）
- 如果有可预料的爆发性流量要发生（或者需要进行压力测试），那么可以联系AWS技术支持，告诉AWS流量预计发生的开始和结束时间、预计的每秒请求数、总请求数。AWS可以对该ELB进行预热（pre-warm）从而提前达到能处理这些流量的性能大小
- ELB是阻挡来自网络攻击的第一道防线（比如DDoS攻击）
- 你不需要为ELB打补丁，或管理和维护它的操作系统
- 能分担加密和解密的工作，从而减少EC2实例的系统负担
- 能和AWS弹性伸缩（Auto Scaling）集成，从而能保证后台运行的EC2实例能满足流量的需求
- 默认情况下，ELB的流量转发规则是 TCP 侦听器使用轮询路由（Round Robin）算法，对 HTTP 和 HTTPS 侦听器使用最少未完成请求路由算法。
- ELB只在一个特定的AWS区域中工作，不能跨区域（Region），但可以跨可用区（AZs）
- 基于ELB在所处应用架构中的位置不同，可以分两个类型ELB
- Internet Load Balancer – 是面向公网的负载均衡器，能接受来自Internet用户的连接请求
- Internal Load Balancer – 是面向AWS私有网段的负载均衡器，一般仅服务于AWS内部的资源。典型的使用案例是放置在前端服务器和后端服务器之间
DNS解析
- ELB会以DNS (Domain Name System)的形式显示在AWS管理控制台，并且会动态解析不同公网IP地址，我们在使用ELB时要尽量用DNS来对它进行访问，而不是IP地址
- 在ELB进行弹性扩容的时候，它的DNS记录会被更新，DNS会解析到新的IP地址上（因此这也是上面所说的我们要尽量用DNS名来访问ELB）
- DNS记录的TTL时间是60秒
- 建议客户端（程序）每60秒更新DNS查找记录，以获取最新的ELB地址和最好的ELB性能
健康检查（Health Check)
ELB在每一个健康检查间隔（HealthCheck Interval）都会向所有已注册的实例发送基于Ping、端口或者（网页）路径的检查数据包，并且在响应超时（Response Timeout）这个时间内等待实例的回复。如果连续没有得到回复的次数超过定义的不健康阈值（Unhealthy Threshold），那么这个实例会被标记为OutofService。如果在连续得到实例回复的次数超过了健康阈值（Healthy Threshold）的话，那么这个实例会被重新标记为Inservice状态。
- ELB会对所有注册到这个ELB上的EC2实例进行健康检查，无论目前的健康状态如何
- ELB的监控状态分别为InService（表示健康）或者OutofService（表示不健康）
监听器（Listeners）
- Listeners可以用来监听用户对ELB发起的请求，以及ELB和后台EC2实例之间的请求
- Listeners可以定义监听的协议和端口
- Listeners支持HTTP, HTTPS, SSL, TCP协议
连接耗尽（Connection Draining）
默认情况下，一个已注册再ELB的EC2实例取消了注册或者进入OutofService状态，那么ELB会马上切断这个实例正在进行的连接。
为了保证Classic Load Balancer中当有实例变成不健康的状态（OutofService）或者正在取消注册，而该实例上已经建立的连接不受影响， 请启用Connection Draining功能。它能保证该不健康的实例在处理完所有已有的连接请求之后，才真正地从ELB内去除，接着ELB不会再转发请求给这个实例。
Connection Draining的可设置时间限制范围是1~3600秒（默认为300秒）。当达到这个最大时限时，不管当前实例是否处理完请求，ELB都会强制关闭与这个实例的连接。
粘性会话/会话关联（Sticky Sessions/Session Affinity）
默认情况下，Classic Load Balancer会将每一个用户请求转发到负载最小的已注册实例上。但是如果启用Sticky Sessions /Session Affinity，则在会话期间ELB会将来自某个用户的所有请求都转发到同一个实例上。
应用程序负载均衡器（Application Load Balancer）
应用程序负载均衡器（Application Load Balancer）工作在7层（应用层），因此也被称为7层的ELB。
在应用程序负载均衡器中，引入了规则这个概念。ELB在收到请求之后，会按照优先顺序评估侦听器的规则，然后根据定义的规则将流量转发到特定的目标组中。如下图所示，你可以配置不同的侦听器规则，然后根据流量的内容或者URL路径来将不同的请求转发到不同的目标组内，而一个目标组又包含了若干的目标（EC2实例)。
应用程序负载均衡器在其他方面和上文讲的传统负载均衡器非常类似，那他们有什么大的区别呢？
- Application Load Balancer可以进行基于路径的路由。即可以根据用户请求中的URL字段不同来将请求发送到不同的目标组中。比方可以定义ELB，将访问https://iteablue.com/posts/*文章的流量转发到目标组1中，然后将访问https://iteablue.com/pages/*页面的流量转发到目标组2中，那么就可以把原本的一个网页应用程序分解成更小的服务单元
- ALB可以侦听HTTP数据包头部的信息，根据此字段来定义规则
- ALB支持通过IP地址进行目标注册，包括位于VPC之外的目标。即可以在一个ALB中定义4个AWS中的EC2实例，同时定义2个来自公司内网的物理服务器
- 支持容器化的应用程序
网络负载均衡器（Network Load Balancer）
网络负载均衡器（Network Load Balancer）工作在4层（传输层），因此也被称为4层的ELB。
- NLB可以基于协议、源 IP 地址、源端口、目标 IP 地址、目标端口和 TCP 序列号，使用流式哈希算法选择目标。
- NLB可以每秒处理数百万个请求
- 支持静态IP地址用于负载均衡器
- 同ALB一样，NLB支持通过IP地址进行目标注册，包括位于VPC之外的目标
- 支持容器化的应用程序
弹性伸缩（Auto Scaling）
亚马逊弹性伸缩（Auto Scaling）能自动地增加/减少EC2实例的数量，从而让你的应用程序一直能保持可用的状态。
你可以预定义Auto Scaling，使其在需求高峰期自动增加EC2实例，而在需求低谷自动减少EC2实例。这样不仅能让你的应用程序一直保持健康的状态，而且也节省了你为EC2实例所付出的费用。
Auto Scaling 适用于那些需求稳定的应用程序，同时也适用于在每小时、每天、甚至每周都有需求变化的应用程序。
- Auto Scaling能保证你一直拥有一定数量的EC2实例来分担应用程序的负载
- Auto Scaling能带来更高的容错性、更好的可用性和更高的性价比
- 你可以控制伸缩的策略来决定在什么时候终止和创建EC2实例，以处理动态变化的需求
- 默认情况下，Auto Scaling能控制每一个可用区内所运行的实例数量尽量平均
- 为了达到这个目标，Auto Scaling在需要启动新实例的时候，会选择一个目前拥有运行实例最少的可用区
Auto Scaling的构成组件：
启动配置（Launch Configuration）
- 启动配置是弹性伸缩组用来启动EC2实例的时候所使用的模板
- 启动配置包含了镜像文件（AMI），实例类型、密钥对、安全组和挂载的存储设备
- 一个启动配置可以关联多个Auto Scaling组
- 启动配置一经创建不能被更改，只能删除重建
- 启动配置中可以使用CloudWatch的基础监控（Basic Monitoring）或者详细监控（Detail Monitoring）
- Auto Scaling automatically creates a launch configuration directly from an EC2 instance.
弹性伸缩组（Auto Scaling Group）
- 弹性伸缩组（ASG）是弹性伸缩的核心，它包含了多个拥有类似配置/类型的EC2实例，这些实例被逻辑上认为是一样的
- 弹性伸缩组需要的几个参数：
- 启动配置（Launch Configuration）：它决定了EC2使用什么模板，模板内容包括了镜像文件（AMI），实例类型、密钥对、安全组和挂载的存储设备
- 最小和最大的性能：决定了在弹性伸缩的情况下，EC2实例数量的浮动范围
- 所需的性能：决定了这个弹性伸缩组要保持的运作所需要的基本的EC2实例数量；如果没有填写，则默认为其数值等同于最小的性能
- 可用区和子网：定义EC2实例启动时候所在的可用区和子网信息
- 参数和健康检查：参数定义了何时启动新实例，何时终止旧实例；健康检查决定了实例的健康状态。
- 如果一个EC2实例的健康状态变成“不健康”，那么ASG会终止这个EC2实例，并且自动启动一个新的EC2实例
- 弹性伸缩组（ASG）只能在某一个AWS区域内运行，不能跨越多个区域
- 如果启动配置（Launch Configuration）有更新，那么之后启动的新EC2实例会使用新的启动配置，而旧的EC2实例不受影响
- 从AWS管理平台你可以直接删除一个弹性伸缩组（ASG）；从AWS CLI你只能先将最小的性能和需求的性能两个参数设置为0，才能删除这个弹性伸缩组。
扩展选项
- 始终保持当前实例级别：比如始终保持一个ASG有恒定的3个健康实例
- 手动扩展：手动更改参数最大容量、最小容量或者所需容量来控制ASG内实例的数量
- 按计划扩展：根据定义的具体时间来弹性扩展实例的数量
- 根据需求进行扩展：结合CloudWatch来基于参数进行扩展（比如说当CPU利用率持续10分钟在70%以上就自动进行向上扩展，即增加EC2实例数量；而当CPU利用率持续10分钟在30%以下就自动进行向下扩展，即减少EC2实例数量）
扩展阅读：更多关于扩展选项的内容可以查看扩展 Auto Scaling 组的大小
默认的实例终止策略
如果你的Auto Scaling Group中包含了分布在不同可用区的实例时，当涉及到需要终止实例的情况下，Auto Scaling Group会按照以下顺序的规律终止实例。
- 选择哪一个可用区？
- 选择当前最多实例并且至少有一个实例不受缩小保护的可用区
- 如果以上的可用区存在多个，则选择使用最旧的启动配置的实例所在的可用区
- 选择哪一个实例？
- 选择一个使用最旧启动配置并且不受保护的实例，如果有多个，则
- 选择一个不受保护的，最接近下一个计费小时的实例，如果还有多个，则
- 随机终止一个实例
注意：弹性伸缩（Auto Scaling）可以和弹性负载均衡（Elastic Load Balancing）一起配合使用，这样能保证通过一个DNS地址对外提供服务，而后台能一直保证有一定数量的健康EC2实例处理相应的负载。
EC2置放群组（Placement Group）
EC2 置放群组（Placement Group）逻辑性地把一些实例放置在一个组里面，在这个组里面的实例能享受低延迟、高网络吞吐的网络。
Placement Group的特点
- EC2 Placement Group分为集群置放群组（Cluster Placement Group）、分布置放群组（Spread Placement Group）和分区置放群组（Partition Placement Group）
- 集群置放群组（Cluster Placement Group）即传统的置放群组，所有的实例需要在同一个可用区内
- 分布置放群组（Spread Placement Group）是将实例分布到不同的底层硬件，可以在不同的可用区内。你最多可以在每一个置放群组的每一个可用区内创建7个实例
- 分区置放群组（Partition Placement Group）确保了置放群组中的每个分区具有自己的一组机架，每个机架具有自己的网络和电源
- Placement Group提供了低延迟，高速率的网络，可提供高达10 Gbps的速度
- EC2 Placement Group的命名需要在你的AWS账户内唯一，不能有命名重复
- 只有特定的EC2实例类型可以放在配置Placement Group内（某些计算优化型、GPU、内存优化型和存储优化型的实例）
- AWS建议在一个Placement Group内的所有EC2实例是一模一样的，否则会有短板效应
- 不可以合并多个EC2 Placement Group
- 不可以将一个正在运行的EC2实例放到一个EC2 Placement Group中；只能为这个EC2实例创建一个AMI，然后基于AMI创建一个新的实例并且加入到Placement Group内
- Placement Group可以跨越peerd VPC，但要保证在同一个可用区内
- 如果在Placement Group中创建实例的时候出现“capacity error”的错误，可以停止再启动组中的所有实例，再重新创建刚才的实例
- 停止再启动组中的所有实例可以改变这些实例所在的底层物理设备，从而带来更多的性能和空间启动新的实例
- Placement Group的创建会告诉AWS将组里的实例安置在物理上接近的AWS设备内
使用Placement Group的最佳实践
- 组内使用一样类型的EC2实例
- 在同一时间启动组内所有EC2实例，这样可以减少出现“capacity error”错误的概率
- 可以通过更改最大传输单元（MTU），从默认的1500改成9001来进一步增加Placement Group内实例之间的传输速度
应用场景
经典负载均衡器（Classic Load Balancer）
AWS第一代负载均衡器，支持4层协议（TCP/UDP）和7层协议(HTTP/HTTPS)。
优势：价格便宜，容易上手
劣势：效果没有NLB/ALB好
应用程序负载均衡器（Application Load Balancer）
ALB的名字为应用程序负载均衡器，支持7层协议（HTTP/HTTPS/WebSocket），不支持4层协议（TCP/UDP）。
优势：支持基于Host和Path的转发；支持粘性会话；性能比CLB好；支持按比例的流量转发；可编辑安全组
负载均衡算法：默认算法为轮询算法,还可以使用最少未完成请求算法
网络负载均衡器（Application Load Balancer）
NLB的名字为网络负载均衡器，支持4层协议（TCP/UDP）。
优势：性能最好，每秒支持百万次请求，不需要预热（ALB和CLB流量大的话需要预热扩充负债均衡服务节点）；NLB的ip地址不会改变（CLB和ALB会随着时间改变，另外NLB可以分配固定弹性ip，ALB不能）
负载均衡算法：默认算法为哈希算法
ALB和NLB选择和区别
当客户的业务基于HTTP/HTTPS/Websocket时候，优先考虑使用ALB。
NLB可以处理7层的流量，但NLB不解析7层的协议，不会对协议进行处理。
如果选择了ALB，则处理不了4层的流量，主要取决于选择的负载均衡器类型。
参考：
AWS学习笔记（四） ELB CLB ALB NLB AS PG – IT Lab Service – Bing哥的博客
AWS ALB NLB CLB负载均衡器_打牛地的博客-CSDN博客_aws nlb
