架构_Web高可用架构

2021-12-18-(6)-PM:352

零. 核心问题

  1. 网站可用性如何衡量？
    • 指标
    • 考核
  2. 如何设计高可用的系统？
    • 冗余
    • 失效转移

一. 网站可用性的衡量

1. 可用性度量

  • 9的多少数量来衡量
    • 90% 小于36天12小时
    • 99% 小于87小时36分钟
    • 99.9% 小于8小时46分钟
    • 99.99% 小于52分钟33秒
    • 99.999% 小于5分钟15秒
    • 99.9999% 小于31.5秒

2. 可用性考核

  • 数据和服务的冗余备份
  • 数据和服务的失效转移

二. 高可用的应用

1. 负载均衡进行无状态服务的失效转移

  • 无状态，实现所有服务器完全对等
  • 失效转移，某一个出现问题能够及时剔除

2. 应用服务器集群的Session管理

  • 业务总是有状态的
  • Session,多次请求使用的上下文对象
    1. Session复制 - 每台都备份一份 - 空间/带宽浪费较多
    2. Session绑定 - 通过负载均衡将请求分发到同一台服务器 - 一旦宕机就会导致无法完成业务处理
    3. 利用Cookie存储Session - Cookie大小受限 - 传输耗费性能 - 浏览区关闭Cookie会导致不可用
    4. Session服务器 - Session服务集群统一管理Session

三. 高可用的服务

1. 分级管理

  • 服务分级管理
    • 核心应用和服务使用更好的配置
  • 服务部署隔离
    • 避免故障的连锁反应

2. 超时设置

  • 由于服务失去响应导致用户请求长时间得不到响应
    • 占用资源
    • 设置超时时间及时释放资源

3. 异步调用

  • 通过消息队列等异步方式，避免一个服务失败导致整个过程失败

4. 服务降级

  • 访问高峰，服务因大量并发而性能下降，为保证核心应用和功能的正常运行
    • 拒绝服务
      • 拒绝低优先级应用的调用
      • 减少服务调用并发数
    • 关闭功能
      • 关闭部分不重要的服务
      • 节约系统开销，为重要的服务和功能让出资源

5. 幂等性设计

  • 服务重复调用和调用一次产生的结果相同
    • 解决服务重复调用问题

四. 高可用的数据

1. CAP原理

  • C: Consistency（数据一致性）
    • 多份副本数据不一致
    • 所有程序都能访问得到相同的数据
  • A: Availability（数据可用性）
    • 多份副本其中某个损坏，需要将访问切换到可用的副本上
    • 任何时候程序能都可与读写访问
  • P: Partition Tolerance（分区耐受性）
    • 系统可以跨网络分区线性伸缩
  • 大型网站通常选择AP,一定程度上放弃C
    • 数据强一致性
      • 各个副本的数据在物理存储中总是一致
      • 数据更新操作结果操作响应总是一致，不处于不确定状态
    • 数据用户一致
      • 各个副本的数据在物理存储中可能不一致
      • 终端用户访问，通过纠错和教研机制，可以确定一个一致且正确的数据
    • 数据最终一致
      • 各个副本的数据在物理存储中可能不一致
      • 终端用户访问，可能不一致
      • 但是经过一段时间的自我恢复和修正，数据最终会达成一致

2. 数据备份

  • 冷备份
    • 缺点
      • 不能保证数据一致性
      • 备份结束时间后更新的数据会丢失
      • 不能保证可用性，恢复时间较长
    • 优点
      • 可靠性高，有效
  • 热备份
    • 异步热备
      • 操作成功保证写入一个成功，其他副本的写入异步完成
      • 分为主存储服务器和从服务器
      • 正常情况下只连接主存储器
    • 同步热备
      • 多分数据副本的写入操作同步完成
      • 存储服务器没有主从之分
      • 性能由最慢那台决定
    • 实践中通常做法
      • 写操作只访问Master数据库
      • 读操作只访问Slave数据库

3. 失效转移

  • 失效确认
    • 心跳检测
    • 访问失败报告
  • 访问转移
    • 对等服务器
    • 不对等服务器
  • 数据恢复
    • 部分服务宕机时，数据存储的副本减少，必须将副本的数量恢复到系统设定的值
    • 系统从正常的服务复制数据

五. 高可用软件质量保证

1. 网站发布

  • 关闭服务器集群中的一小部分
  • 发布过的服务可以立即访问
  • 整个发布过程不影响用户使用

2. 自动化测试

  • Selenium
    • 功能测试
    • 浏览器兼容测试

3. 预发布验证

  • 避免环境不一致导致上线异常
  • 通过预发布服务器进行预发布验证
  • 与线上的唯一不同是没有配置在负载均衡服务器上

4. 代码控制

  • 主干开发，分支发布
    • 主干代码反应目前整体应用的状态一目了然，便于管理和控制
  • 分支开发，主干发布
    • 当前主要使用的方式

5. 自动化发布

  • 基于规则驱动的流程

6. 灰度发布（AB测试）

  • 将服务器分成若干部分
  • 每天只发布一部分服务器
  • 观察运行稳定没有问题
  • 如果发现问题回滚已发布的服务器

六. 网站运行监控

  • 不允许没有监控的系统上线

1. 监控数据采集

  1. 用户行为日志收集
    • 服务端日志
    • 客户端日志
  2. 服务器性能监控
    • 收集服务器性能指标
  3. 运行数据报告
    • 监控具体业务场景相关的技术和业务
      • 平均响应延迟时间
      • 邮件数目
      • 缓存命中率

2. 监控管理

  • 根据监控数据进行
    • 风险预警
    • 负载调整
    • 最大化资源利用
  1. 系统报警
    • 配置警报阀值
    • 设置警报系统
  2. 失效转移
    • 警报系统通知应用进行失效转移
  3. 自动优雅降级
    • 访问高峰时，主动关闭部分功能
    • 确保资源用在核心功能的访问上

总结

  1. 先求生存
  2. 再求发展
  3. 追求高概率稳定性