首页 > 其他 > 详细

简要分析《XXX需求征集系统》采用的可用性和可修改性战术

时间:2018-03-22 22:07:35      阅读:219      评论:0      收藏:0      [点我收藏+]

        网站的页面能完整呈现在最终用户面前,需要经过很多个环节,人一个环节出了问题,都可能导致网站不可访问。DNS会被劫持,网卡会送掉,程序有Bug等等,要保证一个网扎很难永远完全可用几乎是一件不可能完成的使命。

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

度量

1. 业界通常用多少个9来衡量网站可用性。

2. 网站不可用也称网站故障。

3. 网站不可用时间公式:网站不可用时间(故障时间)= 故障修复时间点-故障发现(报告)时间点

4. 网站年度可用性指标公式:网站年度可用性指标 =(1-网站不可用时间/年度总时间)×100%

考核

1. 故障分:对网站故障进行分类加权计算故障责任的方法。

2. 网站故障分类权重表(示例)

3. 故障分公式:故障分=故障时间(分钟)×故障权重

4. 考核过程:年初或考核季度开始时,根据网站产品可用性指标计算总的故障分,然后根据团队和个人职责角色分摊故障分,这个可用性指标和故障分是管理预期;故障发生后,根据故障分类和责任划分给故障产生的故障分分配给责任者承担;年末或考核季度末时,个人及团队实际承担的故障分如果超过年度分摊的故障分,绩效考核受到影响。

网站架构高可用

1. 以《XXX需求征集系统》为例。

    a) 应用层:需求征集系统。

    b) 服务层:应用层产品依赖共同的复用业务,这些业务服务各自部署集群。

c) 数据层:各自部署集群。

2. 实现高可用架构主要手段:数据和服务的冗余备份及失效转移。

3. 应用层高可用:通过负载均衡设备将一组服务器组成一个集群对外处理高并发请求,负载均衡设备通过心跳检测等手段监控到应用服务器不可用时,将其从集群列表剔除,请求分发到集群其他可用服务器上。

4. 服务层高可用:也是通过集群实现高可用。服务层被应用层通过分布式服务调用框架访问,分布式服务调用框架在应用层客户端中实现负载均衡,服务注册中心获取服务层服务器心跳检测,发现不可用服务器,立即通知客户端修改服务层访问列表,剔除不可用服务器。

5. 数据层高可用:数据写入时同步复制数据到多台服务器上,实现数据冗余备份;数据服务器宕机时,数据访问切换到备份数据服务器上。

6. 网站升级发布可能引起故障。

可用性战术:

1、错误检测:命令/响应;心跳(dead man 计时器);异常;

2、错误恢复-检测和修复:表决;主动冗余(热重启);被动冗余(暖重启/双冗余/三冗余);备件;

3、错误恢复-重新引入:shadow操作;状态再同步;检查点/回滚

4、错误预防:从服务中删除;事务;进程监视器

 

    很多时候,随着时间的变化,或者用户提出了更高的实用要求,我们需要更快速地对系统进行更新优化,同时也要控制实现、测试和部署变更的时间和成本

2.可修改性战术

扩展性与伸缩性

    以《XXX需求征集系统》为例。

   伸缩性:将独立的模块分别部署,如填报,需求征集,需求审核,需求浏览等等模块进行分层分割,形成各自独立的功能模块,在对单独模块功能进行调整的时候,通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。

扩展性:需求征集系统在对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力。系统可添加相对应的需求功能,如报表查看,分类浏览等等功能。

构建可扩展的网站架构

1. 设计网站可扩展架构的核心思想是模块化,并在此基础上降低模块间的耦合性,提高模块复用性。

2. 模块化的重要手段:分层和分割,分层、分割为若干个低耦合的独立组件模块(模块可分布式部署,从物理上分离模块间耦合),各模块以消息传递及依赖调用方式聚合成完整系统。

可修改性战术

控制可修改性的战术,其目标是控制实现、测试和部署变更的时间和成本。

1、局部化变更:维持语义的一致性;预期期望的变更;泛化该模块;限制可能的选择;抽象通用服务;

2、防止连锁反应:信息隐藏;维持现有的接口;限制通信路径;仲裁者的使用;

3、推迟绑定时间:运行时注册;配置文件;多态;组件更换;遵守已定义的协议;

 

 

 

 

简要分析《XXX需求征集系统》采用的可用性和可修改性战术

原文:https://www.cnblogs.com/xxdcxy/p/8626782.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!