1. 一、可用性度量与考核

如何度量网站可用性？

一个神奇的数字—9！你有几个 9，就代表了你的可用性。例如 QQ 可用性达到了 4 个 9：99.99%

①2 个 9=基本可用　　 ②3 个 9=较高可用　　 ③4 个 9=具有自动恢复能力的高可用　　 ④5 个 9=极高可用->理想状态

那么，可用性的 9 又是怎么计算出来的呢：

① 网站不可用时间=故障修复时间点-故障发现时间点

② 网站年度可用性指标=（1-网站不可用时间/年度总时间）*100%
如何考核网站可用性？

广泛采用故障分的，它是对网站故障进行分类加权计算故障责任的方法。一般会给每个分类的故障设置一个权重（例如事故级故障权重为 100，A 类为 20 等），其计算公式为：故障分=故障时间（分钟）*故障权重。公司对技术团队的考核一般会参考故障分，例如某团队今年发生了几个事故级故障，那么其绩效考核估计受到很大影响，年终奖什么的就悲剧了。

2. 二、高可用的架构

目前，通常企业级应用系统（特别是政府部门和大企业的应用系统）一般会采用安规的软硬件设备，如 IOE（IBM 的小型机、Oracle 数据、EMC 存储设备）系列。而一般互联网公司更多地采用 PC 级服务器（x86），开源的数据库（MySQL）和操作系统（Linux）组建廉价且高容错（硬件故障是常态）的应用集群。

设计的目的？

保证服务器硬件故障服务依然可用，数据依然保存并能够被访问。
主要的手段？

① 冗余备份以及 ② 失效转移：

对于服务而言，一旦某个服务器宕机，就将服务切换到其他可用的服务器上。对于数据而言，如果某个磁盘损坏，就从备份的磁盘（事先就做好了数据的同步复制）读取数据。

3. 三、高可用的应用

3.1.1. 1. 通过负载均衡进行无状态服务的失效转移

3.1.2. 2. ==应用服务器集群的 Session 管理==

Session 单机情况下由部署在服务器上得 Web 容器（如 IIS、Tomcat、JBoss 等）管理。在使用了负载均衡的集群环境中，由于请求的分发是随机的，所以保证每次请求依然能够获得正确的 Session 比单机时要复杂得多。

在集群环境中，Session 管理的几种常见手段:

Session 复制：

该方案简单易行，集群中的几台服务器之间同步 Session 对象，任何一台服务器宕机都不会导致 Session 对象的丢失，服务器也只需要从本机获取即可。但是，该方案只适合集群规模较小的情况下。当规模较大时，大量的 Session 复制操作会占用服务器和网络的大量资源，系统不堪重负。
Session 绑定：

利用负载均衡的源地址 Hash算法，总是将源于同一 IP 地址的请求分发到同一台服务器上。这样的话，在整个会话期间，用户所有的请求都在同一台服务器上进行处理，即 Session 绑定在某台特定服务器上，保证 Session 总能在这台服务器上获取。（这种方案又叫做会话粘滞）。

但是，这种方案不符合高可用的需求。因为一旦某台服务器宕机，那么该机器上得 Session 也就不复存在了，用户请求切换到其他机器后因为没有 Session 而无法完成业务处理。因此，很少有网站采用此方案进行 Session 管理。
Cookie 记录 Session：

利用浏览器支持的 Cookie 记录 Session 简单易行，可用性高，并且支持服务器的线性伸缩，因此，许多网站都或多或少地使用了 Cookie 来记录 Session。但是 Cookie 记录 Session 有缺点：比如受 Cookie 大小限制、每次请求响应都要传输 Cookie 影响性能、用户关闭了 Cookie 会造成访问不正常等。
==Session 服务器==：利用独立部署的 Session 服务器（集群）统一管理 Session，应用服务器每次读写 Session 时，都访问 Session 服务器。这种方案实际上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的 Session 服务器。

