一、前言
根据AWS网站的文章《Elastic Load Balancing Product Details》介绍，现在AWS支持三种负载均衡服务，分别是：
- Application Load Balancer
- Network Load Balancer
- Classic Load Balancer
CLB是最早的产品，而NLB和ALB都是从CLB衍生出来的。
转载自https://blog.csdn.net/cloudvtech
二、不同负载均分服务的分析
下图可以看到不同类型的LB的功能列表：
可以看到APL由于是七层负载均衡服务所有功能最为丰富，而NLB是四层负载均衡服务，CLB是同时支持四层和七层负载均衡的。但是相对而言ALB和NLB都支持更多最新的负载均衡的功能，所以AWS也是建议尽量使用或者从CLB迁移到ALB或者NLB。
转载自https://blog.csdn.net/cloudvtech
三、关于NLB的一些技术点
在2017年的KubeCon/CloudNativeCon上HBO分享了他们使用AWS EC2服务构建Kubernetes集群对外提供冰与火之歌视频服务，他们使用的应该就是AWS的负载均衡服务，这个keynote《Keynote: Pushing the Limits of Kubernetes with Game of Thrones - Zihao Yu & Illya Chekrygin, HBO》展示了他们面临的一些数据面的挑战，而文章《Why HBO Chose Kubernetes to Help Stream Game of Thrones》也对这个keynote进行了分析。
最近由于项目的需要，和AWS NLB的技术人员进行了一些交流，了解了NLB一些相关的功能和能力：
1. NLB是基于NAT模式的LB，数据的进出都会经过NLB，但是猜测应该使用了基于类似DPDK等的数据面加速技术来保证效率；未来可能会推出基于LVS-DR模式的负载均衡服务。
2. 新建的NLB的初始能力为5Gbps per zone，但是随着流量的增加，NLB可以自行提升自己的能力，AWS给出的单个NLB的最大吞吐量在20~30Gbps。
3. 随着流量增加，NLB需要每20~30分钟才能double它的处理能力。
4.如果有特殊event，可以预先和AWS support(IEM)联系对NLB做pre-warmup，保证在event开始的时候NLB达到所需要的能力。
5.NLB是基于源IP进行负载均衡的，没有基于权重等的流量分配算法，NLB也无法感知一个AWS EC2虚拟机上kubernetes的数目来选择POD作为负载均衡的后端。
6.kubernetes的对于NLB的支持已经有一个alpha版本的功能可以使用，这个功能可以定义AWS NLB类型的external loadbalance service。
7. 在一个zone里面每个NLB支持的后端EC2的数据是有限的，在200个左右(未来新的版本可能可以到1000)。
8. 对于500+Gbps的流量，一般需要分割成多个NLB负载均衡域进行部署，多个NLB可以被注册到同一个route53服务中的一个域名，之后会现在DNS这边进行基于NLB的DNS负载均衡。
9. 可以定于阈值来告诉NLB在某个metric到达这个阈值的时候开始进行能力扩展。
10. NLB只支持本NLB能力的扩展，并不支持通过自动建立多个NLB来进行能力扩展。
转载自https://blog.csdn.net/cloudvtech