阅读《大型网站技术架构：核心原理与案例分析》第五、六、七章，结合《XXX重大技术需求征集系统》，列举实例分析采用的可用性和可修改性战术，将上述内容撰写成一篇1500字左右的博客阐述你的观点。

　　这三章主要讲述的是网站的可用性、伸缩性和可扩展性。

　　首先，网站的可用性描述网站可有效访问的特性，相比于网站的其他非功能特性，网站的可用性更容易引起人们的注意，尤其是大型网站的可用性，如果大公司的网站出现错误或者不能登录上去，不但会影响人们的浏览，而且也会给公司带来不可想象的经济损失。但是要保证一个网站永远完全可用几乎是一件不可能完成的任务。我们通过一个神奇的数字9来度量网站可用性，采用故障分来考核网站可用性。可用性指标是网站架构设计的重要指标，网站可用性看得见，摸得着，跟技术、运营、相关各方的绩效考核息息相关。一个典型的网站设计遵循基本分层架构模型即应用层、服务层、数据层。应用层主要负责具体业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储和访问。网站的可用性架构设计不但考虑实际的硬件故障引起的宕机，还要考虑网站升级发布引起的宕机。高可用的服务策略包括分级管理、超时设置、服务降级（关闭非核心服务）等。高可用的数据是最宝贵的资产，保证数据存储高可用的手段主要是数据备份和失效转换机制。数据备份可以实现数据完全的持久化，失效转换机制是为了保证系统可用。保证网站高可用，万无一失，是一个艰难的过程，还需要更多努力。

　　相比较我们在去年的软件工程概论的课程中所编写的《XXX重大技术需求征集系统》来说，可用性基本为0，所编写的这个系统，只是我们个人的成果而已，对于其中的联网、测试、发布等并没有进行相应的操作，总的来说就是一个空壳子系统，并没有很大的实际应用。同时，自身的系统还需要不断的完善，良好的界面风格，简单便捷的操作，合理的结构布局，以及适当的错误信息提示和网站的反应速度都要进一步的优化。

　　其次，描述的就是网站的伸缩性。所谓网站的伸缩性，指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。要实现网站的可伸缩性，关键技术就在于如何构建良好的服务器集群。要达到良好的目标，就要求每次扩容和减少服务器时，对整个网站的影响是最小的。CAP原理就是选择强化分布式存储系统的可用性和伸缩性，而在某种程度上放弃一致性。CAP原理对于可伸缩的分布式系统设计具有重要意义，不恰当地迎合各种需求，可能会使设计进入两难境地，难以为继。我们的系统有大量的统计数据。我们的网站随时都有可能进行修改，比如发布新功能，这时就需要在服务器上关闭原有的应用，重新部署新的应用，整个过程要求不影响用户的使用。为了把对用户的影响降低到最小，通常使用发布脚本来完成发布。经过严格的测试，软件部署到服务器还是会出现问题，主要原因就是测试环境和线上环境并不相同，所以我们在网站发布时，要把测试通过的代码先发布到预发布机器上，确认系统没有问题后才正式发布。

　　《XXX重大技术需求征集系统》的伸缩性为0，其中涉及到了服务器的数量，基本就是在个人机上来运行的，没有尝试过在多台服务器上运行，所以对于网站的伸缩性了解的不多。

　　最后，讲解的是网站的可扩展性。对于可扩展性来说，是随需而变的。有的网站可以随时发布，新功能随时快速上线，而有的必须规定发布日，究其原因，则依赖于网站的扩展性架构设计。扩展性和伸缩性不同。扩展性是指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。它符合系统架构设计层面的开闭原则，架构设计考虑到了系统未来的功能扩展，即当系统需要增加新的功能时，不需要对系统的原有代码进行编辑和修改或者不需要对源代码进行较大的改动。其设计的核心思想是模块化，并在此基础上，降低模块的耦合性，提供模块的复用性。

　　这一特性对于所写的《XXX重大技术需求征集系统》来说，还是有一些熟悉的，因为在编写的过程中，对系统进行了多次的修改，页面的设计、功能的增加、角色的管理、按键以及相应的提示信息都根据所给的编写文档进行了多次的修改，每次都尽量使新增和修改的代码在少数，能最大程度的减少自己的工作量。

　　网站的可用性、伸缩性和可扩展性，在很多方面影响着网站的质量，一个优秀的网站，不仅能给用户带来很好的体验，也可以为公司创造出巨大的利润，但是要想把网站维护的更加完美，还需要不断的去努力，公司的资金投入、工程师认真负责的态度以及相应的运气，都是必不可少的条件。