**Availability**：描述网站可有效访问的特性(不同于另一个网站运营指标，`Usability`通常也被译作可用性。后者强调的是网站的有用性，即对最终用户的使用价值)。 相比于网站的其他非功能特性，网站的可用性更牵动人们的神经，大型网站的不可用事故直接影响公司形象和利益，许多互联网公司都将网站可用性列入工程师的绩效考核，与奖金升迁等利益挂钩。 * 对公司而言，可用性关系网站的生死存亡。 * 对个人而言，可用性关系到自己的绩效升迁。 工程师对架构做了许多优化、 对代码做了很多重构, 对性能、 扩展性、 伸缩性做了很多改善，但别人未必能直观地感受到，也许你的直接领导都不知道你做的这些意义何在。 但如果你负责的产品出了重大故障，CEO 都会知道你的名字。 事物总是先求生存，然后求发展。保证网站可用，万无一失，任重而道远。 [TOC] ## 2.1 高可用性架构 ### 2.1.1 企业级应用系统 为提高系统可用性，会采用较昂贵的软硬件设备，如 * IBM的小型机乃至中型机大型机及专有操作系统 * Oracle 数据库 * EMC 存储设备等。 ### 2.1.2 互联网公司 更多地采用 * PC级服务器 * 开源的数据库 * 开源的操作系统 上述廉价的设备在节约成本的同时也降低了可用性。 特别是服务器硬件设备，低价的商业级服务器一年宕机一次是一个大概率事件，而那些高强度频繁读写的普通硬盘，损坏的概率则要更高一些。 既然硬件故障是常态，网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、 数据依然保存并能够被访问。 实现上述高可用架构的主要手段是**数据和服务的*冗余备份*及*失效转移***。一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。 典型的网站架构通常遵循三层分层模型： * 应用层：负责具体的业务逻辑； * 服务层：负责提供可复用的服务； * 数据层：负责数据的存储于访问。 中小型网站在具体部署时，通常把应用层和服务层部署在一起，数据层则另外部署。 复杂的大型网站，则在各层中有更细的划分粒度，更大的服务器规模。  :-: 分层按模块分割的网站架构模型 大型网站的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。 关闭服 务或者服务器宕机时产生的影响也不相同，高可用的解决方案也差异甚大。 1. **应用层服务器** 通常为了应对高并发的访问请求，通过集群方式实现高可用 - 通过*负载均衡设备*将一组服务器组成一个*集群*共同对外提供服务； - 负载均衡设备通过*心跳检测*等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的服务器上；保持整个集群保持可用。 2. **服务层服务器** 也是通过集群方式实现高可用。这些服务器被应用层通过*分布式服务调用框架*访问，分布式服务调用框架 - 会在应用层客户端程序中实现软件负载均衡； - 通过服务注册中心对提供服务的服务器进行心跳检测, 发现有服务不可用, 立即通知客户端程序修改服务访问列表,剔除不可用的服务器。 3. **数据层服务器** 位于数搌层的服务器情况比较特殊，数据服务器上存储着数据，为了保证服务器宕机时数据不丢失，数据访问服务不中断，需要 - 在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。 - 当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。 ### 2.1.3 网站升级 网站升级的频率一般都非常高，大型网站一周发布一次，中小型网站一天发布几次。 每次网站发布都需要关闭服务，重新部署系统，整个过程相当于服务器宕机。 因此网站的可用性架构设计不但要考虑实际的硬件故障引起的宕机，还要考虑网站升级发布引起的宕机，而后者更加频繁，不能因为系统可以接受偶尔的停机故障就降低可用性设计的标准。 ## 2.2 高可用的应用 应用层主要处理网站应用的业务逻辑，也称为业务逻辑层。要实现高可用性，主要基于应用的无状态性来实现。 ### 2.2.1 通过负载均衡进行无状态服务的失效转移  :-: 利用负载均衡服务器实现高可用的应用服务 **无状态的应用**：是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例 (服务器) 之间完全对等，请求提交到任意的服务器，处理的结果都一样。 无状态的应用的好处： * 对于终端用户，其请求总是能被系统成功处理。 * 对于应用服务器集群，通过负载均衡来实现服务器可用状态实时监测、自动转移失败任务。 **负载均衡**： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载处理能力。 目前，不管是开源免费的负载均衡软件还是昂贵的负载均衡硬件，都提供失效转移功能。 在网站应用中，当集群中的服务是无状态对等时，负载均衡可以起到事实上高可用的作用，如上图所示。 ### 2.2.2 应用服务器集群的SESSION管理 但业务总是有状态的。 交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品； 社交类的网站，需要记录用户的当前登录状态、最新发布的消息及好友状态等，用户每次刷新页面都需要更新这些信息。 Web应用中将这些多次请求修改使用的上下文对象称作`会话（SESSION）`。 单机情况，`SESSION`可由部署在服务器上的Web容器（`JBoss`）管理； 负载均衡的集群中，由于负载均衡服务器会把请求发到集群的任意一台应用服务器上，所以保证每次请求依然能获取正确的`SESSION`要比单机复杂很多。主要的方法有： 1. SESSION复制 Session复制是早期企业应用系统使用较多的一种服务器集群Session管理机制。 具体为： 应用服务器开启Web 容器的Session 复制功能，在集群中的几台服务器之间同步 Session 对象，使得每台服务器上都保存所有用户的 Session 信息， 这样任何一台机器宕机都不会导致Session 数据的丢失，而服务器使用 Session时，也只需要在本机获取即可。 如下图所示。  :-: 使用SESSION复制实现应用服务器共享SESSION * 优点： 方案简单，从本机读取Session 信息也很快速。 * 缺点： 只能使用在集群规模比较小的情况。 当集群规模较大时，集群服务器间需要大量的通信进行Session 复制，占用服务器和网络的大量资源，系统不堪负担。 而且由于所有用户的 Session信息在每台服务器上都有备份，在大量用户访问的情况下，甚至会出现服务器内存不够Session使用的情况。 而大型网站的核心应用集群就是数千台服务器，同时在线用户可达千万，因此并不适用这种方案。 2. SESSION绑定 Session 绑定可以利用负载均衡的源地址Hash算法实现。 负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上(也可以根据Cookie 信息将同一个用户的请求总是分发到同一台服务器上，当然这时负载均衡服务器必须工作在 HTTP 协议层上)，这样在整个会话期间，用户所有的请求都在同一台服务器上处理，即Session 绑定在某台特定服务器上，保证 Session 总能在这台服务器上获取。这种方法又被称作`会话黏滞`，如下图所示。  :-: 利用负载均衡的会话黏滞机制将请求绑定到特定服务器 * 优点 整个会话期间，用户所有的请求都在同一台服务器上处理。 * 缺点 一旦某台服务器宕机，那么该机器上的 Session 也就不复存在了，用户请求切换到其他机器后因为没有Session 而无法完成业务处理。 Session绑定的方案不符合我们对系统高可用的需求。 因此虽然大部分负载均衡服务器都提供源地址负载均衡算法，但很少有网站利用这个算法进行Session管理。 3. 利用Cookie记录SESSION  :-: 利用Cookie记录SESSION * 优点 Cookie 的简单易用，可用性高，支持应用服务器的线性伸缩，而大部分应用需要记录的 Session 信息又比较小。 * 缺点 Cookie有大小限制，能记录的信息有限；每次请求响应都需要传输 Cookie，影响性能；如果用户关闭 Cookie，访问就会不正常。 事实上, 许多网站都或多或少地使用 Cookie记录 Session. 4. 使用SESSION服务器 利用独立部署的Session服务器(集群)统一管理Session，应用服务器每次读写 Session时，都访问 Session服务器，如下图所示。  :-: 利用SESSION服务器共享SESSION 这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。 有状态的Session服务器 * 一种比较简单的方法：是利用分布式缓存，数据库等，在这些产品的基础上进行包装，使其符合 Session 的存储和访问要求。 * 专门的Session 服务管理平台：应对业务场景对Session 管理有比较高的要求，比如利用 Session 服务集成单点登录(SSO)、用户服务等功能。 ## 2.3 高可用的服务 ## 2.4 高可用的数据 ## 2.5 高可用网站的软件质量 ### 2.5.1 网站发布 ### 2.5.2 自动化测试 ### 2.5.3 预发布验证 ### 2.5.4 代码控制 ### 2.5.5 自动化发布 ### 2.5.6 灰度发布 ## 2.1 监控数据 ### 2.1.1 用户行为日志 用户行为日志：指用户在浏览器上所做的所有操作及其所在的操作环境。包括用户的 * 操作系统版本信息 * 浏览器版本信息 * IP地址 * 页面访问路径 * 页面停留时间等 这些数据对统计网站PV/UV指标、分析用户行为、优化网站设计、个性化营销与推荐等非常重要。 具体用户行为日志收集手段有两种： * 服务器端日志收集。 Apache等几乎所有Web服务器都具备日志记录功能，可以记录大部分用户行为日志，开启 Web 服务器的日志记录功能即可。 其缺点是可能会出现信息失真，如IP地址是代理服务器地址而不是用户真实IP，无法识别访问路径等。 * 客户端浏览器日志收集。 利用页面嵌入专门的 JavaScript 脚本可以收集用户真实的操作行为,因此比服务器日志收集更加精准。其缺点是比较麻烦,需要在页面嵌入特定的JavaScript脚本来完成。 ### 2.1.2 服务器性能 网站的运维人员可以在初始化系统时进行统一的部署，对服务器性能指标数据进行收集。主要的指标有： * 系统Load * 内存占用 * 磁盘I/O * 网络I/O等 尽早做出故障预警，及时判断应用状况，防患于未然，将故障扼杀在萌芽时期非常重要。 此外根据性能监控数据 * 运维工程师，可以合理安排服务器集群规模。 * 架构师，及时改善系统性能及调整系统伸缩性策略。 ### 2.1.3 运行数据报告 与具体业务场景相关的技术和业务指标，例如 * 缓存命中率 * 平均响应延迟时间 * 每分钟发送邮件数目 * 待处理任务总数 上述的运行数据需要在具体的应用程序中采集并报告，汇总后统一显示，需要应用程序在代码中处理运行数据采集的逻辑。 ## 2.2 监控管理 监控数据采集后，除了用作系统性能评估、集群规模伸缩性预测等，还可以根据实时监控数据进行风险预警， 并对服务器进行失效转移，自动负载调整，最大化利用集群所有机器的资源。 ### 2.2.1 系统报警 监控管理系统配置报警阈值和值守人员的联系方式，报警方式除了邮件，即时通信工具，还可以配置手机短信，语音报警。 相关人员接到报警后需要及时采取措施，在故障还未发生时就消除隐患防患于未然。 ### 2.2.2 失效转移 除了应用程序访问失败时进行失效转移，监控系统还可以在发现故障的情况下主动通知应用，进行失效转移。 ### 2.2.3 自动优雅降级 优雅降级是指网站为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心功能正常访问的一个手段。 例如：淘宝每年一次的 “双十一” 促销活动主动关闭“评价”、“确认收货”等非核心功能，以保证交易功能的正常进行，就可以看作是一种优雅降级。 网站在监控管理基础之上实现自动优雅降级，是网站柔性架构的理想状态：监控系统实时监控所有服务器的运行状况, 根据监控参数判断应用访问负载情况 * 如果发现部分应用负载过高，而部分应用负载过低，就会适当卸载低负载应用部分服务器，重新安装启动部分高负载应用，使应用负载总体均衡； * 如果所有应用负载都很高，而且负载压力还在继续增加，就会自动关闭部分非重要功能，保证核心功能正常运行. ## 2.3 监控工具 ### 2.3.1 实时日志统计与分析——`Storm` 大型网站的用户日志数据量惊人，数据存储与计算压力很大，目前许多网站逐步开发基于实时计算框架`Storm`的日志统计与分析工具。 ### 2.3.2 实时性能监控——`Ganglia` 开源性能监控工具是`Ganglia`，它支持大规模服务器集群，并支持以图形的方式在浏览器展示实时性能曲线。 ## 2.2 优化方法