C. 高性能架构 --- 高性能负载均衡

C. 高性能架构 — 高性能负载均衡

概述

• 不同类型的请求，对网络链路要求不一样，比如说
  • 搜索请求的要求是：延迟
  • 视频上传的要求是：吞吐量
• 单从硬件来看，关于优化资源的利用率，避免某个服务器负载过高

分类

• DNS 负载均衡：DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。
  • 优点
    • 简单、成本低：负载均衡工作交给 DNS 服务器处理，无须自己开发或者维护负载均衡设备。
    • 就近访问，提升访问速度：DNS 解析时可以根据请求来源 IP，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能。
  • 缺点
    • 更新不及时：DNS 缓存的时间比较长，修改 DNS 配置后，由于缓存的原因，还是有很多用户会继续访问修改前的 IP，这样的访问会失败，达不到负载均衡的目的，并且也影响用户正常使用业务。
    • 扩展性差：DNS 负载均衡的控制权在域名商那里，无法根据业务特点针对其做更多的定制化功能和扩展特性。
    • 分配策略比较简单：DNS 负载均衡支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）；也无法感知后端服务器的状态。
  • 解决方案
    • 针对 DNS 负载均衡的一些缺点，对于时延和故障敏感的业务，有一些公司自己实现了 HTTP-DNS 的功能，即使用 HTTP 协议实现一个私有的 DNS 系统。这样的方案和通用的 DNS 优缺点正好相反。
  • 实现方式：精确评估每个用户的地理位置很困难，只能做到针对大部分用户是最优的
    • DNS回复多个地址，客户端随机选择
    • 提供anycaseDNS服务器地址，假设DNS请求会到达最近的地址这个方式来识别“最近地址”
    • 建立所有的IP地址和无力地值的对照表，按照对照回复
  • 案例：google负载均衡器
    • Google将权威DNS服务器和全局负载均衡其整合一起，全局负载均衡器负责跟踪各个数据中心的流量水平，可用容量和各种基础设施的状态
• 硬件负载均衡
  • 优点
    • 功能强大：全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。
    • 性能强大：对比一下，软件负载均衡支持到 10 万级并发已经很厉害了，硬件负载均衡可以支持 100 万以上的并发。
    • 稳定性高：商用硬件负载均衡，经过了良好的严格测试，经过大规模使用，稳定性高。
    • 支持安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙、防 DDoS 攻击等安全功能。
  • 缺点
    • 价格昂贵：最普通的一台 F5 就是一台“马 6”，好一点的就是“Q7”了。
    • 扩展能力差：硬件设备，可以根据业务进行配置，但无法进行扩展和定制。
• 软件负载均衡
  • 优点
    • 简单：无论是部署还是维护都比较简单。
    • 便宜：只要买个 Linux 服务器，装上软件即可。
    • 灵活：4 层和 7 层负载均衡可以根据业务进行选择；也可以根据业务进行比较方便的扩展，例如，可以通过 Nginx 的插件来实现业务的定制化功能。
  • 缺点
    • 性能一般：一个 Nginx 大约能支撑 5 万并发。
    • 功能没有硬件负载均衡那么强大。
    • 一般不具备防火墙和防 DDoS 攻击等安全功能。
• 虚拟IP：很多设备共享同一个虚拟IP
  • 网络负载均衡器算法
    • 选择负载最小的后端服务器，但是对有状态的协议不适用
    • 数据包中的某些部分创建出一个连接标识符，使用连接标识符来选择后端服务器，但是如果出现服务器增减的情况，原有的状态就会失效
    • 一致性哈希
  • 实现方式
    • 网络地址转换
    • 修改数据链路层的信息（MAC地址），后端服务器直接发送回应给用户，被称为直接服务器响应，缺点是所有的机器必须在数据链路层相同，对于大集群做不到
    • 包封装，用通用路由封装协议封装到另外一个IP包，有可能需要碎片重组，不过在数据中心，可以通过设置更大的MTU来避免这种情况

架构

• 地理级别负载均衡：www.xxx.com 部署在北京、广州、上海三个机房，当用户访问时，DNS 会根据用户的地理位置来决定返回哪个机房的 IP，图中返回了广州机房的 IP 地址，这样用户就访问到广州机房了。
• 集群级别负载均衡：广州机房的负载均衡用的是 F5 设备，F5 收到用户请求后，进行集群级别的负载均衡，将用户请求发给 3 个本地集群中的一个，我们假设 F5 将用户请求发给了“广州集群 2”。
• 机器级别的负载均衡：广州集群 2 的负载均衡用的是 Nginx，Nginx 收到用户请求后，将用户请求发送给集群里面的某台服务器，服务器处理用户的业务请求并返回业务响应。

客户端连接服务器

• 识别异常任务
  • 流速控制
    • 实现
      • 客户端任务会跟踪记录发往后端的请求状态。当某个后端的活跃请求达到一定数量时，不再给它发送请求
    • 缺点
      • 可能在到达限制之前就过载了
      • 可能有特殊的长连接请求，导致无法响应新的连接请求
  • 跛脚鸭状态
    • 状态
      • 健康
      • 拒绝连接：后端处于无响应状态
      • 跛脚鸭状态：后端任务正在健康端口，并且可以服务请求，但是已经明确要求客户端停止发送请求
    • 实现
      • 客户端定期发送UDP监控检查包，判断服务端的状态
    • 使用场景
      • 后端程序需要进行较长时间的初始化过程
