结合某某系统分析系统的可用性和易用性

     这是我第二次读大型网站技术架构的5，6，7，章，了解了网站的可用性描述网站可有效访问的特性，不同于另一个网站运营指标Usability,通常也被译作可用性，但是后者强调的是网站的有用性，即对最终用户的使用价值，以前对网站的有用性不甚了解，以为系统能满足用户的需求就是达到了有用性，网站不可用也被称作为网络故障，业界通常用多少个9来衡量网站的可用性，对于一个网站来说，故障时间等于故障修复时间点减去故障发现时间点。可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标，从管理层面，可用性指标是网站或者产品的整体考核指标，具体到每个工程师的考核，更多的是使用故障分。

    所谓故障分是指对网站故障进行分类加权计算故障责任的方法，网站可用性更加看得见，摸得着，跟技术，运营，相关各方的绩效考核息息相关，因此在架构设计与评审会议上，关于系统可用性的讨论与争执总是最花费时间与精力的部分。

      对于此系统的可用性也挺多的，位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证服务器数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据备份，当服务器死机时将其转换到有备份数据的服务器上。由于此系统主要是对数据的提交保存，审核以及统计等等功能，但是此系统没有对数据的备份还原等功能，因此这是一个缺陷，所以说此系统必须要有这个功能，每天定时对系统进行备份。

      扩展性是指现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。他是系统架构设计层面的开闭原则，对扩展开放，对修改关闭，架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。伸缩性指系统通过增加自身资源规模的方式减少自己计算处理事务的能力。如果这种增减是成比例的，就被称作线性伸缩性。在网站架构中，通常指利用集群的方式增加服务器数量，提高系统的整体事务吞吐能力。开发低耦合系统是软件设计的终极目标之一，这一目标驱动着软件开发技术的创新与发展，从软件与硬件的第一次分离到操作系统的诞生，从汇编语言到面向过程的开发语言，再到面向对象的编程语言，从各种软件工具集到各种开发框架，无不体现着降低软件系统耦合性这一终极目标，可以说，度量一个开发框架，设计模式，编程语言优劣的重要尺度就是衡量它是不是让软件开发过程和软件产品更加低耦合。

     显而易见，低耦合更容易扩展，低耦合的模块更容易复用，一个低耦合的系统设计也会让开发过程和维护变得更加轻松和容易管理。一个复杂度为100的系统，如果能够分解成没有耦合的两个子系统，那么每个子系统的复杂度不是50，而可能是25.当然，完全没有耦合就是没有关系，也就无法组合出一个强大的系统。大型网站也常常意味着功能复杂，产品众多，网站为了在市场竞争中取胜，不断推出各种新产品，为了把握市场机会，这些产品从策划到上线，时间非常短暂，技术团队必须在产品设计和需求分析结束之后，快速的开发完成一个新产品。同时经过长期的演化和发展，这些产品之间的关系错综复杂，维护也变得异常困难。这些问题对网站的扩展架构提出了挑战和要求。队列是一种先进先出的数据结构，分布式消息队列可以看作将这种数据结构部署到独立的服务器上，应用程序可以通过远程访问接口使用分布式消息列队，进行消息存取操作，进而实现分布式的异步调用，消息生产者应用程序通过远程访问接口将消息推送给消息队列服务器，消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。消息队列服务器根据订阅列表查找订阅该消息的消息消费者应用程序，将消息队列中的消息按照先进先出，进行操作。

结合某某系统分析系统的可用性和易用性