大型网站架构读后感

       这周我们开始学习这两个方面的内容了。老师上课的时候讲到了可用性和易用性。然后提到了大型网站架构的第5、6、7章，通过对这三章的扩展阅读，也有了一些自己的认识，对于自己之的作业也有了不同的看法，当时认为自己做得已经很出色了，现在想想，很多实际的功能还有纰漏的地方。根据文章中的内容，我们需要从可用性，易用性，可扩展性方面着手。

      首先我们了解一些可用性。可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时，就出现了系统故障。系统的用户可以观察到此类故障。有两个著名的例子。书中有两个涉及到可用性崩溃的较为著名的例子，一是2010年1月12日，百度被黑客攻击，其DNS域名被劫持，导致百度全站长达数小时不可访问。2011年4月12日，亚马逊云计算服务EC2发生故障，其ESB服务不可用，故障持续了数天，最终还是有部分数据未能恢复。

 

       对于实发性的项目，都有一个可用性的度量，也就是对于网的可用性的考核。对于一个系统来说，当然是可用性越高越好。可用性度量的通常用几个9来衡量，对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站的年度不可用时间小于53分钟，比如QQ就是4个9，QQ服务99.99%可用，这意味着保证其服务的在所有运行时间中，不可用的时间小于0.01%，一年中的不可用时间少于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。其计算方式为：

      网站不可用时间=故障修复时间点-故障发现时间点

      网站年度可用性指标=（1-网站不可用时间/可用时间）*100%

      可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面，可用性指标是网站架构或产品的整体考核指标。由于可用性影响因素很多，对于网站整体而言，要达到高可用性，除了过硬的技术、大量的设备资金投入和工程师的责任心，还要有很好的运气。

      举个最简单的实发性项目的例子，上学期我们做过的《XXX系统》。之前的时候，同学们都自己开发者这个网站，以为说所有的瑕疵都已经解决了，我也是这样，实际上等到那天审查的时候，才发现有几个地方还没有解决。因为可能使用那个系统的同学操作的方式跟我们测试的时候不太一样，因此发现了一些我们不曾发现的错误。好多同学的系统甚至会跳到apache的网页。当出现崩溃的时候，没有解决方案，解决方法就是最古老的，开发的同学去亲自修改代码。用可用性标准来衡量，跟1个9都差了十万八千里，可用性无限接近于0%。

      接下里了解一下易用性。易用性与用户完成期望任务的难易程度以及系统为用户提供的支持种类有关。说得通俗一点，易用性是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。拿我们自己开发的系统来说，易用性是做到了，因为功能实在是太少了，基本上没有什么复杂的功能。但是有一个重要的问题要注意，易用性要基于可用性的实现，就好比功能再简单的《XXX系统》，停留在不能使用的apache页面，也就不存在什么易用性之说了。     

       说到这里，我想到了大家平常都有使用的软件——QQ。身边好多的朋友都喜欢用轻聊版的QQ，甚至说微信，自己的家长那种年龄的用户也喜欢用微信，究其原因，他们觉得相比而言，微信的功能要简单一些，易于操作，QQ上一些兴趣部落啊之流的内容，不能说是毫无用处，相比起最重要的功能来说，还是有些画蛇添足。

对于扩展性，就是在对现有系统影响最小的情况下，系统可持续扩展和提升的能力。在系统做的比较大的时候，利用可扩展性，可以较快速地扩展系统的功能。

       阅读完这些内容，我觉得做一个系统的时候，不能一开始就卯足了劲去实现其功能，应该先考虑其质量属性，还有数据库的设计备份等等，先做好准备工作再下手，能够减少实现过程的多次推到重做。