《XXX重大技术需求征集系统》的可用性和可修改性战术分析

在网站的界面完整有效的呈现在最终用户面前前，其中经历的每一环节出现问题都会导致网站页面不可访问。原因如，如DNS被劫持、网站交换机失效，硬盘损坏，网卡松掉，机房停电等都可能导致网站不可用(网站故障)情况出现。通常用多少个9来度量网站可用性，如QQ可用性99.99%，就意味着在一年中约有53分钟是不可用的。对于多数网站2个9是最基本的要求，即一年中要求不可用时间得小于88个小时。考核可用性通常用故障分类加权计算而得。具体参照“网站故障分类权重表示例”表。

可用性的作用是显而易见的，在上学期制作的XXX重大技术需求征集系统中，当应对快速增长的用户数量，以及业务数量是，并不能很好的应对，甚至是处理能力很低。当应对这样的情况，也会发生数据丢失，服务不可用的情况，所以我的网站可用性是很低了。在预防数据丢失方面，可以在数据写入是同时进行复制同步将数据写入多台服务器实现冗余备份，当然目前实现是有困难的。

高可用性，一方面需要较高配置的软硬件设备如服务器、操作系统等，不同的产品部署到不同的服务集群上、互不相干，一些可复用的业务服务也各自部署在独立的服务集群上，这样实现高可用性，使得软件负载均衡，发现服务异常时会剔除掉不可用服务器。另一方面也需要有数据和服务的冗余备份和失效转移技术方面，在我的系统中并没有考虑数据备份相关问题，所以如果直接投入使用，用户定会丢失数据；在另一方面我使用的是jsp+servlet的mvc模式，各层之间具有相当的独立性，但是同时在项目的中后期我发现自己的dao层显得有些许混乱，每个函数划分得不够精确，结构显得复杂。阅读过程中，发现大型网站架构划分的粒度会更小、更详细，同样结构也会更复杂，所以我认为之后的练习过程中，应当严格要求自己多做一点多想一点。

在第一个方面，通过负载均衡使流量和数据分摊到一个集群的多台服务器上提高整体的负载处理能力，来处理服务无状态时的情况。如一个服务集群上的服务器都可用时，负载均衡服务器会将用户发送的访问请求发送到任意一个服务器上进行处理，当一个服务器发生宕机时，负载均衡服务器会通过心脏检测机制发现这台服务器已经失去了响应，则把它从服务器列表中剔除，将请求发送给别的服务器，这些服务器是完全一样的，发送给任何一台都不会影响结果。而在业务有状态时，使用服务器集群的SESSION管理。1.session复制，我认为和数据冗余备份一样，将session信息复制同步到集群中的几台服务器中，但是不足之处当集群规模较大时，大量复制会导致占用资源，这就显得不够优秀哦。2. session绑定，我认为就像学校邮件处理室一样，信息学院想要的信件就放在信息院柜中；负载均衡服务器将源于同一IP的请求分发到同一台服务器上，这样用户的所有请求都在这台服务器上处理，保证了session总能在这台服务器上获取。但是如果信息院柜子满了或者坏了，信息院信件就会找不到，同样，如果该服务器发生宕机，该服务器上的session也就不存在了，还是不够优秀哦。3.利用cookie记录session，在网站中利用浏览器支持的cookie记录session，虽然在信息量和性能方面不优秀但是简单易用，也能使用。

前3个办法中，我的系统中关于服务器的每一个有，所以性能！！很不可观！！唯有cookie这个方便简单，还是有的。基于上面的不完美，阅读得知，session服务器可以达到对信息量大小和延展性等方面都不错的管理。第一种session复制不能处理有状态时的情况，所以现在将服务器状态分离，分为有状态和无状态。第二个方面，保护网站数据。通过保证数据备份和失效转移机制，即失效转移机制，保证数据有多个备份，任意副本丢失失效都不会导致数据永久都是，实现数据的完全持久化。

 

------------------------分割线----------------------

今天进行了答辩，针对我的系统，有如下分析：

 

六大属性：安全性，可修改性，可测试性，易用性，安全性，性能

 

一 可用性--指的是应对故障和相关后果

错误被人看到时就升级为故障，引出修复时间--错误发生到用户看不到故障前的纠正错误的时间。

战术：从源头上预防错误，错误一发生就被检测到，检测到就马上去进行错误恢复。

举例：

1.try-catch机制，避免错误被检测

 

二 可修改性--指的是进行变更所带来的成本问题

主要讨论2个方面  有谁来进行什么样的变更

战术：减少变更直接影响到的模块数量---局部化修改，限制变更模块---防止连锁反应。

举例：

1.连接数据库的方法--减少变更代价--局部化修改中的泛化该模块，通过输入参数来通用   2.MVC模式--减少各部分之间的依赖关系--局部化修改--维持语义的一致性

 

三 性能--指的是当源达到一定数量时的响应，通常用时间来衡量

战术：1.环境上资源的消耗如CPU/内存/宽带  2.对资源争用或等依赖的事件

举例：

1.审核成功的报表不能进行修改----闭锁时间--依赖于一个结果导致不可用某个资源

2.未实现~~~~~如限制上限人数，加大内存等

3.缓存器/排队

 

四 安全性--指的是1.提供合法用户的服务 2.非授权操作

安全性指的是认可、机密性、完整性和正确性

战术：由于主动让攻击不进行，所以在抵抗攻击，检测攻击和从攻击中恢复三个方面

抵抗攻击---防御：如用户密码加密，身份验证，授权，重要数据加密，维护数据完整性(备

份），限制暴露信息，限制访问

举例：

1.用户未登录限制行为   2.用户密码MD5加密   3不同角色/用户授权不同行为

 

五 可测试性--指的是通过测试发现缺陷的容易度

目的是允许开发了一个增量后，可轻松的进行软件测试

战术：1.输入输出（记录回放   将接口与实现分离   特化访问路线/接口）  2.内部监视器

举例：

1.在dao与servlet的调用之间使用多个print输出传递和接收的数据---记录/回放--捕获跨接口的信息

 

六易用性--对用户来说 1.主动完成任务的难易度  2.系统所提供的用户的种类

战术：

使用时-从用户使用来看系统帮助用户处理事务，如用户模型（抓住用户特点信息，如看书速度滚动），系统模型（基于系统信息，确定了期望的系统行为给用户反馈），任务模型（试图通过一个任务上下文，确定用户想要做什么）

设计时-从开发人员来看不希望在修改内部时不希望还要改变用户界面---分离用户接口和应用部分（模型-视图-控制器 / 表示层-抽象层-控制）

举例：

1.用户填写时自动获取几个基本信息--用户模型

2.提示用户填报规则----便于完成填报

3.填写取消---支持用户主动