1. 系统高可用的挑战

一个互联网应用想要完整地呈现在最终用户的面前，需要经过很多个环节，任何一个环节出了问题，都有可能会导致系统不可用。

比如说 DNS 被劫持，域名解析就失败了，系统虽然完好无损，但用户依然不能访问系统。再比如，CDN 服务不可用，前面提过，CDN 服务是用户访问的第一跳，对于大型互联网系统而言，主要的静态资源都是通过 CDN 返回的。如果 CDN 服务不可用，那么大量的用户请求就会到达互联网数据中心，会给互联网数据中心带来巨大的请求负载压力，可能直接导致系统崩溃。还有就是应用服务器及数据库宕机、网络交换机宕机、磁盘损坏、网卡松掉，这样的硬件故障；机房停电了、空调失灵了、光缆被挖掘机挖断了，这些环境故障。以及程序代码 bug 引起的故障，等等。

每种故障都是系统不可用的原因之一，在设计系统相关架构的时候，要考虑各个方面的因素。除了系统本身故障导致的可用性问题，还有外部因素导致的系统不可用。比如说系统被黑客攻击了；业务上要做一次大的促销，或者要做一个秒杀的活动，因此带来的访问压力冲击；以及第三方合作伙伴服务不可用等等，各种带来系统故障的原因。

这里面需要注意的一个点是，当我们提到一个应用服务器不可用的时候，并不仅仅是指应用服务器的硬件故障，或者是系统故障导致的系统宕机，更多的可能是应用程序在发布，因为应用程序要发布，必须要关闭以前的应用程序进程，拷贝新的程序代码，重新启动应用程序，这个时间可能需要几分钟或者十几分钟的时间，那么这段时间这台应用服务器对外看起来就是不可用的。

而这样的发布在互联网场景中是非常频繁的，一周有几次，甚至一天都有几次这样的发布。应用服务器是需要频繁停机的。所以在架构设计的时候，你不光要考虑到真正的服务器硬件或者系统故障导致的宕级，还要考虑到应用程序发布导致的系统停机，而这个可能更加频繁。

系统的高可用架构，说的就是如何去应对这些挑战。

2. 互联网应用可用性的度量

业界通常用多少个 9 来说明互联网应用的可用性。比如说 QQ 的可用性是 4 个 9，就是说 QQ 的服务 99.99% 可用，这句话的意思是 QQ 的服务要保证在其所有的运行时间里只有 0.01% 不可用，也就是说一年大概有 53 分钟不可用。这个 99.99% 就叫做系统的可用性指标，这个值的计算公式是：年度可用性指标= 1 −（不可用时间/年度总时间）×100%。

一般说来，两个 9 表示系统基本可用，年度停机时间小于 88 小时；3 个 9 是较高可用，年度停机时间小于 9 个小时；4 个 9 是具有自动恢复能力的高可用，年度停机时间小于 53 分钟；5 个 9 指极高的可用性，年度停机时间小于 5 分钟。事实上对于一个复杂的大型互联网系统而言，对可用性的影响因素是非常多的，能够达到 4 个 9 甚至 5 个 9 的可用性，除了具备过硬的技术、大量的设备资金投入、有责任心的工程师，有时候还需要好运气。

https://edgar615.github.io/ha-sla.html