可用性

网站可用性度量

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

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

高可用网站架构

目的: 保证服务器硬件故障时服务依然可用,数据依然保存并能够被访问

主要手段: 冗余备份和失效转移(心跳检测也是一种失效转移策略)

大型网站的分层架构(应用层/服务层/数据层,甚至更小粒度)及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点

高可用的应用

应用层: 主要处理网站应用的业务逻辑,一个显著特点就是应用的无状态性.所谓无状态应用指应用服务器不保存业务的上下文信息,请求提交到任意服务器,处理结果都是完全一致的

通过负载均衡进行无状态服务的失效转移: 基于应用服务器的无状态性,实现服务器可用状态实时监测,自动失效转移的机制就是负载均衡

应用服务器集群的Session管理: 事实上,业务总是有状态的,如记录用户当前登录状态,用户每次刷新页面都需要更新这些信息.Web应用中这些多次请求修改使用的上下文对象称作会话(Session).单机情况下,Session由部署在服务器上的Web容器管理;集群环境中,由于负载均衡服务器可能会将请求分发到集群中任意一台应用服务器上,所以保证每次请求获取正确的Session要比单机复杂的多.集群环境下,Session管理主要有以下几种手段
1.Session复制
原理: 每台服务器都保存所有用户的Session信息
缺陷: 集群规模较大时,Session复制会占用服务器和网络大量资源,系统不堪重负;服务器内存不够Session使用

使用Session复制实现应用服务器共享Session.png

2.Session绑定
原理: 利用负载均衡源地址Hash算法实现,负载均衡服务器总是将来源于同一IP请求分发到同一台服务器上.Session绑定在某台特定服务器上,保证Session总能在这台服务器上获取,这种方法称为会话黏滞
缺陷: 一旦某台服务器宕机,该机器上的Session信息将不复存在

利用负载均衡的会话黏滞机制将请求绑定到特定服务器.png

3.利用Cookie记录Session
原理: 将Session记录在客户端,每次请求服务器时,将Session放在请求中发送给服务器,服务器处理完成再将修改过的Session响应给客户端
缺陷: 受Cookie大小限制,能记录的信息有限;每次请求响应都需要传输Cookie,影响性能;若用户关闭Cookie,则访问不正常;由于Cookie简单易用,可用性高,支持应用服务器线性伸缩,大部分需记录的Session信息又比较小,事实上许多网站使用Cookie记录Session

利用Cookie记录Session信息.png

4.Session服务器

原理: 利用独立部署的Session服务器(集群)统一管理Session.这种解决方案事实上是将应用服务器的状态分离,分为无状态的应用服务器和有状态的Session服务器

利用Session服务器共享Session.png

高可用的服务

分级管理: 核心应用和服务优先使用更好的硬件,同时在服务部署上也进行必要的隔离

超时设置: 设置服务调用超时时间,一旦超时,通信框架就抛出异常,应用程序可根据服务调度策略,选择继续重试或失效转移

异步调用: 消息队列

服务降级: 保证核心应用和功能的正常运行,需要对服务降级.降级有两种手段:拒绝服务(拒绝低优先级应用调用,减少服务并发数,或随机拒绝部分请求)或关闭服务(关闭部分不重要的服务)

幂等性设计: 服务重复调用和调用一次产生的结果相同

高可用的数据

保证数据存储高可用的手段主要是数据备份和失效转移机制

高可用数据含义

数据持久性: 保证数据可持久存储,不但在写入数据时需要写入持久性存储,还需要将数据备份多个副本,存放在不同的物理存储设备上,在故障或灾害发生时保证数据不丢失
数据可访问性: 多份副本存放在不同存储设备的情况下,若一个数据存储设备损坏,就需要将访问切换到另一个数据存储设备上,若这个过程不能很快完成,或在完成过程中需要停止终端用户访问数据,那么这段时间数据是不可访问的
数据一致性: 在数据有多个副本情况下,服务器/网络/软件出现故障,会导致部分副本写入成功,部分副本写入失败,造成各个副本之间副本不一致.数据不一致分为以下三种:
数据强一致: 各个副本物理存储中总是一致;数据更新操作总是一致的,而不是处于不确定状态
数据用户一致: 各个副本物理存储可能不一致,但用户访问时通过纠错和校验机制,可以确定一个正确且一致的数据返回给用户
数据最终一致: 物理存储和用户访问都可能不一致,系统经过一段时间自我修复和修正,数据最终一致

CAP理论: 一个提供数据服务的存储系统无法同时满足数据一致性(Consistency),数据可用性(Availibility),分区耐受性(Patition Tolerance,系统具有跨网络分区的伸缩性)这三个条件.大型网站通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),在某种程度放弃一致性(C).针对分布式数据处理系统的数据不一致进行补偿和纠错,避免出现应用系统数据不正确

CAP原理.png

数据备份

数据冷备: 优点是简单廉价技术难度低;缺点是不能保证数据最终一致,若系统数据丢失,从上个冷备点开始后的数据将永久丢失,同时无法保证数据可用性,恢复数据需要较长时间,导致系统不可用
数据热备: 分为异步热备和同步热备,关系型数据库热备机制就是通常所说的Master-Slave机制

数据异步热备.png

数据同步热备.png

失效转移
原理: 集群中任何一台服务器宕机,针对这台服务器所有读写操作都需要重新路由到其他服务器,保证数据访问不会失败,这个过程即为失效转移

失效转移操作由三部分组成: 失效确认,访问转移,数据恢复

失效确认: 判断服务器宕机是系统进行失效转移的第一步,系统确认一台服务器是否宕机的手段有两种:心跳检测和应用程序访问失败报告.对于应用程序访问失败报告,系统会再次发送心跳检测进行确认,以免错误判断服务器宕机

存储服务器失效确认.png
访问转移: 确认某台数据存储服务器宕机后,需要将数据读写访问重新路由到其他服务器上
数据恢复: 从健康服务器复制数据,将数据副本数目恢复到设定值

高可用网站的软件质量保证

网站发布: 飞行中的飞机换引擎,既不能让飞机剧烈晃动(影响用户体验),也不能让飞机降落(系统停机维护),更不能让飞机坠毁(系统故障网站完全不可用)

网站应用发布流程.png

自动化测试

预发布验证: 预发布服务器和线上正式服务器唯一不同就是没有配置在负载均衡服务器上,外部用户无法访问.工程师通过配置hosts文件绑定域名IP关系或直接使用IP地址访问

网站应用预发布.png

代码控制: 如何进行代码管理,技能保证代码发布版本稳定正确,又能保证不同团队开发互不影响

自动化发布: 火车发布模型

网站火车发布模型.png

灰度发布: 部分服务器发布新版本,其余服务器保持老版本,然后监控用户操作行为,收集用户体验报告,比较用户对两个版本的满意度,确定最终的发布版本.这种手段也被称为AB测试

网站灰度发布模型.png