论文

2017届

软件体系架构质量属性之可用性

姓名：刘晨

学号：20173672

院系：信息科学与技术学院

专业：软件工程

指导教师：王建民

联系方式：15614157932

软件体系架构质量属性之可用性

刘晨石家庄铁道大学河北省石家庄市 050043

摘要

本文讲述了有关软件质量属性六大指标中的可用性，通过针对淘宝网工作流程的举例和亚马逊云计算服务进行简单的阐述，分析可用性在网站方面的重要性，其主要包含网站可用性的度量与考核，可用性的应用，保障数据的可用性三个方面。

关键词可用性，应用，数据

Availability of Software Architecture Quality Attributes

(LiuChen, ShiJiaZhuang TieDao University,Shijiazhuang, Hebei province,050043)

Abstract

This paper describes the usability of the six major indicators of software quality attributes. Through a simple exposition of Taobao workflow and Amazon cloud computing service, it analyzes the importance of usability in websites, which mainly includes the measurement and assessment of website usability, the application of usability and the guarantee of data usability.

KEY WORDS availability applicable data

前言

由于本学期开展了软件体系架构课程，学习了有关软件质量体系的六大属性的内容，应老师要求，从而进一步对可用性的深入了解，也为了以后的工作过程中更加清晰。可用性分析所关注的方面包括：如何检测系统故障，系统故障发生的频度，出现故障时会发生什么情况，允许系统有多长时间非正常运行，什么时候可以安全地出现故障，如何防止故障的发生以及发生故障时要求进行哪种通知。对公司而言，可用性关系网站的生死存亡。对个人而言，可用性关系到自己的绩效升迁。工程师对架构做了许多优化、对代码做了很多重构，对性能、扩展性、伸缩性做了很多改善，但别人未必能直观地感受到。但如果产品出了重大故障例如页面无响应，用户能很直观的感受到。事物总是先求生存，然后求发展。

1. 网站可用性的度量与考核

1.1网站可用性度量

网站不可用也被称作网站故障，在软件系统的高可靠性（也称为可用性，英文描述为HA，High Available）里有个衡量其可靠性的标准——X个9，这个X是代表数字3--5。X个9表示在软件系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比。

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

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

如QQ的可用性是4个9,即QQ服务99%可用，这意味着QQ服务要保证其在所有运行时间中，只有0.01 %的时间不可用，其业务中断时间也就是(1-99.99%)*365*24=0.876小时=52.6分钟。

对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时; 3个9是较高可用，网站年度不可用时间小于9小时; 4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟; 5个9是极高可用性,网站年度不可用时间小于5分钟。

由于可用性影响因素很多，对于网站整体而言，达到4个9,乃至5个9的可用性，除了过硬的技术、大量的设备资金投入和工程师的责任心，还要有个好运气。SLA可用性好几个9的阿里云也宕机过多次。要做到更多的9，就要不断的监控自己的服务，服务挂掉能及时恢复服务。就像开车出远门，首先得检查轮胎，同时还得准备一个备胎一样的道理。

1.2网站可用性考核

可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面，可用性指标是网站或者产品的整体考核指标，具体到每个工程师的考核，更多的是使用故障分。
所谓故障分是指对网站故障进行分类加权计算故障责任的方法。

分类	描述	权重
事故级故障	网站整体不可用	100
A类故障	网站访问不顺畅或核心功能不可用	20
B类故障	非核心功能不可用，或核心功能少数用户不可用	5
C类故障	以上故障以外的其他故障	1

表1 网站故障分类权重表示例

故障分的计算公式为:

故障分=故障时间(分钟) x故障权重

下面我们假设双十一导致淘宝用户猛增的场景，进一步对故障分加以说明。

场景	双十一导致淘宝用户猛增
刺激源	淘宝用户
故障	登录人数过多，导致淘宝无法响应，淘宝页面瘫痪
持续时间	30分钟
制品	淘宝的处理器、通信通道、存储器、进程
环境	用户的正常浏览操作
响应	淘宝页面呈现“网络出现故障，重新刷新”等的提示信息
响应度量	系统降级模式下继续运行，用户刷新页面或者重新登录之后可继续正常使用。

表2 双十一导致淘宝用户猛增场景

通过故障的描述可知此次属于A类故障且持续了30分钟，那么故障分应为30*20=600分。出现了故障那么必然会有处理机制，以下是应对上述场景的一个简化的故障处理流程图。

图1 淘宝故障处理流程图

在年初或者考核季度的开始，会根据网站产品的可用性指标计算总的故障分，然后根据团队和个人的职责角色分摊故障分，这个可用性指标和故障分是管理预期。在实际发生故障的时候，根据故障分类和责任划分将故障产生的故障分分配给责任者承担。

2. 可用性的应用

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

不保存状态的应用给高可用的架构设计带来了巨大便利，既然服务器不保存请求的状态，那么所有的服务器完全对等，当任意一台或多台服务器宕机，请求提交给集群中其他任意一台可用机器处理，这样对终端用户而言，请求总是能够成功的，整个系统依然可用。对于应用服务器集群，实现这种服务器可用状态实时监测、自动转移失败任务的机制是负载均衡。

负载均衡主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载处理能力。

由于负载均衡在应用层实际上起到了系统高可用的作用，因此即使某个应用访问量非常少，只用一台服务器提供服务就绰绰有余，但如果需要保证该服务高可用，也必须至少部署两台服务器，使用负载均衡技术构建一个小型的集群。

2.2应用服务器集群的Session管理

