『大型网站技术架构:核心原理与案例分析』(三)

来源:互联网 发布:留学生 知乎 编辑:程序博客网 时间:2024/05/22 07:02

一、可用性度量与考核

度量

衡量方式:多少个9。

网站不可用时间(故障时间) = 故障修复时间点 – 故障发现(报告)时间点

网站年度可用性指标 = (1-网站不可用时间/年度总时间) * 100%

  • 2个9:基本可用,年度不可用时间小于88小时
  • 3个9:较高可用,年度不可用时间小于9小时
  • 4个9:具有自动恢复能力的高可用,年度不可用时间小于53分钟
  • 5个9:极高可用,年度不可用时间小于5分钟

考核

故障分:对网站故障进行分类加权计算故障责任。故障分 = 故障时间(分钟) * 故障权重。

  • 事故级故障(100): 严重故障,网站整体不可用
  • A类故障(20): 网站访问不顺畅或核心功能不可用
  • B类故障(5): 非核心功能不可用,或核心功能少数用户不可用
  • C类故障(1): 以上故障以外的其他故障

二、高可用网站架构

高可用架构设计不仅要考虑软硬件故障,还要考虑网站升级发布引起的不可用。

主要手段: 数据和服务的冗余备份和失效转移。

典型分层模型:

  • 应用层: 负责具体业务逻辑处理。思路:负载均衡设备
  • 服务层: 负责提供可复用的服务。思路:分布式服务调用框架,客户端软件负载均衡
  • 数据层: 负责数据的存储与访问。思路:数据冗余

三、高可用应用

主要特点:无状态

无状态应用是指应用服务器不保存业务的上下文信息,仅根据每次请求提交的数据进行相应业务逻辑处理,多个服务实例完全对等。

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

  • 应用访问量小也使用负载均衡技术构建一个小型集群保证高可用
  • 平滑升级

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

  • Session复制:Session在集群中同步,大集群不适用。
  • Session绑定:Session Sticky,会话黏滞。Hash(Source IP)、Hash(Cookie),无法实现高可用。
  • 利用Cookie记录Session:服务器端不记录Session,每次从Cookie中解,服务器可线性伸缩。缺点:大小受限、增大传输数据量、用户关闭Cookie时不可用。
  • Session服务器:独立部署Session服务器集群,通过 分布式缓存+数据库 实现。可用性高、伸缩性好、性能不错。

四、高可用服务

主要特点: 无状态

  • 分级管理:核心业务隔离部署、用更好更稳定的硬件。
  • 超时设置
  • 异步调用
  • 服务降级:拒绝服务(拒绝低优先级任务、随机拒绝)、关闭功能。
  • 幂等性设计:允许重复调用。

五、高可用数据

主要手段:数据备份和失效转移机制

含义:

  • 数据持久性
  • 数据可访问性
  • 数据一致性:
    • 1) 数据强一致:最强,各副本数据在物理存储中一致;
    • 2) 数据用户一致: 较强,在物理存储中可能不一致,但是通过纠错和校验机制,可以返回一个一致且正确地的数据给用户;
    • 3) 数据最终一致,较弱,用户得到的数据可能不一致,但是最终会达到一致。

CAP理论: 数据一致性(Consistency)、数据可用性(Availibility)、分区容忍性(Partition Tolerance)。大型网站中,通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),在某种程度上放弃一致性(C)。

缓存服务讨论,两种观点:

  • 缓存需要高可用:缓存承担了业务中绝大多数数据读取访问,缓存服务失效会影响整个网站可用性。
  • 缓存不需要高可用:缓存服务不是数据存储服务,缓存失效引起服务器负载太大的问题应用通过其他手段解决。比如扩大缓存集群规模,单台缓存服务器失效带来影响较小。

数据备份

  • 冷备份:定期将数据备份到某种存储介质(磁带、光盘……)并物理存档保管。简单、廉价、技术难度低,无法保证数据最终一致,可能丢数据,无法保证数据可用性。
  • 热备份:
    • 异步热备:Master-Slave架构。写Master,返回操作成功响应,再由Master同步到Slave,这个过程可能失败。例子:MySQL半同步复制、读写分离等。
    • 同步热备:存储服务器互相间对等。数据多副本写入同步完成。

失效转移

  • 失效确认:1. 心跳检查。2. 应用程序访问失败报告。
  • 访问转移:数据读写重新路由
  • 数据恢复:恢复副本数量

六、高可用网站软件质量保证

  • 网站发布:平滑升级,从LB下线->更新程序->挂回LB
  • 自动化测试
  • 预发布验证:预发布服务器与线上机器的唯一不同就是没有配置在负载均衡上,外部用户无法访问。避免验证过程污染生产环境数据。
  • 代码控制:1. 主干开发、分支发布。2. 分支开发、主干发布。
  • 自动化发布:周四发布,火车发布模型(基于规则驱动的流程,一级级评审)
  • 灰度发布:分批次升级,等一批稳定运行后再上下一批。

七、网站运行监控

准则:“不允许没有监控的系统上线”

监控数据采集

  • 用户行为日志收集:服务器端日志、客户端日志
  • 服务器性能监控
  • 运行数据报告:业务场景相关

监控管理

  • 系统报警
  • 失效转移
  • 自动优雅降级
0 0