下文，以软负载均衡（反向代理）方案为背景，讨论负载均衡。
负载均衡特点：
负载均衡：暴露给用户的IP只有一个，如果后端机器故障，进行下线修复后再上线这一过程，前端用户感觉不到，并且可以根据后端机器的性能差异，调整流量分配权重，科学的分配访问量。
负载均衡的以上特点，大大提高了应用程序容错能力。
开源负载均衡nginx、HAProxy 等方案，最大连接数一般有数万。需要技术人员预估资源，在业务旺季，进行扩容，保证可用性。
开源方案的灵活性同时也带来了复杂性，这些方案不像专业云平台有统一标准，需要技术人员首先搭建一个基本可用的系统，然后监视业务运行状态，自己总结实践经验，自己优化改进。
开源方案，需要技术人员自己搭建安全防护方案，这需要学习安全防御技术。成熟的云平台阿里云、腾讯云都已提供可靠的安全防护服务。
负载均衡的层次，TCP 协议和 UDP 协议；HTTP 协议和 HTTPS协议；
负载均衡监听器，可以监听负载均衡实例上的四层请求（即OSI网络协议模型第四层传输层），并将这些请求分发至后端服务器进行处理。四层转发能力需要在具体软件的配置文件，进行配置。
负载均衡端口：负载均衡器对外或对内提供服务时，接收请求的前端端口。用户可以为下列 TCP 端口执行负载均衡：21（FTP）、25（SMTP）、80（Http）、443（Https），以及 1024-65535等端口。
后端服务器端口：后端服务器接受负载均衡分发流量的端口。在同一个负载均衡中，一个负载均衡端口可以对应多个后端服务器端口。
负载均衡运行监管，需要自己实现健康检查，实时识别后端服务器的运行状况，自动隔离异常的服务器，保证应用程序的可用性。
腾讯云的四层转发的健康检查机制是，由负载均衡器向配置中指定的服务器端口发起访问请求，如果端口访问正常则视为后端服务器运行正常，否则视为后端服务器运行异常。对于TCP的业务，使用SYN包进行探测。对于UDP业务，使用ping进行检查。技术人员自己实现的方案，可以参考腾讯云的思想。
- 响应超时时间： 2-60 秒
- 检查间隔： 5-300 秒
- 不健康阀值：2-10 次 （健康后端服务器出现此指定次数响应超时后，视为不健康）
- 健康阀值：2-10 次（不健康后端服务器出现此指定次数响应超时后，视为健康）
可参照腾讯云的健康阀值设置，实现自己的负载均衡检查。
负载流量分配
腾讯云四层转发能力，使用加权轮询的分流方式，流量经负载均衡器后按权重比例分配到不同后端服务器上。后端服务器的权重默认为10，可设置0-100范围内的整数。自建负载均衡，也可以参照该实现方法的思想，自己实现负载分配方案。
注意下流量分配的细节
- 当后端服务器权重配置为0时，负载均衡实例将不再往该服务器转发流量
- 负载均衡实例向后端服务器转发的流量，将按实际配置的权重比例计算。例如：一个负载均衡实例绑定了2台后端服务器，若A服务器配置权重为40，B服务器配置权重为60，则两台服务器的流量接收比例为2：3
- 当所有后端服务器权重设置值相同时（如默认值10），流量将均匀地转发至所有后端服务器。例如：一个负载均衡实例绑定了2台后端服务器，权重均为默认值10，则流量将按50：50的比例进行转发；若该负载均衡实例新增加了一台权重设置为默认值10的后端服务器，则流量将按33：33：33的比例进行转发；若该实例又新增加了一台权重设置为默认值10的后端服务器则流量将按25：25：25：25的比例进行转发
- 启用了会话保持功能后，流量则不会完全按照权重比例转发
-------------------------------------------------------------------------------
转载自网络，作者：温昂展
负载均衡算法
目前，负载均衡算法不管是在学术研究还是在工程实现上都已比较成熟，算法大体可分以下几种：
- 随机（random）算法
- 轮询（round-robin）算法
- 哈希（hash）算法
- 一致性哈希算法
- 静态权重调度算法
- 动态权重、自适应算法
非自适应类算法不要求从服务节点实时获得负载的更新，而自适应算法通常需要负载均衡器能感知节点的负载变化动态调整分发策略，提高负载平衡的效果。也因此，两类算法在实现上架构设计也有较大的差别。
那么节点的负载如何衡量呢? 根据不同类型的系统应用，通常会定义不同的度量方式，如：CPU资源、内存资源、当前进程数、吞吐量、成功率、响应时间等指标都可以作为负载度量的指标，各个指标的重要程度根据实际情况有所不同。
负载均衡架构
这里探讨的是软负载均衡技术，一些基于硬负载均衡的架构设计不做具体涉及。软负载均衡架构大体可以分为：
- 基于客户端
- 基于DNS
- 基于反向代理
- 基于第三方应用或系统，如：哈雷、TGW、LVS
除了基于客户端方式，其他架构上实际上都是引入一个均衡服务器做控制或代理，或是返回请求的调度结果，亦或是直接对请求做转发。结合TAF的设计理念和架构做思考，负载均衡器其实可以放到主控侧来实现，但是我认为由于负载均衡策略的复杂性，单是对调度决策数据分析已经非常繁重，因此负载均衡通常还是单独引入一个接入层（统一接入网关）来实现，比如目前在使用的 TGW、哈雷接入、LVS（四层）、GSLB/LB（七层）、L5、CMLB 等都是此类接入层系统的实现方案。
负载均衡器周期性计算出每个被调机器的权重，再使用高效的配额算法分配各个主调机器的访问路由，主调机器上的业务进程通过API来取得这些路由，调用结束时通过API来反馈路由的好与坏。
而TAF的实现，我们把重点放在客户端。
内容引用说明
原文章标题：TAF 必修课（七）：负载均衡
原文章地址：https://cloud.tencent.com/developer/article/1005900