• 利用划分子集限制连接池大小：限制某个客户端任务需要连接的后端任务数量
  • 客户端和服务端请求的模式
    • 保持长连接
    • 每个请求建立一次连接和销毁一次连接
    • UDP
  • 优化方法：子集模式
    • 子集大小
      • 需要相对较大子集数量的方式
        • 客户端数量相比后端数量少很多
        • 客户端会出现负载不平衡的情况（比如说某个客户端会比其他的客户端发送更多的请求）
    • 选择算法
      • 随机选择
        • 缺点
          • 会出现负载不均衡，特别是子集数量越小越明显，如果要达到相对均衡，需要至少75%的自己大小
      • 确定性算法
        • 步骤
          • 将客户端分批，比如说n个客户端一批
          • 针对每一批客户端，对服务端进行重排序，然后划分成n个子集，每个客户端和子集一一对应
  • 关键点
    • 服务端出现变化（新增或者减少），客户端如何重新达到负载均衡

算法

• 任务平分类：负载均衡系统将收到的任务平均分配给服务器进行处理，这里的“平均”可以是绝对数量的平均，也可以是比例或者权重上的平均。
  • 轮询
    • 某个服务器当前因为触发了程序 bug 进入了死循环导致 CPU 负载很高，负载均衡系统是不感知的，还是会继续将请求源源不断地发送给它。
    • 集群中有新的机器是 32 核的，老的机器是 16 核的，负载均衡系统也是不关注的，新老机器分配的任务数是一样的。
  • 加权轮询：负载均衡系统根据服务器权重进行任务分配，这里的权重一般是根据硬件配置进行静态配置的，采用动态的方式计算会更加契合业务，但复杂度也会更高。
• 负载均衡类：负载均衡系统根据服务器的负载来进行分配，这里的负载并不一定是通常意义上我们说的“CPU 负载”，而是系统当前的压力，可以用 CPU 负载来衡量，也可以用连接数、I/O 使用率、网卡吞吐量等来衡量系统的压力。
  • 方法
    • LVS 这种 4 层网络负载均衡设备，可以以“连接数”来判断服务器的状态，服务器连接数越大，表明服务器压力越大。
    • Nginx 这种 7 层网络负载系统，可以以“HTTP 请求数”来判断服务器状态（Nginx 内置的负载均衡算法不支持这种方式，需要进行扩展）。
    • 如果我们自己开发负载均衡系统，可以根据业务特点来选择指标衡量系统压力。如果是 CPU 密集型，可以以“CPU 负载”来衡量系统压力；如果是 I/O 密集型，可以以“I/O 负载”来衡量系统压力。
  • 复杂度
    • 最少连接数优先的算法要求负载均衡系统统计每个服务器当前建立的连接，其应用场景仅限于负载均衡接收的任何连接请求都会转发给服务器进行处理，否则如果负载均衡系统和服务器之间是固定的连接池方式，就不适合采取这种算法。例如，LVS 可以采取这种算法进行负载均衡，而一个通过连接池的方式连接 MySQL 集群的负载均衡系统就不适合采取这种算法进行负载均衡。
    • CPU 负载最低优先的算法要求负载均衡系统以某种方式收集每个服务器的 CPU 负载，而且要确定是以 1 分钟的负载为标准，还是以 15 分钟的负载为标准，不存在 1 分钟肯定比 15 分钟要好或者差。不同业务最优的时间间隔是不一样的，时间间隔太短容易造成频繁波动，时间间隔太长又可能造成峰值来临时响应缓慢。
• 性能最优类：负载均衡系统根据服务器的响应时间来进行任务分配，优先将新任务分配给响应最快的服务器。
  • 复杂度
    • 负载均衡系统需要收集和分析每个服务器每个任务的响应时间，在大量任务处理的场景下，这种收集和统计本身也会消耗较多的性能。
    • 为了减少这种统计上的消耗，可以采取采样的方式来统计，即不统计所有任务的响应时间，而是抽样统计部分任务的响应时间来估算整体任务的响应时间。采样统计虽然能够减少性能消耗，但使得复杂度进一步上升，因为要确定合适的采样率，采样率太低会导致结果不准确，采样率太高会导致性能消耗较大，找到合适的采样率也是一件复杂的事情。
    • 无论是全部统计还是采样统计，都需要选择合适的周期：是 10 秒内性能最优，还是 1 分钟内性能最优，还是 5 分钟内性能最优……没有放之四海而皆准的周期，需要根据实际业务进行判断和选择，这也是一件比较复杂的事情，甚至出现系统上线后需要不断地调优才能达到最优设计。
• Hash 类：负载均衡系统根据任务中的某些关键信息进行 Hash 运算，将相同 Hash 值的请求分配到同一台服务器上。常见的有源地址 Hash、目标地址 Hash、session id hash、用户 ID Hash 等。
  • 源地址 Hash
  • ID Hash