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

        网站的页面能完整呈现在最终用户面前，需要经过很多个环节,人一个环节出了问题,都可能导致网站不可访问。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、推迟绑定时间：运行时注册；配置文件；多态；组件更换；遵守已定义的协议；