互联网高可用系统架构概论（上）

写在前面

高可用架构，是近年来构建大中型网站很时髦的词，是大数据，大并发，高负载后出现的产品。但是根据实际情况真正能做到，可伸缩，可扩展，可维护，确是不容易的事。

高可用架构的话题扩展开来，可以写一本书，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代表系统或服务不可用时的总分钟数

可以在下表（该表使可用性百分比与日历时间等价值相关联）中看到，很难实现五个九的可用性。
请见下表：

网站或后端系统可用性标准

关于可用性服务标准，在一些正规的数据中心IDC或提供CDN的公司，它们IT 服务级别协议 (SLA)能够达到4个9标准的。
当然，可用性是有一个平衡点，达到4个9就是不错的公司，还有一些关键特性，比如容错，容灾，备份和恢复等。

举个栗子，一些网站在人们心目中是一直不宕机的。比如百度，它在若干年的页面只有十几K。不管是不是互联网公司，人们会通过ping baidu.com来检测网络的连通性。它的高可用服务，达到了常说的『简单，可依赖』，『如果百度都打不开，应该网络断了』，人们会常这样确定。
另外还有163.com等都成为业内公认高可用保障非常出色的系统，这是对这些技术团队的至高荣誉。

如何保障系统高可用

我们都知道，单点故障是系统高可用的大敌，即一台机器出现问题，导至整个系统的不可用。因此在架构设计上应该尽量避免单点。在理论方法上，保证高可用的方法就是『负载均衡』，即『分布式』『集群化』式设计。假如说只有一台服务器，如果它挂掉了，整体服务都受到了影响。
现实中，一台机器来支撑应用的场景也有，需要我们做到可用性也可以达成，但思想也有多台机器思维，以及异常的处理，后面我会持续大家谈讨。
很显而易见的是，当有了多台服务器后，流量负载会分摊到这些机器上，即使有一台挂了还有其它机器能够顶得上。

保证系统高可用，架构设计的核心准则就是：系统冗余。加了冗余后，还不够，当每次出现故障后，如果需要人工来介入以恢复服务，这样也会增加系统的不可服务实践。
所以，我们是通过『故障自动转移』来实现系统的高可用。接下来，我们一起看典型的互联网架构中，如果通过冗余+自动故障转移来保证系统的高可用特性。

图1 互联网基础架构概览

我们常见的互联网分布式基本架构就是上面的图示。
这些分层简介如下：
1、 客户端层：也称前端，调用方为浏览器或手机APP
2、 CDN为内容分发网络，相当于内容的分布式缓存
3、 站点应用层：实现核心应用逻辑，返回HTML/JavaScript或JSON数据
4、 服务层：如果架构已经实现了SOA，RPC或Web Service
5、 数据-缓存层：缓存加速访问存储，包括NoSQL等相关
6、 数据库层：数据持久化
整个系统的高可用，是通过第一层的均衡+冗余与自动故障转移来综合实现的。

小结

本文向大家介绍了分布式系统，关于高可用架构的梗概与简要说明。
我们的文章会每章分为几次登载，本文的后半部分为高可用系统分层实践，敬请期待~

作者：杜江。21CTO（21cto.com）社区创始人。多年架构与管理经验。 著有《PHP5与MySQL5 Web开发技术详解》、《PHP5完全攻略》、《PHP与MySQL高性能应用开发》（机械工业出版社出版，各大电商平台和书店有售）。