■ 正文
网站的可用性（Availability）描述网站可有效访问的特性（不同于另一个网站运营指标：Usability，通常也被译作可用性，但是后者强调的是网站的有用性，即对最终用户的使用价值），相比于网站的其他非功能特性，网站的可用性更牵动人们的神经，大型网站的不可用事故直接影响公司形象和利益，许多互联网公司都将网站可用性列入工程师的绩效考核，与奖金升迁等利益挂钩。
1.1 网站可用性的度量与考核
1.1.1 网站可用性度量
1) 网站不可用也被称作网站故障，业界通常用多少个9来衡量网站的可用性，如QQ的可用性是4个9，即QQ服务99.99％可用，这意味着QQ服务要保证其在所有运行时间中，只有0.01％的时间不可用，也就是一年中大约最多53分钟不可用。
2) 网站不可用时间（故障时间）＝ 故障修复时间点 – 网故障发现（报告）时间点
3) 网站年度可用性指标＝（网站不可用时间 / 年度总时间）* 100％
4) 对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。
5) 由于可用性影响因素很多，对于网站整体而言，达到4个9，乃至5个9的可用性，除了过硬的技术、大量的设备资金投入和工程师的责任心，还要有个好运气。
1.1.2 网站可用性考核
1) 可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面，可用性指标是网站或者产品的整体考核指标，具体到每个工程师的考核，更多的是使用故障分。
2) 
1.2 高可用的网站架构
1) 实现高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据
1.3 高可用的应用
1) 应用层主要处理网站应用的业务逻辑，因此有时也称作业务逻辑层，应用的一个显著特点是应用的无状态性。
2) 所谓无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。
1.3.1 通过负载均衡进行无状态服务的失效转移
1) 不保存状态的应用给高可用的架构设计带来了巨大便利，既然服务器不保存请求的状态，那么所有的服务器完全对等，当任意一台或多台服务器宕机，请求提交给集群中其他任意一台可用机器处理，这样对终端用户而言，请求总是能够成功的，整个系统依然可用。
1.3.2 应用服务器集群的Session管理
1) Web应用中将这些多次请求修改使用的上下文对象称作会话（Session），单机情况下，Session可由部署在服务器上的Web容器（如JBoss）管理。在使用负载均衡的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。
2) Session复制：应用服务器开启Web容器的Session复制功能，在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息，这样任何一台机器宕机都不会导致Session数据的丢失，而服务器使用Session时，也只需要在本机获取即可。
3) Session绑定：Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上（也可以根据Cookie信息将同一个用户的请求总是分发到同一台服务器上，当然这时负载均衡服务器必须工作在HTTP协议层上，关于负载均衡算法的更多信息请参考第6篇。这样在整个会话期间，用户所有的请求都在同一台服务器上处理，即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。这种方法又被称作会话黏滞。但是Session绑定的方案显然不符合我们对系统高可用的需求，因为一旦某台服务器宕机，那么该机器上的Session也就不复存在了，用户请求切换到其他机器后因为没有Session而无法完成业务处理。因此虽然大部分负载均衡服务器都提供源地址负载均衡算法，但很少有网站利用这个算法进行Session管理。
4) 利用Cookie记录Session：企业应用系统使用C/S（客户端/服务器）架构，一种管理Session 的方式是将Session记录在客户端，每次请求服务器的时候，将Session放在请求中发送给服务器，服务器处理完请求后再将修改过的Session响应给客户端。网站没有客户端，但是可以利用浏览器支持的Cookie记录Session。
5) Session服务器：利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。对于有状态的Session服务器，一种比较简单的方法是利用分布式缓存、数据库等，在这些产品的基础上进行包装，使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录（SSO）、用户服务等功能，则需要开发专门的Session服务管理平台。
1.4 高可用的服务
1) 分级管理：运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。同时在服务部署上也进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心。
2) 超时设置：由于服务端宕机、线程死锁等原因，可能导致应用程序对服务端的调用失去响应，进而导致用户请求长时间得不到响应，同时还占用应用程序的资源，不利于及时将访问请求转移到正常的服务器上。
3) 异步调用：应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。如提交一个新用户注册请求，应用需要调用三个服务：将用户信息写入数据库，发送账户注册成功邮件，开通对应权限。如果采用同步服务调用，当邮件队列阻塞不能发送邮件时，会导致其他两个服务也无法执行，最终导致用户注册失败。
4) 服务降级：在网站访问高峰期，服务可能因为大量的并发调用而性能下降，严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务及关闭服务。
a) 拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节约资源，让另一部分请求得以成功，避免要死大家一起死的惨剧。貌似Twitter比较喜欢使用随机拒绝请求的策略，经常有用户看到请求失败的故障页面，但是问下身边的人，其他人都正常使用，自己再刷新页面，也好了。
b) 关闭功能：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源。淘宝在每年的“双十一”促销中就使用这种方法，在系统最繁忙的时段关闭“评价”、“确认收货”等非核心服务，以保证核心交易服务的顺利完成。
5) 幂等性设计：应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。服务重复调用是无法避免的，应用层也不需要关心服务是否真的失败，只要没有收到调用成功的响应，就可以认为调用失败，并重试服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。交易编号等信息进行服务调用有效性校验，只有有效的操作才能继续执行。
1.5 高可用的数据
1) 保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。而失效转移机制则保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。
1.5.1 CAP原理
1) CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Patition Tolerance，系统具有跨网络分区的伸缩性）这三个条件。
2) 数据持久性：保证数据可持久存储，在各种情况下都不会出现数据丢失的问题。为了实现数据的持久性，不但在写入数据时需要写入持久性存储，还需要将数据备份一个或多个副本，存放在不同的物理存储设备上，在某个存储故障或灾害发生时，数据不会丢失。
3) 数据可访问性：在多份数据副本分别存放在不同存储设备的情况下，如果一个数据存储设备损坏，就需要将数据访问切换到另一个数据存储设备上，如果这个过程不能很快完成（终端用户几乎没有感知），或者在完成过程中需要停止终端用户访问数据，那么这段时间数据是不可访问的。
4) 数据一致性：在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就会造成各个副本之间的数据不一致，数据内容冲突。实践中，导致数据不一致的情形有很多种，表现形式也多种多样，比如数据更新返回操作失败，事实上数据在存储服务器已经更新成功。
1.5.2 数据备份
1) 数据备份主要分为冷备份和热备份，冷备的优点是简单和廉价，成本和技术难度都较低。缺点是不能保证数据最终一致，数据热备可分为两种：异步热备方式和同步热备方式
2) 异步热备方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本（这个过程有可能会失败）。
3) 同步热备具体实现的时候，为了提高性能，在应用程序客户端并发向多个存储服务器同时写入数据，然后等待所有存储服务器都返回操作成功的响应后，再通知应用程序写操作成功。关系数据库热备机制就是通常所说的Master-Slave同步机制。Master-Slave机制不但解决了数据备份问题，还改善了数据库系统的性能，实践中，通常使用读写分离的方法访问Slave和Master数据库，写操作只访问Master数据库，读操作只访问Slave数据库。
1.5.3 失效转移
1) 若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫作失效转移。失效转移操作由三部分组成：失效确认、访问转移、数据恢复。
2) 失效确认：判断服务器宕机是系统进行失效转移的第一步，系统确认一台服务器是否宕机的手段有两种：心跳检测和应用程序访问失败报告。对于应用程序的访问失败报告，控制中心还需要再一次发送心跳检测进行确认，以免错误判断服务器宕机，因为一旦进行数据访问的失效转移，就意味着数据存储多份副本不一致，需要进行后续一系列复杂的操作。
3) 访问转移：确认某台数据存储服务器宕机后，就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器（几台存储服务器存储的数据完全一样，我们称几台服务器为对等服务器，比如主从结构的存储服务器，其存储的数据完全一样），当其中一台宕机后，应用程序根据配置直接切换到对等服务器上。如果存储是不对等的， 那么就需要重新计算路由，选择存储服务器。
4) 数据恢复：因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机时，就可能出现无法访问转移（所有副本的服务器都宕机了），数据永久丢失的情况。因此系统需要从健康的服务器复制数据，将数据副本数目恢复到设定值。
1.6 高可用网站的软件质量保证
1.6.1 网站发布
1) 发布过程中，每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用。
1.6.2 自动化测试
1) 目前大部分网站都采用Web自动化测试技术，使用自动测试工具或脚本完成测试。比较流行的Web自动化测试工具是ThoughtWorks开发的Selenium。Selenium运行在浏览器中，模拟用户操作进行测试，因此Selenium可以同时完成Web功能测试和浏览器兼容测试。
1.6.3 预发布验证
1) 在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没有配置在负载均衡服务器上，外部用户无法访问，
1.6.4 代码控制
1) 使用git，svn等进行代码管理，
1.6.5 自动化发布
1) 火车发布模型是基于规则驱动的流程，所以这个流程可以自动化。采用火车发布模型的网站会开发一个自动化发布的工具实现发布过程的自动化。根据响应驱动流程，自动构造代码分支，进行代码合并，执行发布脚本等。正常流程下，可以做到发布过程无人值守，无需SCM（网站配置管理员）参与，每个项目相关人员基于流程执行相应的操作，即可完成应用自动发布。人的干预越少，自动化程度越高，引入故障的可能性就越小，火车准点到达，大家按时下班的可能性就越大。
1.6.6 灰度发布
1) 大型网站会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。
2) 灰度发布也常用于用户测试，即在部分服务器上发布新版本，其余服务器保持老版本（或者发布另一个版本），然后监控用户操作行为，收集用户体验报告，比较用户对两个版本的满意度，以确定最终的发布版本。这种手段也被称作AB测试。
1.7 网站运行监控
1.7.1 监控数据采集
1) 用户行为日志收集：用户行为日志指用户在浏览器上所做的所有操作及其所在的操作环境，包括用户操作系统与浏览器版本信息，IP地址、页面访问路径、页面停留时间等，这些数据对统计网站PV/UV指标、分析用户行为、优化网站设计、个性化营销与推荐等非常重要。
2) 服务器端日志收集：这个方案比较简单，Apache等几乎所有Web服务器都具备日志记录功能，可以记录大部分用户行为日志，开启Web服务器的日志记录功能即可。其缺点是可能会出现信息失真，如IP地址是代理服务器地址而不是用户真实IP；无法识别访问路径等。
3) 客户端浏览器日志收集：利用页面嵌入专门的JavaScript脚本可以收集用户真实的操作行为，因此比服务器日志收集更加精准。其缺点是比较麻烦，需要在页面嵌入特定的JavaScript脚本来完成。
4) 服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO、网络IO等对尽早做出故障预警，及时判断应用状况，防患于未然，将故障扼杀在萌芽时期非常重要。此外根据性能监控数据，运维工程师可以合理安排服务器集群规模，架构师及时改善系统性能及调整系统伸缩性策略。目前网站使用比较广泛的开源性能监控工具是Ganglia，它支持大规模服务器集群，并支持以图形的方式在浏览器展示实时性能曲线。
5) 运行数据报告：除了服务器系统性能监控，网站还需要监控一些与具体业务场景相关的技术和业务指标，比如缓冲命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等。
1.7.2 监控管理
1) 系统报警：在服务器运行正常的情况下，其各项监控指标基本稳定在一个特定水平，如果这些指标超过某个阈值，就意味着系统可能将要出现故障，这时就需要对相关人员报警，及时采取措施，在故障还未真正发生时就将其扼杀在萌芽状态。
2) 失效转移：除了应用程序访问失败时进行失效转移，监控系统还可以在发现故障的情况下主动通知应用，进行失效转移。
3) 自动优雅降级：优雅降级是指网站为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心功能正常访问的一个手段。淘宝每年一次的“双十一”促销活动主动关闭“评价”、“确认收货”等非核心功能，以保证交易功能的正常进行，就可以看作是一种优雅降级。
1.8 小结
1) 工程师对架构做了许多优化、对代码做了很多重构，对性能、扩展性、伸缩性做了很多改善，但别人未必能直观地感受到，也许你的直接领导都不知道你做的这些意义何在。但如果你负责的产品出了重大故障，CEO都会知道你的名字。