这三章主要强调了网站架构应具有高可用性、伸缩性和可扩展性。
第5章主要讲述了网站的架构的高可用性。要保证一个网站永远完全可用几乎是一件不可能完成的任务。业界通过一个多少个9来度量网站可用性，采用故障分来考核网站可用性。可用性指标是网站架构设计的重要指标，网站可用性看得见，摸得着，跟技术、运营、相关各方的绩效考核息息相关。一个典型的网站设计遵循基本分层架构模型即应用层、服务层、数据层。应用层主要负责具体业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储和访问。网站的可用性架构设计不但考虑实际的硬件故障引起的宕机，还要考虑网站升级发布引起的宕机。高可用的服务策略包括分级管理、超时设置、服务降级（关闭非核心服务）等。高可用的数据是最宝贵的资产，保证数据存储高可用的手段主要是数据备份和失效转换机制。数据备份可以实现数据完全的持久化，失效转换机制是为了保证系统可用。对公司而言，可用性关系到网站的生死存亡，对个人而言，可用性关系到个人绩效升迁。所以保证网站可用，任重而道远。
对于我们正在设计的系统，就可用性方面而言，我觉得可以添加一个删除之后可以恢复的功能。新建一个日志功能，方便用户或者设计者找到网站的缺陷。然后，就易用性方面而言。我觉首先应该优化一下填报界面得javaScript代码。保证代码的准确性。并使其处理速度更快。
第6章主要讲了网站架构的伸缩性，所谓网站架构的伸缩性，就是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。要实现网站的可伸缩性，关键技术就在于如何构建良好的服务器集群。要达到良好的目标，就要求每次扩容和减少服务器时，对整个网站的影响是最小的。CAP原理就是选择强化分布式存储系统的可用性和伸缩性，而在某种程度上放弃一致性。CAP原理对于可伸缩的分布式系统设计具有重要意义，不恰当地迎合各种需求，可能会使设计进入两难境地，难以为继。我们的系统有大量的统计数据。我们的网站随时都有可能进行修改，比如发布新功能，这时就需要在服务器上关闭原有的应用，重新部署新的应用，整个过程要求不影响用户的使用。为了把对用户的影响降低到最小，通常使用发布脚本来完成发布。经过严格的测试，软件部署到服务器还是会出现问题，主要原因就是测试环境和线上环境并不相同，所以我们在网站发布时，要把测试通过的代码先发布到预发布机器上，确认系统没有问题后才正式发布。
一个具有良好伸缩性架构设计的网站，其设计总是走在业务发展前面，在业务需要处理更多访问和服务之间，就已经做好充足准备，当业务需要时，只需要购买和租用服务器简单部署实施即可，技术团队亦可以高枕无忧。
就我们的系统而言，由于访问的用户不会太多。所以可伸缩的设计在这里不做过多的阐述。
第7章主要讲了网站架构的可扩展性，所谓可扩展性，是指对现有系统响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。我们想要是网站架构具有可扩展性。开发的低耦合是必要的条件。低耦合的系统更容易扩展，低耦合的模块更容易服用，一个低耦合的系统设计也会让开发也会让开发过程和维护变得更加轻松和容易管理。大型网站通常使用分布式消息队列降低系统的耦合性。并利用分布式服务打造可复用的业务平台。在数据库的使用上，使用的是支持ColumnFamily结构的NoSQL数据库，创建表的时候，只需要制定ColumnFamily的名字，无需制定字段，可以再数据写入再指定，通过这种方式，数据表可以包含数百万的字段，使用应用程序数据结构可以随意扩展。而在查询时，可以通过指定任意字段的名称和值进行查询。
一个具有扩展性架构的网站，可以更快的开发新产品。开发的效率大大的提高。
就我们自己的系统而言，可扩展性的设计主要就是让每个文件的所要实现功能单一。即一个文件只负责一个功能。并将它单独封装在一个类中。这样我们需要什么功能，直接调用封装好的类就可以。不仅提高了效率。而且让我们的源代码更加有序。