【Redis & 知识储备】应⽤服务集群架构 -- 分布系统的演进（3）

• 简介: 引入负载均衡, 应用以集群方式运作

• 出现原因: 单个应用不足以支持海量的并发请求, 高并发的时候响应变慢

• 架构工作原理

• 服务再次升级, 客户访问的流量增大, 单台应用服务器不能满足需求

• 一共有两种解决方案:

  • 垂直扩展 / 纵向扩展 Scale Up。通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量。这种⽅案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增⻓关系是⾮线性的，意味着选择性能 2 倍的硬件可能需要花费超过 4 倍的价格，其次硬件性能提升是有明显上限的。
  • ⽔平扩展 / 横向扩展 Scale Out。通过调整软件架构，增加应⽤层硬件，将⽤⼾流量分担到不同的应⽤层服务器上，来提升系统的承载能⼒。这种⽅案的优势在于成本相对较低，并且提升的上限空间也很⼤。但劣势是带给系统更多的复杂性，需要技术团队有更丰富的经验。

• 选择了⽔平扩展的⽅案，来解决该问题

• 这需要引⼊⼀个新的组件⸺负载均衡：为了解决⽤⼾流量向哪台应⽤服务器分发的问题，需要⼀个专⻔的系统组件做流量分发。

• 常见算法

  • Round-Robin 轮询算法。即⾮常公平地将请求依次分给不同的应⽤服务器。
  • Weight-Round-Robin 轮询算法。为不同的服务器（⽐如性能不同）赋予不同的权重（weight），能者多劳。
  • ⼀致哈希散列算法。通过计算⽤⼾的特征值（⽐如 IP 地址）得到哈希值，根据哈希结果做分发，优点是确保来⾃相同⽤⼾的请求总是被分给指定的服务器。也就是我们平时遇到的专项客⼾经理服务。

• 相关软件

  • 负载均衡软件：Nginx、HAProxy、LVS、F5 等

• 负载均衡器, 对于请求量的承担能力, 要远超过应用服务器的

架构优缺点

• 优点:
  • 应用服务器高可用: 应用满足高可用, 不会一个服务出问题整个站点挂掉
  • 应用服务具备一定高性能: 如果不访问数据库, 应用相关处理通过扩展可以支持海量请求快速响应
  • 应用服务有一定扩展能力: 支持横向扩展
• 缺点
  • 数据库成为性能瓶颈, 无法应对数据库的海量查询
  • 数据库是单点, 没有高可用
  • 运维工作增多, 扩展后部署工作增多, 需要开发对应的工具应对快速部署
  • 硬件成本较高