高可用架构的话题扩展开来，可以写一本书，21CTO平台也会持续登载相关文章，这些文章会汇聚和总结为这本书的主要内容。
从Livedoor，再从赶集网，从一两台机器到十几台。再到后来的YY平台，后来的今日头条的特卖架构，再到云架构，随着技术的演进，有些异同，但也有共通之处。根据产品特性，成本，团队技术等的综合体现，并没有固定的标准。
什么是高可用
高可用(High Availability)实际上是构建分布式系统的一个标准，特别是互联网的分布式系统架构要达到高性能，高扩展，以及高可用可伸缩等特征，高可用是分布式系统架构中首重考虑的因素。
高可用指通过系统架构来减少和避免系统不能提供可用服务的时间。马上快过年了，我们都要用12306网站来订票，这个最牛网站还是每天晚上10点到第二天7点关机不营业，这属于另一种不提供服务，另当别论。
假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1小时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.8个小时。
使用公式 x = (n - y) * 100/n 来计算可用性百分比。
x代表百分比
n代表给定历月（30 天）中的总分钟数
y代表系统或服务不可用时的总分钟数
可以在下表（该表使可用性百分比与日历时间等价值相关联）中看到，很难实现五个九的可用性。
请见下表：
说明
通俗叫法
可用性级别
年/停机时间
基本可用性
2个9
99%
87.6小时
较高可用性
3个9
99.9%
8.8小时
具有故障自动恢复能力的可用性
4个9
99.99%
53分钟
最高可用性
5个9
99.999%
5分钟
网站或后端系统可用性标准
关于可用性服务标准，在一些正规的数据中心IDC或提供CDN的公司，它们IT 服务级别协议 (SLA)能够达到4个9标准的。
当然，可用性是有一个平衡点，达到4个9就是不错的公司，还有一些关键特性，比如容错，容灾，备份和恢复等。
举个栗子，一些网站在人们心目中是一直不宕机的。比如百度，它在若干年的页面只有十几K。不管是不是互联网公司，人们会通过ping baidu.com来检测网络的连通性。它的高可用服务，达到了常说的『简单，可依赖』，『如果百度都打不开，应该网络断了』，人们会常这样确定。
另外还有163.com等都成为业内公认高可用保障非常出色的系统，这是对这些技术团队的至高荣誉。
如何保障系统高可用
我们都知道，单点故障是系统高可用的大敌，即一台机器出现问题，导至整个系统的不可用。因此在架构设计上应该尽量避免单点。在理论方法上，保证高可用的方法就是『负载均衡』，即『分布式』『集群化』式设计。假如说只有一台服务器，如果它挂掉了，整体服务都受到了影响。
现实中，一台机器来支撑应用的场景也有，需要我们做到可用性也可以达成，但思想也有多台机器思维，以及异常的处理，后面我会持续大家谈讨。
很显而易见的是，当有了多台服务器后，流量负载会分摊到这些机器上，即使有一台挂了还有其它机器能够顶得上。
保证系统高可用，架构设计的核心准则就是：系统冗余。加了冗余后，还不够，当每次出现故障后，如果需要人工来介入以恢复服务，这样也会增加系统的不可服务实践。
所以，我们是通过『故障自动转移』来实现系统的高可用。接下来，我们一起看典型的互联网架构中，如果通过冗余+自动故障转移来保证系统的高可用特性。
图1 互联网基础架构概览
我们常见的互联网分布式基本架构就是上面的图示。
这些分层简介如下：
1、客户端层：也称前端，调用方为浏览器或手机APP
2、CDN为内容分发网络，相当于内容的分布式缓存
3、站点应用层：实现核心应用逻辑，返回HTML/Java或JSON数据
4、服务层：如果架构已经实现了SOA，RPC或Web Service
5、数据-缓存层：缓存加速访问存储，包括NoSQL等相关
6、数据库层：数据持久化
整个系统的高可用，是通过第一层的均衡+冗余与自动故障转移来综合实现的。