对于，有状态的 Session 服务器，一种较简单的方法是利用分布式缓存（如 Memcached、Redis 等，有关 Redis 的简单介绍可以阅读我的博文：NoSQL 初探之人人都爱 Redis）、数据库等，在这些产品的基础上进行封装，使其符合 Session 的存储和访问要求。

4. 四、高可用的服务

高可用的服务模块为业务产品提供基础公共服务，在大型站点中这些服务通常都独立分布式部署，被具体应用远程调用。

在具体实践中，有以下几点高可用的服务策略可以参考：

① 分级管理：核心应用和服务具有更高的优先级，比如用户及时付款比能否评价商品更重要；

② 超时设置：设置服务调用的超时时间，一旦超时后，通信框架抛出异常，应用程序则根据服务调度策略选择重试 or 请求转移到其他服务器上；

③ 异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。

PS：不是所有服务都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。对于那些必须确认服务调用成功后才能继续进行下一步的操作的应用也不适合异步调用。有关具体使用消息队列实现异步调用的案例，请阅读我的博文：《使用 Redis 作为消息队列服务场景的应用案例》。

④ 服务降级：网站访问高峰期间，为了保证核心应用的正常运行，需要对服务降级。

降级有两种手段：一是拒绝服务，拒绝较低优先级的应用的调用，减少服务调用并发数，确保核心应用的正常运行；二是关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为核心应用服务让出资源；

⑤ 幂等性设计：保证服务重复调用和调用一次产生的结果相同；

5. 五、高可用的数据

对于大多数网站而言，数据是其最宝贵的物质资产。

保证数据高可用的主要手段有两种：一是数据备份，二是失效转移机制；

① 数据备份：又分为冷备份和热备份，冷备份是定期复制，不能保证数据可用性。热备份又分为异步热备和同步热备，异步热备是指多份数据副本的写入操作异步完成，而同步方式则是指多份数据副本的写入操作同时完成。

关系数据库的热备机制就是通常所说的主从同步机制，实践中通常使用读写分离的方法来访问 Master 和 Slave 数据库，也就是说写操作只访问 Master 库，读操作均访问 Slave 库。

PS：在 MS SQL Server 中，可以通过发布订阅功能实现主从分离。关于发布订阅，可以参考 MSDN 的这篇文章：http://technet.microsoft.com/zh-cn/ff806143.aspx

② 失效转移：若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都要重新路由到其他服务器，保证数据访问不会失败。

6. 六、高可用的 QA

① 网站发布：在柔性的发布过程中，每次关闭的服务都是集群中的一小部分，并在发布完成后立即可以访问；

② 自动化测试：使用自动测试工具或脚本完成测试；

③ 预发布验证：引入预发布服务器，与正式服务器几乎一致，只是没有配置在负载均衡服务器上，外部用户无法访问；

④ 代码控制：目前大多数网站采用 SVN，分支开发，主干发布模式；另外，目前开源社区广泛采用 Git 作为版本控制工具，正逐步取代 SVN 的地位；

7. 七、网站运行监控

”不允许没有监控的系统上线“

（1）监控数据采集

① 用户行为日志收集：服务器端的日志收集和客户端的日志收集；目前许多网站逐步开发基于实时计算框架 Storm 的日志统计与分析工具；

② 服务器性能监控：收集服务器性能指标，如系统 Load、内存占用、磁盘 IO 等，及时判断，防患于未然；

③ 运行数据报告：采集并报告，汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑；

（2）监控管理

① 系统报警：配置报警阀值和值守人员联系方式，系统发生报警时，即使工程师在千里之外，也可以被及时通知；

② 失效转移：监控系统在发现故障时，主动通知应用进行失效转移；

③ 自动优雅降级：为了应付网站访问高峰，主动关闭部分功能，释放部分系统资源，保证核心应用服务的正常运行；—>网站柔性架构的理想状态

5 高可用架构