通过阅读《大型网站技术架构：核心原理与案例分析》的第五、六、七章，对网站的可用性和修改性战术有了进一步的理解，接下来就来谈谈我的认识。
网站的可用性描述网站可有效访问的特性。相比于网站的其他非功能特性，网站的可用性更牵动着人们的神经，大型网站的不可用事故直接影响公司形象和利益，许多互联网公司都将网站可用性列入了工程师的绩效考核，与奖金升迁等利益挂钩。
网站不可用也被称作网站故障，业界通常用多少个9来衡量网站的可用性，如QQ的可用性是4个9，即QQ服务99.99%可用，这意味着QQ服务器要保证其在所有运行时间中，只有0.01%的时间不可用，也就是一年中大约最多53分钟不可用。由于可用性影响因素很多，对于网站整体而言，达到4个9，乃至5个9的可用性，处理过硬的技术，大量的设备资金投入和工程师的责任心，还要有个好运气。
可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面，可用性指标是网站或者产品的整体考核指标，具体到每个工程师的考核，更多的是使用故障分。故障分=故障时间（分钟）X 故障权重。有时候一个故障责任可能由多个部门或团队来承担，故障分也会相应按责任分摊到不同的团队和个人。
不同于其他架构指标，网站可用性更加看得见摸得着，跟技术、运营、相关各方的绩效考核息息相关，因此在架构设计与评审会议上，关于系统可用性的讨论与争执总是最花费时间与精力的部分。
通常企业级应用系统为提高系统可用性，会采用较昂贵的软硬件设备。实现高可用架构的主要手段是数据和服务的荣誉备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份到磁盘读取数据。
网站升级的频率一般都很高，大型网站一周发布一次，中小型网站一天发布几次。每次网站发布都需要关闭服务，重新部署系统，整个过程相当于服务器宕机。因此网站的可用性架构设计不但要考虑实际的硬件故障引起的宕机，还要考虑网站审计发布引起的宕机，二后者更加频繁，不能因为系统可以接受偶尔的停机故障就降低可用性设计的标准。
应用层主要处理网站应用的业务逻辑，因此有时也称作业务逻辑层，应用的一个显著特点就是应用的无状态性。由于负载均衡在应用层实际上起到了系统高可用的作用，因此即使某个应用访问量非常少，只用一台服务器提供服务就绰绰有余，但如果需要保证该服务器高可用，也必须至少部署两台服务器，使用负载均衡技术个欧建一个小型的集群。
可复用的服务器模块为业务产品提供基础公共服务，大型网站中这些服务通常都独立分布式部署，被具体应用远程调用。可复用的服务和应用一样，也是无状态的服务，因此可以使用类似负载均衡的失效转移策略实现高可用的服务。除此之外，具体实践中，还有以下几点高可用的服务策略。1）分级管理 2）超时设置 3）异步调用 4）服务降级 5）幂等性设计
回顾网站架构发展历程，网站架构发展史就是一部不断向网站添加服务器的历史。只要工程师能向网站的服务器集群中添加新的机器，只要新添加的服务器能线性提高网站整体服务处理能力，网站就无需为不断增长的用户和访问而焦虑。
将不同功能分离部署可以实现一定程度的伸缩性，但是随着网站访问量的逐步增加，即使分离到最小力度的独立部署，单一的服务器也不能满足业务规模的要求。因此必须使用服务器集群，即将相同服务部署在多态服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又可分为应用服务器集群伸缩性和数据服务器集群伸缩性。
开发低耦合系统是软件设计的终极目标之一，这一目标驱动着软件开发技术的创新与发展，从软件与硬件的第一次奋力到操作系统的诞生；从汇编语言到面向过程的开发语言，砸到面相对对象的编程语言。可以说，度量一个开发框架、设计模式、编程语言优劣的重要尺度就是衡量它是不是让软件开发过程和软件产品更加低耦合。
网站通过不断失措，在残酷的市场中找到自己的竞争优势，持续的退出新功能，发现达不到预期，就立马下线。多以我们看到网站是不停的推出新功能，发布新产品。