why
- 大量用户访问、高并发请求、海量数据
- 垂直扩展：高性能服务器 + 大型数据库 + 高速存储 + 高效编程语言(Go,Scala等)
- 横向扩展：分布式
- 从单机到分布式：重要的区别在于业务拆分和分布式部署
- 业务拆分和分布式解决了集中到分布的问题，但是独立业务还存在单点和统一访问入口问题
- 单点问题方案：冗余
- 统一访问入口问题：负载均衡，实现流量分发
what
- 将负载进行平衡，分摊到多个操作单元上执行
- 作用
- 分散并发压力，提高吞吐量（高性能）
- 故障转移（高可用）
- 网站伸缩（扩展性）
- 安全防护（黑白名单等过滤）
- 分类
- DNS负载均衡
- HTTP负载均衡
- IP负载均衡
- 链路层负载均衡
- 混合型负载均衡
负载均衡原理
- 系统扩展
- 纵向扩展：单机增强，无法满足大流量、高并发、海量数据
- 横向扩展：机器叠加
- 典型的集群和负载均衡架构
- 应用集群
- 同一应用多机部署
- 负载均衡设备
-
将用户请求，根据负载均衡算法，分发到集群中的某一台服务器
load-balance-001.jpg
-
- 应用集群
DNS负载均衡
load-balance-002.jpg
- 最早的负载均衡技术，利用域名解析实现负载均衡
- DNS服务器中配置多个A记录，对应的服务器构成集群
- 优点
- 简单：仅需DNS服务器即可
- 提高性能：可以解析成最短路径
- 缺点
- 可用性差：DNS解析是多级解析，改动DNS后解析时间较长
- 扩展性低：DNS控制权在域名商，无法做更多改善和扩展
- 维护性差：无法反映服务器当前运行状态；支持的算法少；无法区分服务器的差异
-
实际应用：DNS作为第一级
load-balance-003.jpg
IP负载均衡
load-balance-004.jpg
- 修改目的IP实现负载均衡
- 用户请求数据包 -> 负载均衡服务器 -> 内核进程获取数据包 -> 根据负载均衡算法得到真实IP -> 修改目的IP -> 发给服务器 -> 服务器处理，发送响应 -> 负载均衡服务器 -> 修改数据包源IP为自己 -> 响应发给用户（下面第二种方式）
- 两种方式
- 负载均衡服务器修改目的IP的同时修改源IP为自己，即源地址转换（SNAT）
- 负载均衡服务器同时作为真实服务器集群的网关
- 优点
- 在内核进程完成数据分发，比在应用层性能更好
- 缺点
- 所有请求响应都需要经过负载均衡服务器，集群吞吐量受限于负载均衡服务器网卡带宽
链路层负载均衡
load-balance-005.jpg
- 修改MAC地址，进行负载均衡
- 数据分发时，不修改IP，而修改目的MAC，配置真实集群所有机器虚拟IP和负载均衡服务器IP一致
- 实际服务器IP和请求目的IP一致，不需要负载均衡服务器进行地址转换，可将响应数据包直接返回给用户，避免负载均衡服务器网卡带宽成为瓶颈
- 也称为直接路由模式（DR）
- 优点
- 性能好
- 缺点
- 配置复杂
- 实践建议
- DR模式是目前使用最广泛的一种负载均衡方式
混合型负载均衡
load-balance-006.jpg
load-balance-007.jpg
