通常企业级应用系统为提高系统可用性，会采用较昂贵的软硬件设备，
如IBM的小型机乃至中型机大型机及专有操作系统、Oracle数据库、EMC存储设备等。
互联网公司更多地采用PC级服务器、开源的数据库和操作系统，这些廉价的设备在节约成本的同时也降低了可用性，
特别是服务器硬件设备，低价的商业级服务器一年宕机一次是一个大概率事件，而那些高强度频繁读写的普通硬盘，损坏的概率则要更高一些。
既然硬件故障是常态，网站高可用架构设计的目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。
实现上述高可用架构的主要手段是数据和服务的冗余设备及失效转移，一旦某些服务器宕机，
就将服务切换到其它可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。
一个典型的网站设计通常遵循如下的基本分层架构模型：
典型的分层模型是三层，即应用层、服务层、数据层，各层之间具有独立性。
应用层主要负责具体业务逻辑处理；服务层负责提供可服用的服务，数据层负责数据的存储和访问。
理解：应用层——web服务器那一块，负责请求分发
服务层——一个具体的程序不断接受请求，并进行处理
数据层——存储数据的地方
中小型网站在具体部署时，通常将应用层和服务层部署在一起（应为没有必要而且节约资源）而数据层另外部署。
下面是网站架构演化的第一步：
在复杂的大型网站架构中，划分的颗粒度会更小、更详细，结构更加复杂，服务器规模更加庞大，
但是通常还是能够把这些服务器划分到这三层中，如图所示：
不同的业务产品会部署在不同的服务器集群上，如某网站的文库、贴吧、百科等属于不同的产品，能部署在各自独立的服务器集群上，互不相干。
这些产品又会依赖一些共同的复用业务，如注册登录服务、Session管理服务等，这些可复用的业务服务也部署在独立的服务器集群上。
至于数据层，数据库服务、文件服务、缓存服务等数据存储与访问服务都部署在各自独立的服务器集群上。
大型网站的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。
关闭服务或者服务器宕机时产生的影响也不相同，高可用的解决方案也差异甚大。
位于应用层的服务器通常为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务，
当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，
并将请求分发到集群中其它可用的服务器上，使整个集群保持可用，从而实现应用高可用。
位于服务层的服务器情况和应用层的服务器类似，也是通过集群方式实现高可用，
只是这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，
并通过服务注册中心对提供服务的服务器进行心跳检测，发现服务不可用，立即通知客户端程序修改服务访问列表，剔除不可用的服务器。
位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证服务器宕机时数据不丢失，
数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。
当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。
网站升级的频率一般都非常高，大型网站一周发布一次，小型网站一天发布几次。
每次网站发布都需要关闭服务，重新部署系统，整个过程相当于服务器宕机。
因此网站的可用性架构设计不但要考虑实际的硬件故障引起的宕机，还要考虑网站升级发布引起的宕机，
而后者更加频繁，不能因为系统可以接收偶尔的停机故障就降低可用性的设计标准。
