对于xx系统，可以说写好也只是一堆堆积的代码罢了，并不能说有什么特别的可用性，但就是对于这样的系统可改的地方才是最大的。之前什么都没有用只是对于jsp的简单使用，比如说一些跳转啊，判定啊，偶尔用了几个servlet，这些都是最基本的了，包括对于数据库的访问，也仅仅是用代码实现的。 可用性的定义：如何检测系统故障、系统故障发生的频度、出现故障时会发生什么情况、允许系统有多长时间非正常运行、什么时候可以安全的出现故障、如何防止故障的发生以及发生故障时要求进行那种通知。高可用架构是万无一失的。要保证一个网站永远完全可用几乎是一件不可能完成的任务。我们通过一个神奇的数字9来度量网站可用性，采用故障分来考核网站可用性。可用性指标是网站架构设计的重要指标，网站可用性看得见，摸得着，跟技术、运营、相关各方的绩效考核息息相关。一个典型的网站设计遵循基本分层架构模型即应用层、服务层、数据层。应用层主要负责具体业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储和访问。网站的可用性架构设计不但考虑实际的硬件故障引起的宕机，还要考虑网站升级发布引起的宕机。高可用的服务策略包括分级管理、超时设置、服务降级（关闭非核心服务）等。高可用的数据是最宝贵的资产，保证数据存储高可用的手段主要是数据备份和失效转换机制。数据备份可以实现数据完全的持久化，失效转换机制是为了保证系统可用。保证网站高可用，万无一失，是一个艰难的过程，还需要更多努力。对于我们的系统，可用性真是不敢想，因为没有投入使用过，唯一一次还是让学弟们使用，照样还是出现问题的人居多。对于一个系统来说，想万无一失真的太难太难，需要我们的精心雕琢，这样真的是可行的么？
第六章提到了网站的收缩性，就是通过改变部署的服务器就可以扩大和缩小网站的服务器的处理能力。就像淘宝在双十一的问题当中，因为人员的突然的增加，就需要进行网站的收缩性。网站的伸缩性永无止境。所谓网站的伸缩性，指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。要实现网站的可伸缩性，关键技术就在于如何构建良好的服务器集群。要达到良好的目标，就要求每次扩容和减少服务器时，对整个网站的影响是最小的。CAP原理就是选择强化分布式存储系统的可用性和伸缩性，而在某种程度上放弃一致性。CAP原理对于可伸缩的分布式系统设计具有重要意义，不恰当地迎合各种需求，可能会使设计进入两难境地，难以为继。我们的系统有大量的统计数据。我们的网站随时都有可能进行修改，比如发布新功能，这时就需要在服务器上关闭原有的应用，重新部署新的应用，整个过程要求不影响用户的使用。为了把对用户的影响降低到最小，通常使用发布脚本来完成发布。经过严格的测试，软件部署到服务器还是会出现问题，主要原因就是测试环境和线上环境并不相同，所以我们在网站发布时，要把测试通过的代码先发布到预发布机器上，确认系统没有问题后才正式发布。我们的系统只是一个问卷系统，可以说是很简单的了，能做的优化依旧很多，伸缩性上面现在无非就是能加一些功能，其实也就是多一个接口而已，耦合度不是很高。
可扩展架构是随需而变的。有的网站可以随时发布，新功能随时快速上线，而有的必须规定发布日，究其原因，则依赖于网站的扩展性架构设计。扩展性和伸缩性不同。扩展性是指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。它是系统架构设计层面的开闭原则，架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。设计网站可扩展架构的核心思想是模块化，并在此基础上，降低模块间的耦合性，提供模块的复用性。
我们的系统要做到这几点，架构上需要重建，进一步的明确各个部分的关联和降低耦合。