阅读了《大型网站技术架构》第五、六、七章后，了解到了这三章分别讲到了是网站的可用性、伸缩性和可扩展性。
先来了解一下可用性。可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时，就出现了系统故障。系统的用户（人或其他系统）可以观察到此类故障。系统可用性是系统正常运行的时间比例。一般将系统可用性定义为：α=平均正常工作时间/（平均正常工作时间+平均修复时间）。有两个著名的例子。2011年4月12日，亚马逊云计算服务EC2发生故障，其ESB服务不可用，故障持续了数天，最终还是有部分数据未能恢复。这一故障导致美国许多使用亚马逊服务的知名网站受到影响，并引发了人们对使用云计算安全性、可靠性的大规模讨论。2010年1月12日，百度被黑客攻击，其DNS域名被劫持，导致百度全站长达数小时不可访问。
网站的伸缩性永无止境。所谓网站的伸缩性，指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。要实现网站的可伸缩性，关键技术就在于如何构建良好的服务器集群。要达到良好的目标，就要求每次扩容和减少服务器时，对整个网站的影响是最小的。CAP原理就是选择强化分布式存储系统的可用性和伸缩性，而在某种程度上放弃一致性。CAP原理对于可伸缩的分布式系统设计具有重要意义，不恰当地迎合各种需求，可能会使设计进入两难境地，难以为继。我们的系统有大量的统计数据。我们的网站随时都有可能进行修改，比如发布新功能，这时就需要在服务器上关闭原有的应用，重新部署新的应用，整个过程要求不影响用户的使用。为了把对用户的影响降低到最小，通常使用发布脚本来完成发布。经过严格的测试，软件部署到服务器还是会出现问题，主要原因就是测试环境和线上环境并不相同，所以我们在网站发布时，要把测试通过的代码先发布到预发布机器上，确认系统没有问题后才正式发布。
可扩展架构是随需而变的。有的网站可以随时发布，新功能随时快速上线，而有的必须规定发布日，究其原因，则依赖于网站的扩展性架构设计。扩展性和伸缩性不同。想起上学期我们做的小系统，可扩展性并不强，加一段代码需要改多个地方，加一个功能需要修改多处的地方，这就是我们没有应用到框架的原因。