前言
上节我们讲了网站核心要素之性能，这节我们接着讲第二个核心要素可用性，网站的可用性，描述的是一个网站是否可以正常使用的特性，这个特性是比较关键的，直接影响公司形象和利益，因此也有很多大公司把这点作为技术人员的绩效考核之一。既然那么重要，那么我们就好好的谈一谈如何构建一个高性能网站架构，我们将从如下几个大方面展开讨论：度量与考核、网站架构高可用、应用高可用、服务高可用、数据高可用、软件质量保证、运行监控。
网站可用性的度量与考核
网站可用性度量：网站不可用又称为网站故障，通常用多少个9来衡量，对于大多数网站来说，2个9是基本可用（网站年度不可用时间小于88小时），3个9是较高可用（小于9个小时），4个9是具有自动恢复能力的高可用（小于53分钟），5个9就是极高可用性（小于5分钟）。
网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度可用性指标=（1-网站不可用时间、年度总时间）*100%
网站可用性考核：可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标，从管理层面上来说可用性指标是网站或者产品的整体考核指标；从每个工程师层面来说，考核更多的是只是故障分。
故障分是指对网站故障进行分类加权计算故障责任的方法，一般分类权重如下，故障分的计算公式：故障分=故障时间（分钟）*故障权重
简化版故障处理流程如下：
有时候一个故障可能由多个部门或团队来承担，故障分也会相应按责任分摊到不同的团队和个人。
高可用的网站架构
高可用架构设计目的：为了保证当服务器硬件故障时，服务依然可用、数据依然保存并能够被访问；
高可用架构实现手段：主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘中读取数据。
一个典型的网站设计一般遵循基本的分层架构模型：应用层-服务层-数据层，各层之间具有相对的独立性。应用层主要负责业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储与访问。不同规模网站架构分层部署也不同，下面分别看下中型和大型网站分层部署，如下图所示：
应用层：通常为了应对高并发的访问请求，会通过负载均衡器将一组服务器组成一个集群共同对外提供服务，当负载均衡器通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群中剔除，并将请求分发到集群中其他可用的服务器上，使整个集群保持可用，从而实现应用高可用；
服务层：服务层和应用层差不多，也是通过集群方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心对提供服务的服务器进行心跳检测，发现有服务不可用时，立即通知客户端程序修改访问列表，剔除不可用的服务器；
数据层：数据层的服务器比较特殊，上面存储着数据，为了保证服务器宕机时数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器，实现数据冗余备份。当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上；
网站高可用设计时，除了考虑实际的硬件故障引起的宕机，还要考虑网站升级发布所引起的宕机；
高可用的应用
应用层主要处理网站应用的业务逻辑，因此也成为业务逻辑层，应用的一个现住特点是应用无状态，所谓的无状态是指应用服务器不保存业务的上下文信息，而仅仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务器之间完全对等，请求提交到任何一个服务器，处理的结果都是一样的。
什么是负载均衡：实现服务器可用状态实时监测，自动转移失任务的机制叫负载均衡，主要是使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过引入负载均衡器，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载能力，在网站应用中，当集群中的服务都是无状态对等时，负载均衡可以起到高可用的作用，如下图：
当web服务器集群中的服务都是可用时，负载均衡器会把请求分发到任意一台服务器上处理，而当服务器139.19.0.1发生宕机时，负载均衡器通过心跳检测机制发现该服务器失去响应，就会把它从服务器列表中剔除，而将请求发送到其他服务器上，这些服务都是对等的，所以处理的结果都是一样的。
通过负载均衡进行无状态服务的失效转移
应用服务器集群的session集中式管理
应用服务器的高可用架构是基于服务无状态设计的，但是实际我们的业务总是有状态的，例如我们需要记录用户的当前登录状态；
web应用中将多次请求修改使用的上下文对象称为会话（session），单机情况下，session可以由部署在服务器上的web容器管理如tomcat，在使用负载均衡的集群环境下，由于负载均衡器会将请求随机分发到集群中某一台服务器上，所以要保证每次请求依然获取正确的session是比较复杂的，主要从以下几个方面入手：
Session复制：应用服务器开启web容器的session复制功能，在集群中的几台服务器之间同步session对象，使得每台服务器上都保存所有用户的session信息，这样任何一台服务器宕机都不会导致session丢失，而服务器使用session时只需要在本机上直接获取即可，如下图：
这种方案虽然简单，服务器从本地获取session也很快速，但是这种只适合在集群规模比较小的情况下，当集群规模比较大时，集群服务器间需要大量的通信进行session复制，这是极大的占用服务器资源，系统将是承受不起的，而且由于所有的用户的session信息在每台服务器上都有备份，在大量用户访问的情况下，甚至会出现服务器内存不够session存储的情况，对于大型网站架构而言，集群服务器成千上万，因此这种方案不适合大型网站。
Session绑定：利用负载均衡的源地址Hash算法实现，负载均衡器总是将来自同一个IP的请求分发给同一台服务器（如果你是通过HTTP协议走请求，也可以通过cookie信息将同一个用户的请求分发到同一台服务器），这样在整个会话期间，同一个用户所有的请求都在同一个服务器上被处理，即每个用户的session绑定在某台特定的服务器上，保证该用户session就从该服务器上获取即可，这种方法又称为会话黏滞：
session绑定的方案显然不符合我们对系统高可用的需求，当一台服务器宕机时，我们就失去了该台服务器所有用户的session信息，用户请求切换到其他服务器时，显然因为获取不到session而业务处理失败，因此很少有网站会用这种方式去进行session管理。
利用cookie记录session：将session记录在客户端，每次请求服务器的时候，将session放在请求中发送给服务器，服务器处理完请求之后再将新的session返回给客户端，网站的客户端就是浏览器，所以我们可以利用浏览器的cookie记录session，cookie简单易用，可用性高，支持应用服务器的线性伸缩，示例见下图：
利用cookie记录session也存在一些缺陷：
受cookie大小的限制，能记录的session有限
每次请求都需要传输cookie，影响性能
依赖cookie，如果用户禁用了cookie，那就完全没法玩了
session服务器：前面所说的方案或多或少都有些不足，那么有没有可用性高、伸缩性好、性能也不错、对session大小也没有限制的解决方案呢？答案就是session服务器。利用独立部署的session服务器（集群）统一管理session，应用服务器每次读写session时都访问session服务器，如下图所示：
这种解决方案本质上是将应用服务器状态分离，分为无状态的应用服务器和有状态的session服务器，然后针对这2种分别设计架构。
有状态的session服务器，一般采用分布式缓存、数据库等方案，但是如果网站业务场景对session管理有较高的要求，那么最好还是需要开发一个专门的session服务管理平台。
高可用的服务
可复用的服务模块为业务产品提供公共服务，大型网站中这些服务通常都独立分布式部署，被远程应用调用，可复用的服务和应用一样，也是无状态的服务，因此使用类似负载均衡的失效转移策略也可以实现高可用的服务，此外还有以下几种高可用服务策略：
分级管理：运维将服务器进行分级管理，核心应用和服务优先使用更好的硬件；同时在服务部署上也进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心；
超时设置：由于服务器宕机、线程死锁等原因，可能会导致应用程序对服务端的调用十七冶响应，进而导致用户请求长时间得不到响应，同时还占用应用程序的资源，不利于及时将访问请求转移到正常服务器上。所以在应用程序中设置服务调用的超时时间，一旦超时未响应，就抛出异常，应用程序根据服务调度策略，可以选择继续重试请求或者将请求转移到其他服务器；
异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败。但是，对于那些必须确认服务调用成功才能继续下一步操作的应用就不适合使用异步调用了；
服务降级：在网站访问高峰期时，服务可能因大量的并发调用而性能下降，严重的可能会导致服务宕机，为了保证核心应用和功能的正常运行，需要对服务进行降级。降级的方案有2种：
拒绝服务：拒绝优先级低的应用调用，减少服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节约资源，让另一部分请求得以成功
关闭服务：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源
幂等性设计：服务重复调用是无法避免的，应用层也不需要关心服务是否真的失败，只要没有收到调用成功的响应，就可以认为调用失败了，并重试服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同，这就是服务必须具有的幂等性。
高可用的数据
保证数据存储高可用的方案主要有2种：数据备份和失效转移机制；
数据备份是保证数据有多个副本，任意副本的失效都不会导致数据永久的丢失，从而实现数据完全的持久化。
失效转移机制则保证当一个数据副本不能访问时，可以快速切换到访问数据的其他副本，保证系统数据的高可用。
CAP原理：在讨论数据服务高可用之前，我们先看下数据一致性，因为为了保证数据高可用，往往需要牺牲数据一致性作为代价。
高可用的数据有如下几个层面的含义：
数据持久性：保证数据可持久存储，在各种情况下都不会出现数据丢失问题，为了实现数据的持久性，不但在写入数据时需要写入持久性存储，还需要将数据备份一个或者多个副本，存放在不同的物理存储设备上，在某个存储故障或灾难发生时，数据不会丢失；
数据可访问性：在多份数据副本分别存放在不同存储设备的情况下，如果一个数据存储设备损坏，就需要将数据切换到另一个数据存储设备上，如果这个过程不能很快完成，或者在完成过程中需要停止用户访问数据，那么这段时间数据是不可访问的；
数据一致性：在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分写入失败，这就会造成各个副本之间的数据不一致，数据内容冲突。CAP原理认为：一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availability）、分区耐受性（Partition tolerance）这三个条件，如图所示：
在大型网站应用中，数据规模总是快速扩张的，所以可伸缩性即分区耐受性必不可少，规模变大以后机器数量也变大，网络和服务器故障就会频繁出现，要想保证应用高可用，就必须保证分布式处理系统的高可用性，所以通常会选择强化分布式存储系统的可用性和伸缩性，而在一定程度上放弃一致性；具体来说数据一致性又可以分为下面几点
数据强一致性：各个副本的数据在物理存储中总是一致的；更新操作结果和操作响应总是一致的。
数据用户一致：即数据在物理存储中的各个副本数据不一定是一致的，但是终端用户在访问时，通过纠错和校验机制，可以保证一个一致的且正确的数据返回给用户。
数据最终一致：这是数据一致性中较弱的一种，即物理存储的数据可能不一致，终端用户访问到的数据也可能不一致，但是系统经过一段时间的自我恢复和修正，数据最终会达到一致。
因为难以满足数据强一致，网站通常会综合成本、技术和业务场景，结合应用服务和其他数据监控与纠错能力，使存储系统达到用户一致性，保证最终用户访问数据的正确性。
数据备份：数据备份分为冷备份和热备份
冷备份：定期将数据复制到某种存储介质上并物理存档保存，如果系统存储损坏，就从冷备的存储设备中恢复数据；
冷备份的优点是简单廉价，成本和技术难度较低；
冷备份缺点是不能保证数据最终一致性，因为数据是定期备份，因此备份设备中的数据比系统中的数据旧，如果系统数据丢失，那么从上个备份点开始更新的数据就会永久丢失，不能恢复；此外也不能保证数据可用性，从冷备份存储中恢复数据需要较长的时间，而这段时间无法访问数据，系统也不可用；
热备份：热备份又分为2种，异步热备份和同步热备份
异步热备份：指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功一份，存储系统将会异步地写其他副本（这个过程可能会失败）如下图：
在异步写入方式下，存储服务器分为主存储服务器（Master）和从存储服务器（Slave），应用程序正常情况下只连接主存储服务器，数据写入时，由主存储器的写操作代理模块将数据写入本机存储系统后立即返回写操作成功响应，然后通过异步线程将写操作数据同步到从存储服务器；
同步热备份：指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功，但是当应用程序收到写操作失败时，可能会有部分副本或者全部副本已经写成功；
同步热备实现的时候，为了提高性能，在应用程序客户端并发向多个存储服务器同时写入数据，然后等待所以存储服务器都返回操作成功的响应后，再通知应用程序写操作成功。这种情况下，存储服务器没有主从之分，完全对等，更便于管理和维护，存储服务客户端在写多份数据时，并发操作，这意味着多份数据的总写操作延迟是响应最慢的那台存储服务器的响应延迟，而不是多台存储服务器响应延迟之和，其性能和异步热备差不多。
失效转移：数据服务器集群中一台服务器宕机，那么应用程序针对这台服务器的所有写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程称之为失效转移；该操作由三部分组成：
失效确认：判断服务器宕机是系统进行失效转移的第一步，系统确认一台服务器是否宕机有2种方式：心跳检测和应用程序访问失败报告
对于应用程序的访问失败报告，控制中心还需要再进行一次心跳检测进行确认，以免错误判断服务器宕机，因为一旦进行数据访问的失效转移，就意味着数据存储多份副本不一致，需要进行一系列后续操作。
访问转移：确认某台数据存储服务器宕机后，就需要将数据写访问重新路由到其他服务器上，对于完全对等存储的服务器，当其中一台宕机后，应用程序根据配置直接切换到对等服务器即可，但是如果存储是不对等的，那么就需要重新计算路由，选择存储服务器。
数据恢复：因为某台服务器宕机，所以数据存储的副本数目就会减少，必须将副本的数目恢复到系统设定的值，否则再有服务器宕机时，就可能出现无法访问转移（所有副本服务都宕机），数据将会永久丢失，因此系统需要从正常的服务器复制数据，将数据副本数目恢复。
高可用网站的软件质量保证
网站发布：不管是发布新功能还是增加一个核心业务，都需要在服务器上关闭原有应用，然后重新部署新的应用，整个过程还要求不影响用户的使用；
网站发布过程本质上和服务器宕机效果是一样的，但是网站发布是一次提前预知的服务器宕机，所以这个过程会比较友好，对用户影响更小，通常使用发布脚本来完成发布，流程如下：
发布过程，每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用。
自动化测试：代码发布到线上服务器之前需要进行严格的测试，为了保证系统没有引入未预料的bug，还是需要对整个网站功能进行全面的回归测试。目前大部分网站都采用web自动化测试技术，使用自动化脚本测试工具或者脚本完成测试，大型公司一般也会开发自己的自动化测试工具，可以一键完成系统部署，测试数据生成，测试执行，测试报告生成等全部测试过程。
预发布验证：网站发布的时候，并不是直接把测试通过的代码包发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些业务流程，确认系统没有问题才正式发布；
预发布服务器是一种特殊的服务器，它和线上的正式服务器唯一的不同就是没有配置在负载均衡器上，外部用户无法访问
此外在网站应用中强调一个处理错误的理念是快速失败，即如果系统在启动时发现问题就立刻抛出异常，停止启动让工程师介入排查错误，而不是启动执行错误的操作。
代码控制：网站代码控制核心问题是如何进行代码管理，既能保证代码发布版本的稳定正确，又能保证不同团队的开发互不影响
主干开发、分支发布：代码修改在主干上进行，需要发布的时候，从主干上拉一个分支发布，该分支即成为一个发布版本，如果该版本发现bug，继续在该分支上修改发布，并将修改合并回主干，直到下次主干发布；
分支开发、主干发布：任何修改都不得在主干上直接进行，需要开发一个新功能或者改bug时，从主干拉一个分进行开发，开发完后合并回主干，然后从主干进行发布，主干上的代码永远是最新发布的版本；
这两种方式各有优缺点，主干开发、分支发布方式，主干反应目前整个应用的状态，一目了然，便于管理和控制，也利于持续集成；分支开发，主干发布方式，各个分支独立进行，互不干扰，可以使不同发布周期的开发在同一个应用中进行。
自动化发布：基于规则驱动的流程，可以实现自动化，开发一个自动化发布工具，根据响应驱动流程，自动构建代码分支，进行代码合并，执行发布脚本
灰度发布：大型网站一般会采用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。
灰度发布也常用于用户测试。即部分服务器上发布新版本，其余服务器保持老版本，然后监控用户的操作行为，收集用户体验报告，比较用户对两个版本的满意度，以确定最终发布版本，这种手段也成为AB测试。
网站运行监控
不允许没有监控的系统上线，网站运行监控对于网站运维和架构设计优化来说至关重要，主要从数据采集和监控管理着手
监控数据采集之后，除了用作系统性能评估，集群规模伸缩性预测，还可以根据监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群所有机器的资源
监控数据采集：包括供数据分析师和产品设计师使用的网站用户行为日志、业务运行数据、以及系统性能数据
此外，大型网站的日志数据比较大，数据存储与计算压力很大，可以使用基于实时计算框架的storm的日志统计分析工具。
用户行为日志采集：指用户在浏览器上所做的操作及其所在的操作环境，包括用户操作系统与浏览器版本信息，IP地址，页面访问路径，页面停留时间等，这些数据对统计网站PV/UV指标、分析用户行为，优化网站设计、个性营销与推荐非常重要，具体用户行为日志收集有下面2种方式：
服务器端日志收集：开启web服务器的日志记录即可；
客户端浏览器日志收集：利用页面嵌入专门的js脚本可以收集用户真实操作行为，比服务器收集日志更加精准你，缺点是比较麻烦，需要在页面嵌入特定的脚本完成
服务器性能监控：收集服务器性能指标，如系统load、内存占用。磁盘IO，网络IO；
运行数据报告：除了服务器性能监控之外，网站还需要监控一些与具体业务相关的技术和业务指标，比如缓存命中率，平均响应延迟时间，待处理的任务总数，线程阻塞的数量等等；
监控管理
系统报警：可以设置一些监控指标的阈值和值班人员的联系方式，当超过阈值就需要联系相关人员进行报警，报警方式可以配置手机短信，语音报警等等
失效转移：除了应用程序访问失败进行失效转移，监控系统还可以在发现故障的情况下，主动通知应用，进行失效转移
自动优雅降级：优雅降级是指网站为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心功能能正常访问。
网站在监控管理基础上实现自动优雅降级，是网站柔性架构的理想状态：监控系统实时监控所有服务器的运行状况，根据监控参数判断应用访问负载情况，如果发现部分应用负载过高，而部分应用负载过低，就会适当卸载低负载应用部分服务器，重新安装启动部分高负载应用，使应用负载总体均衡，如果所有应用负载都很高，而且负载压力还在继续增加，那就会自动关闭部分非重要功能，保证核心功能正常运行。
