需求驱动驱动;而高可用与高性能，是架构设计中两个非常重要的决策因素。因此，面对不同业务系统的不同需求，对高可用与高性能也会有不同的决策结论，其实现的复杂度也各不相同。支 付宝业务，对于可用性和性能就会有很高的要求，在可用性方面希望能提供7*24不间断服务，在高性能方面则希望能实时收付款;而对于一个学生管理系统，在可用性与性能方面就不一定要有 多高的要求，比如晚上可关机，几秒内能查询到信息也可接受。为此，高可用性与高性能的复杂度讨论需要结合业务需求。
1 WHAT - 什么是可用性? 定义可用性，可以先定义什么是不可用。需要经历若干环节，网站的页面才能呈现在最终的用户面前;而其中的任何一个环节出现了故障，都可能会导致网站的页面不可访问，也就是出现了网 站不可用的情况。昨夜iOS版本QQ出现大面积闪退就是一个系统不可用的典型案例。
我们可以利用百分比来对网站可用性进行度量: 网站不可用时间=完成故障修复的时间点 - 故障发现的时间点 网站年度可用时间=年度总时间 - 网站不可用时间 网站年度可用性=(网站年度可用时间/年度总时间) x 100%
举例:一些知名大型网站的可用性可达到99.99%(俗称4个9)，我们可以算一下一年下来留给处理故障的时间有多少? 年度总时间=365*24*60=525600分钟
网站不可用时间=525600*(1-99.99%)=52.56分钟 也就是，如果网站要达到4个9的可用性，一年下来网站不可用时间最多53分钟(也就是不足1个小时)。
可见，高可用性就是技术实力的象征，高可用性就是竞争力。
2 WHY - 为什么会出现不可用? 硬件故障。网站多运行在普通的商用服务器，而这些服务器本身就不具备高可用性，再加之网站系统背后有数量众多服务器，那么一定时间内服务器宕机是大概率事件，直接导致部署在该服务 器上的服务受影响。
软件BUG或网站更新升级发布。BUG不能消灭，只能减少;上线后的系统在运行过程中，难免会出现故障，而这些故障同样直接导致某些网站服务不可用;此外，网站更新升级发布也会引起相 对较频繁的服务器宕机。
不可抗拒力。如地震、水灾、战争等。
3 HOW - 如何做到高可用 核心思想:网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上;数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕 机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。
从架构角度看可用性:当前网站系统多采用经典的分层模型，从上到下为:应用层、服务层与数据层。应用层主要实现业务逻辑处理;服务层提供可复用的服务;数据层负责数据读写;在部署
架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器;这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器;而各类数据库系
统、文件柜等数据则部署在数据层的服务器。
硬件故障方面引起不可用的技术解决措施:(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务(前提是这些服务需要设计为无状态，即应用服务器不保存业务的上 下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应)，当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务 上。(2)服务层服务器。这些服务器被应用层通过分布式服务框架(如Dubbo)访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心 跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。(3)数据服务器。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗 余备份;当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。
软件方面引起不可用的技术解决措施:通过软件开发过程进行质量保证。通过预发布验证、严格测试、灰度发布等手段，尽量减少上线服务的故障。
閱讀更多 愛分享de螢火蟲 的文章
