大型网站架构核心要素之可用性：高可用架构

前言

上节我们讲了网站核心要素之性能，这节我们接着讲第二个核心要素可用性，网站的可用性，描述的是一个网站是否可以正常使用的特性，这个特性是比较关键的，直接影响公司形象和利益，因此也有很多大公司把这点作为技术人员的绩效考核之一。既然那么重要，那么我们就好好的谈一谈如何构建一个高性能网站架构，我们将从如下几个大方面展开讨论：度量与考核、网站架构高可用、应用高可用、服务高可用、数据高可用、软件质量保证、运行监控。

网站可用性的度量与考核

• 网站可用性度量：网站不可用又称为网站故障，通常用多少个9来衡量，对于大多数网站来说，2个9是基本可用（网站年度不可用时间小于88小时），3个9是较高可用（小于9个小时），4个9是具有自动恢复能力的高可用（小于53分钟），5个9就是极高可用性（小于5分钟）。

  网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点

  网站年度可用性指标=（1-网站不可用时间、年度总时间）*100%

• 网站可用性考核：可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标，从管理层面上来说可用性指标是网站或者产品的整体考核指标；从每个工程师层面来说，考核更多的是只是故障分。

  故障分是指对网站故障进行分类加权计算故障责任的方法，一般分类权重如下，故障分的计算公式：故障分=故障时间（分钟）*故障权重

  

  简化版故障处理流程如下：

   

  

  有时候一个故障可能由多个部门或团队来承担，故障分也会相应按责任分摊到不同的团队和个人。

高可用的网站架构

• 高可用架构设计目的：为了保证当服务器硬件故障时，服务依然可用、数据依然保存并能够被访问；

• 高可用架构实现手段：主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘中读取数据。

  一个典型的网站设计一般遵循基本的分层架构模型：应用层-服务层-数据层，各层之间具有相对的独立性。应用层主要负责业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储与访问。不同规模网站架构分层部署也不同，下面分别看下中型和大型网站分层部署，如下图所示：

   

   

  

   

  

  应用层：通常为了应对高并发的访问请求，会通过负载均衡器将一组服务器组成一个集群共同对外提供服务，当负载均衡器通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群中剔除，并将请求分发到集群中其他可用的服务器上，使整个集群保持可用，从而实现应用高可用；

  服务层：服务层和应用层差不多，也是通过集群方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心对提供服务的服务器进行心跳检测，发现有服务不可用时，立即通知客户端程序修改访问列表，剔除不可用的服务器；

  数据层：数据层的服务器比较特殊，上面存储着数据，为了保证服务器宕机时数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器，实现数据冗余备份。当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上；

• 网站高可用设计时，除了考虑实际的硬件故障引起的宕机，还要考虑网站升级发布所引起的宕机；

高可用的应用

    应用层主要处理网站应用的业务逻辑，因此也成为业务逻辑层，应用的一个现住特点是应用无状态，所谓的无状态是指应用服务器不保存业务的上下文信息，而仅仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务器之间完全对等，请求提交到任何一个服务器，处理的结果都是一样的。

什么是负载均衡：实现服务器可用状态实时监测，自动转移失任务的机制叫负载均衡，主要是使用在业务量和数据量较高的情况下，当单台服务器不