应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的，在交易类的电子商务网站例如淘宝京东，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品，用户每次刷新页面都需要更新这些信息。

Web应用中将这些多次请求修改使用的上下文对象称作会话( Session ),单机情况下，Session可由部署在服务器上的Web容器管理。在使用负载均衡的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。

集群环境下，Session管理主要有以下几种手段：

1. Session复制

应用服务器开启Web容器的Session复制功能，在集群中的几台服务器之间同步Session 对象，使得每台服务器上都保存所有用户的Session 信息，这样任何一台机器宕机都不会导致Session数据的丢失，而服务器使用Session时，也只需要在本机获取即可。

2. Session 绑定

Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。这样在整个会话期间，用户所有的请求都在同一台服务器上处理，即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。这种方法又被称作会话黏滞。

3.利用Cookie记录Session

早期的企业应用系统使用C/S(客户端/服务器)架构，一种管理Session的方式是将Session记录在客户端，每次请求服务器的时候，将Session放在请求中发送给服务器，服务器处理完请求后再将修改过的Session 响应给客户端。网站没有客户端，但是可以利用浏览器支持的Cookie记录Session。

4. Session 服务器

Session服务器。利用独立部署的Session 服务器(集群)统一管理Session,应用服务器每次读写Session时，都访问Session服务器。这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。

3. 保障数据的可用性

对许多网站而言，数据是其最宝贵的物质资产，硬件可以购买，软件可以重写，但是多年运营积淀下来的各种数据(用户数据、交易数据、商品数据）一旦失去，对网站的打击可以说是毁灭性的，因此可以说，保护网站的数据就是保护企业的命脉。

不同于高可用的应用和服务，由于数据存储服务器上保存的数据不同，当某台服务器宕机的时候，数据访问请求不能任意切换到集群中其他的机器上。

保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。而失效转移机制则保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本,保证系统可用。

3.1 CAP原理

为了保证数据的高可用，网站通常会牺牲另一个也很重要的指标:数据一致性。高可用的数据有如下几个层面的含义：

数据持久性

在写入数据时需要写入持久性存储，还需要将数据备份一个或多个副本，存放在不同的物理存储设备上,在某个存储故障或灾害发生时，数据不会丢失。

数据可访问性

在多份数据副本分别存放在不同存储设备的情况下，如果一个数据存储设备损坏，就需要将数据访问切换到另一个数据存储设备上，如果这个过程不能很快完成(终端用户几乎没有感知)，或者在完成过程中需要停止终端用户访问数据，那么这段时间数据是不可访问的。

数据一致性

在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就会造成各个副本之间的数据不一致，数据内容冲突。

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性( Consistency).数据可用性( Availibility).分区耐受性( Patition Tolerance, 系统具有跨网络分区的伸缩性)这三个条件。

在大型网站中，为了保证分布式处理系统的高可用性，通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),而在某种程度上放弃一致性(C)。

2012年淘宝“双十一”活动期间，在活动第一分钟就涌入了1000万独立用户访问，这种极端的高并发场景对数据处理系统造成了巨大压力，存储系统较弱的数据一致性导致出现部分商品超卖现象(交易成功的商品数超过了商品库存数)。CAP原理对于可伸缩的分布式系统设计具有重要意义。

3.2 数据备份

数据备份是一-种古老而有效的数据保护手段，早期的数据备份手段主要是数据冷备，即定期将数据复制到某种存储介质上并物理存档保管，如果系统存储损坏，那么就从冷备的存储设备中恢复数据。
    冷备的优点是简单和廉价，成本和技术难度都较低。缺点是不能保证数据最终一致，由于数据是定期复制，因此备份设备中的数据比系统中的数据陈旧，如果系统数据丢失，那么从上个备份点开始后更新的数据就会永久丢失，不能从备份中恢复。同时也不能保证数据可用性，从冷备存储中恢复数据需要较长的时间，而这段时间无法访问数据，系统也不可用。
    因此，数据冷备作为一种传统的数据保护手段，依然在网站日常运维中使用，同时在网站实时在线业务中，还需要进行数据热备，以提供更好的数据可用性。数据热备可分为两种:异步热备方式和同步热备方式。
    传统的企业级关系数据库系统几乎都提供了数据实时同步备份的机制。而一开始就为大型网站而设计的各种NoSQL数据库(如HBase)更是将数据备份机制作为产品最主要的功能点之一。

3.3 失效转移

若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫作失效转移。

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

3.3.1失效确认

判断服务器宕机是系统进行失效转移的第一步，系统确认一台服务器是否宕机的手段有两种:心跳检测和应用程序访问失败报告。

对于应用程序的访问失败报告，控制中心还需要再一次发送心跳检测进行确认，以免错误判断服务器宕机，因为一旦进行数据访问的失效转移，就意味着数据存储多份副本不一致，需要进行后续一系列复杂的操作。

图2 存储服务器失效确认

3.3.2访问转移

确认某台数据存储服务器宕机后，就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器(几台存储服务器存储的数据完全一样，我们称几台服务器为对等服务器，比如主从结构的存储服务器，其存储的数据完全一样)，当其中一台宕机后，应用程序根据配置直接切换到对等服务器上。如果存储是不对等的，那么就需要重新计算路由，选择存储服务器。

3.3.3数据恢复
因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机时，就可能出现无法访问转移(所有副本的服务器都宕机了),数据永久丢失的情况。因此系统需要从健康的服务器复制数据，将数据副本数目恢复到设定值。