本次重点阅读了第五、六、七章。
系统的可用性是十分重要的，第五章介绍了网站的高可用性架构，甚至用上了万无一失这样的字眼。可用性体现了系统故障的多少以及出现故障后恢复的速度，一个的不可用时间越短，网站的可用性就越高。网站的可用性可以用多少个9来度量。虽然一个网站不可能是完全可用的，但我们可以尽力去做一些事情去完善。因而，高可用架构的主要目的就是保证服务器硬件故障时服务依然可用，数据依然能被访问。实现高可用架构的主要目的就是数据和服务的冗余备份及失效转移，也就是服务器的切换以及读取备份磁盘的数据。网站设计基本上遵循应用层、服务层、数据层这样的三层架构，各层之间具有相对独立性，保证了网站的可维护性。随着网站的复杂性的提高，可能粒度会越来越细，但是大体上都离不开这三层结构。不同层次结构的服务器具有不同的可用性特点，因而解决方案也不同。
位于应用层的服务器情况和应用层的服务器，会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务，当某个服务器不可用时，将其剔除并将请求分发给其他可用的服务器上，使整个集群可用（因为无状态性）。位于服务层的服务器也是通过集群方式，但是通过分布式服务调用框架访问。还有几项策略，如：分级管理，超时设置，异步调用，服务降级，幂等性设计等。位于数据层的服务器需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。通过阅读了解到了原来每一次网站的升级都是要关闭服务重新部署的，此时的服务器宕机，因此可用性架构设计还要考虑到这一点。
但是为了保证数据的高可用，网站通常会牺牲另一个也很重要的指标：数据一致性。CAP原理是说一个提供数据服务的存储系统无法同时满足数据一致性、数据可用性和分区耐受性。需要进行补偿和纠错，避免出现应用系统数据不正确。网站可用性在发布、监控上也有自己的一些策略。
网站的伸缩性，往往是和可用性、正确性、性能等耦合在一起。早期是通过物理分离实现，后期在各个层次结构上有不同的处理方法要实现网站的可伸缩性，关键技术就在于如何构建良好的服务器集群。要达到良好的目标，就要求每次扩容和减少服务器时，对整个网站的影响是最小的。一个具有良好伸缩性的网站，其设计总是走在业务发展的前面，在业务需要处理更多访问和处理之前，就已经做好了充分的准备，当业务需要时，只需要增加服务器并简单部署就可以了，技术团队便可轻松应对了。
接下来可扩展架构，一开始在阅读伸缩性的时候我就把伸缩性理解成了扩展性。不过接下来书中解释了概念。扩展的一个关键就是系统要低耦合，低耦合的模块更容易复用。如何分解成一个个低耦合的独立模块对于架构师来说十分重要。扩展性是随着需求的变化而变化的。可以利用分布式消息队列降低系统耦合性，如事件驱动架构等。还要有可扩展的数据结构，传统的关系型数据库设计不利用扩展，而NoSQL数据库使用的列族设计即可以做到可扩展的数据结构设计。可以在数据写入时再指定，使数据结构可以随意扩展。
针对我们上学期做的系统，首先我们系统的易用性就不是很好，界面不够友好，操作不够便利。因而要尽量提高系统的易用性，给用户良好的人际交互体验。一部分流程还没有很科学。在可用性方面，由于目前是本机同时做客户机和服务器，用户只有我们自己并且只有简单的几条测试数据，并不会出现故障，但随着并发度的提高一定会出现许多故障。既然我们现在不能使用租用服务器等措施，我们可以尽量减轻tomcat服务器的负担，加快它的响应速度。在数据层，对数据库进行备份。写脚本文件时也要尽可能优化算法，使算法效率更高。