大多数情况，在测试自己电脑能否上网时，我们都会用浏览器打开百度首页，如果不能打开百度首页，那就是我们电脑的网络没有连通，如果能够打开百度首页，那说明我们电脑的网络是连通的。之所以我们会拿百度首页来测试网络的连通性，是因为百度网站做到了高可用，我们相信只要网络正常就一定能打开百度首页。
同时，对于百度来说， 每次搜索查询都可以创造广告收入，服务不可用就意味着金钱的损失，意味着用户的流失。同理，服务不可用对于其他网站而言，也是公司的损失。网站的可用性这么重要，那我们怎么来衡量网站的可用性呢？有哪些措施可以用来提高网站的可用性？
网站可用性衡量指标
一个高可用网站不能频频出现故障，只要发生故障，即使是很短时间的中断，都会影响业务运营。其次，高可用网站，即使出现故障，也应该能很快恢复。如果一个网站一年不出一次故障，但一次故障需要几个小时，甚至几天才能恢复，那么这个网站也算不上一个高可用网站。
网站可用性(availability)也即网站正常运行时间的百分比，业界用 N 个9 来量化可用性， 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。 百度网站的可用性号称是5个9，即99.999% 。下表是N个9的具体说明。
描述通俗叫法可用性级别年度停机时间基本可用性2个999%87.6小时较高可用性3个999.9%8.8小时具有故障自动恢复能力的可用性4个999.99%53分钟极高可用性5个999.999%5分钟
如何提高网站的可用性？
对于大型网站来说，网站可用性越高越好。互联网架构的高可用设计可以从以下方面去考虑：
1）基于负载均衡的故障转移
对于业务逻辑服务，一般会设计成无状态化的服务，无状态化也就是服务模块只处理业务逻辑，而无需关心业务请求的上下文信息。所以无状态化的服务器之间是相互平等和独立的。
故障转移就是在某一个应用服务器不能服务用户请求的时候，通过一定的技术实现用户请求转移到其他应用服务器上来进行业务逻辑处理。
如上图所示，用户请求通过负载均衡器分发到具体的应用服务器上，应用服务器进行业务逻辑的处理。当应用服务器1出现故障不能对外提供服务时，负载均衡器可以探测到应用服务器的状态，然后将业务请求负载均衡到应用服务器2和应用服务器3上去，进而达到应用服务器故障时，不影响服务的使用。
2）冗余备份
冗余备份就是针对某一个服务通过服务器集群或多机房部署来达到服务器冗余和相互备份的目的。
在上一小节中的基于负载均衡器的失效转移方案，其实也一种冗余备份容灾的方式。同时有三台服务器组成一个集群来对外提供服务，三台服务器之间是相互备份的关系，只是三台服务器是在同一机房。
为了达到更高的可用性，我们还可以考虑通过多机房的冗余备份，如上图所示。正常情况下，负载均衡器将请求都分发到机房1的服务器上去，在机房1处理故障，或者处理性能比较高时，负载均衡器可以将请求切换到机房2上来，从而达到机房之间的容灾备份。
冗余备份可以达到避免单点，系统容量备份，多方式容灾等目的。
4）超时设置
一般网站服务都会有主调服务和被调服务之分。超时设置就是主调服务在调用被调服务的时候设置一个超时等待时间Timeout，主调服务发现超时后，主动进入超时处理流程。
例如：主调服务A调用被调服务B时，设置超时等待时间为3秒，可能由于B服务宕机、网络情况不好或程序BUG而导致B服务不能及时回复A服务的调用，此时A服务在等待3秒后，将触发超时逻辑而不再关心B服务的回复情况。A服务的超时逻辑可以依据情况而定，比如可以采取重试，或到另一个对等的B服务去请求，或直接放弃直接对外进行回包。
超时设置的好处在于当某个服务不可用时，不至于整个系统发生连锁反应。
5）异步调用
采用异步调用的方式调用被调服务，有利于将主调服务和被调服务进行解耦，同时提高系统的处理性能。
例如：当你在微信发布朋友圈时，微信APP的后台服务器需要把文字和图片存储到不同的服务模块上去，这时后台服务收到请求后，将两种不同的数据以异步调用的方式分发到不同的功能模块，这样的后台服务处理会更高效，同时即使图片存储模块响应时间长也不会影响到文字存储过程。
注：简化朋友圈发表逻辑举例仅为说明问题，不代表实际的做法。
6）服务分级和降级
在一个大系统中，一般会有核心服务和次要服务之分，那么对于不同的服务可以采用不同的处理方案，出现故障时应该优先保证核心服务的运行。再者就是针对一个完善的服务，可能需要1-2-3 三步才能完成，但是1-2两步也可以满足基本需要，那么可以将1-2 两步完成的服务是 1-2-3三步完成的服务的降级。
假如朋友圈发表逻辑，需要将用户发表的朋友圈中的文字进行存储（步骤1），同时也需要将图片进行存储（步骤2），还需要处理用户的地理位置（步骤3），三个步骤都成功完成后，用户的朋友圈就算成功发布。在某些情况下，地理位置服务可能出现故障，那么朋友圈发表逻辑模块在成功执行文字和图片的存储后，对用户返回勉强发布成功，虽然用户看到的信息不够完整，但是还勉强可用，比发布失败还是要好一些的。这就是服务降级的过程。
7）监控告警
大型网站系统的服务模块众多，经常会因为各种原因出现进程core掉，网络质量不好，机器宕机等现象，我们设计的系统应该具备监控上报和告警的能力，运维和开发能够通过监控报表实时的查看系统的运行状态。服务一旦出现问题能够及时发现，通过自动化处理，或者人工介入处理，从而达到缩短系统的不可用时间，提高可用性。
常见的监控指标有：CPU、带宽、内存使用率、网络连接状态，系统调用错误，成功率，PV，UV等
8）防雪崩机制
对于设计的任何一个系统，都需要进行容量的预估和最大容量设置，当外部请求量超过最大容量时，应该启动防雪崩机制，以避免大量外部请求把服务压跨而不能对外提供服务。
例如A服务的最大QPS是5W/S，那么当外部请求达到5W/S时，A服务只服务5W/S的QPS，超过的部分直接拒绝服务，而不是强吞下导致A服务完全不可用。
9）流量缓冲机制
在服务内可以建立队列，当流量过大时，储存一定的用户请求到队列，当流量偏小时再拿出来快速处理，从而达到削峰填谷的作用。在请求数据库时，这个方案使用得很多，避免写入高峰时压跨数据库。
10）自动化测试
对于每一次代码的提交，都能通过自动测试程序对整个服务进行整体的回归测试，这样可以快速地避免代码修改引入新的问题，而导致服务不稳定。
11）灰度发布和回滚机制
对于网站系统要发布的服务，可以采用灰度发布的方式来进行发布。所谓灰度发布就是先在生产环境中选取一小部分机器进行发布，然后再测试验证，验证成功后再继续加大发布范围。如果遇到发布的版本存在重大BUG需要能快速的启动服务回滚机制，迅速恢复到发布前的稳定版本。
12）代码控制
对于大型系统来说，一般会有多个团队或者工程师同时进行开发。需要对相同的代码库进行版本管理和发布管理。目前大部分开发团队都采用SVN和Git等工具来进行代码管理和发布。
Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理，是目前最流行的代码管理工具之一。