读发布！设计与部署稳定的分布式系统（第2版）笔记24_互联层之负载均衡

 

1. 水平扩展

1.1. 有助于提高系统的整体容量和韧性

1.2. 现阶段构建的几乎所有系统，都使用了能够水平扩展的实例农场

1.3. 引入了对负载均衡的需求

2. 负载均衡

2.1. 在整个实例池中分发请求，从而尽可能快地正确响应所有请求

2.2. 负载均衡会创建映射到实例池的“虚拟IP地址”

2.3. DNS轮询视为负载均衡的一种手段

2.4. 负载均衡器是系统服务中不可或缺的组成部分，不能将其仅仅视为网络基础设施的一部分

2.5. 构建服务和规划部署时，需要与负载均衡设计结合起来

2.5.1. 如果系统结构将负载均衡器处理为其他团队管理的“超出管理范围的部分”，那么甚至可以考虑在可控范围内实施一层软件负载均衡，完全安装在网络硬件负载均衡器后

2.5.2. 软件负载均衡器在OSI应用层上运行，成本低，易操作

3. 主动负载均衡

3.1. 所有类型的主动负载均衡器，都会监听一个或多个套接字

3.2. 这些套接字在一个或多个IP地址上，这些IP地址通常称为“虚拟IP地址”或VIP

3.3. 需要使用的负载均衡算法

3.4. 需要对实例进行的健康状况检查

3.5. 运用哪种会话黏性进行客户端会话

3.6. 当实例池中没有可用实例时如何处理传入请求

3.7. 对发出调用的应用程序而言，负载均衡器应是无形的

3.8. 如果客户端能感知到负载均衡器，那么很可能是负载均衡器停机了

3.9. 图示

 

4. 反向代理服务器

4.1. 反向代理服务器后的服务提供方实例，需要生成多个URL，包含虚拟IP地址对应的DNS名字，而不是自身的主机名

4.2. 无论如何都不应该使用实例自身的主机名

4.3. 通的正向代理服务器采用多路复用将传出的多个调用组合到单个源IP地址上

4.4. 反向代理服务器正相反，它采用逆多路复用将传入单个IP地址上的调用分散到多个地址上

4.5. Squid、HAProxy、Apache httpd和nginx等都是很好的反向代理服务器，能够起到负载均衡的作用

4.6. 讲规矩”的代理服务器，会将X-Forwarded-For这样的头部信息添加到传入的HTTP请求中

4.7. 服务可以使用自定义的日志格式记录

4.8. 在反向代理服务器上配置缓存，通过缓存响应信息来减少服务实例的负载

4.8.1. 有助于减少内部网络上的流量

4.9. 由于反向代理服务器需要处理每个请求，因此它可能很快就不堪重负

4.10. 图示

 

5. 硬件负载均衡

5.1. 与反向代理服务器功能类似的专用网络设备

5.2. 和反向代理软件一样，这些设备提供同种类型的拦截和重定向功能

5.3. 相比反向代理软件，硬件负载均衡器运行时更靠近网络，所以能够更好地提供容量和吞吐量

5.3.1. 能满足的网络规模更大，但它要求直接访问网络，还需要特定的工程技能

5.4. 具有应用程序感知能力，并提供在OSI模型第4层到第7层切换的能力

5.4.1. 可以负载均衡所有面向连接的协议，而不仅仅是HTTP或FTP

5.5. 可以将流量从一个站点完全切换到另一个站点

5.5.1. 在灾难恢复时特别有用，可以将流量转移到故障切换站点

5.6. 硬件负载均衡器与GSLB配合使用效果更佳

5.7. 最大的缺点是价格

5.7.1. 低端配置的价格大概是几万美元

5.7.2. 高端配置的价格轻易就能达到几十万美元

5.8. F5的Big-IP产品

6. 健康状况检查

6.1. 负载均衡器不会将流量发送到未通过若干健康状况检查的实例

6.2. 是负载均衡器配置的重要组成部分

6.3. 良好的健康状况检查可以确保请求能够执行成功，而不仅仅是服务正在监听套接字

7. 会话黏性

7.1. 负载均衡器会尝试将重复的请求引向同一个实例，这对应用程序服务器中的有状态服务很有帮助

7.1.1. 有助于缩短有状态服务的响应时间

7.2. 会话黏性需要某种方式来确定如何将“重复请求”分组到一个逻辑会话中

7.3. 黏性会话的缺点是它会阻止负载在机器间均匀分布

8. 按请求类型分隔流量

8.1. 使用基于内容感知的负载均衡

8.1.1. 有效运用负载均衡器的方法是“基于内容的路由”

8.2. 请求中的某些内容对负载均衡器必须是可识别的