大型网站技术架构 读书笔记2.2 核心架构要素之高可用

二 网站的高可用架构

  可用性：描述网站可有效访问的特性，最为基本。

  可用性度量：使网站故障时间尽可能短。

故障时间 = 故障修复时间点 - 故障报告时间点
网站年度可用性指标 = ( 1 - 年度故障时间 / 年度总时间 ) * 100%

  下面从多个角度进行可用性保证说明。

---

2.1 高可用网站架构

  前因：互联网公司一般采用PC级服务器、开源数据库和操作系统，这些廉价设备降低了系统可用性。

  高可用架构设计目标：保证服务器出现硬件故障时服务依然可用、数据依然能被读写。

  高可用架构手段：数据和服务的冗余备份和失效转移。

  在笔记1中，介绍了网站典型的分层模型；此外，还有不同业务的分割处理并进行独立服务器集群布置。这样的设计导致不同的层次有不同的可用性特点，下面对三个层次分别进行可用性方案设计。

---

2.2 高可用的应用

  应用层主要处理网站应用的业务逻辑，也称业务逻辑层，其典型特点是无状态。

  无状态：指应用服务器不保存业务的上下文信息，仅根据每次请求提交的数据进行相应的业务逻辑处理，这样，服务器之间完全对等。

  在实际设计时，因为无状态，则只需考虑使用负载均衡提高整个应用服务器集群的负载能力及某个服务器出现问题时的失效转移即可；另一方面，请求往往是有状态的，还需要进行额外的状态管理。这就是下面两小节的内容。

2.2.1 负载均衡

  负载均衡：部署服务器集群应对高并发请求时，使用负载均衡技术进行服务器可用状态实时监测和自动转移失败任务。前者通过合理安排，可提高集群的负载能力；后者则提高了可用性保障。

2.2.2 Session管理(状态管理)

  Session:多次请求修改使用的上下文对象。用以保存和更改请求的状态。

  Session管理：在单机状态，可以直接使用服务器上的Web容器(如JBoss)管理；在使用负载均衡时，由于涉及服务器集群，Session管理会很复杂。

  下面介绍在集群环境下，Session管理的几种手段：

  1. Session复制：应用服务器开启Web容器的Session复制功能，在集群的所有服务器中同步Session对象，每台服务器保存所有用户的Session信息。优点：简单易实现；缺点：易达到上限，通信较多，只适合于小型集群。

  2. Session绑定：使用负载均衡算法(Hash算法等)，将同一IP(或使用Cookie信息)的请求总是分发到同一台服务器上，也叫会话粘滞。

  3. 利用Cookie记录Session：使用Cookie将Session记录在客户端，请求时用Cookie将Session传递给服务器，再经服务器修改返回。优点：Cookie本身简单易用；缺点：与Cookie绑定，受Cookie功能大小影响。

  4. Session服务器：利用独立部署的Session服务器集群统一管理，应用服务器每次读写时，都访问Session服务器——即将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。这种方案，除了要多花钱配置，哪哪都挺好的。

---

2.3 高可用的服务

  可复用的服务模块为业务产品提供基础公共服务；在大型系统中，通常都独立分布式部署，由应用远程调用。下面介绍几种高可用的服务策略：

  1. 分级管理：在运维上将服务器分级管理，核心应用和服务使用更好的硬件；在服务部署上进行必要的隔离——低优先级服务启动不同线程或部署在不同虚拟机上；高优先级服务部署在不同物理机上，核心服务和服务部署在不同地域的数据中心。

  2. 超时设置：在应用程序中设置服务调用的超时时间，一旦超时，通信框架抛出异常，并使用服务调度策略重试。

  3. 异步调用：应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情形。不可用情形——1.获取用户信息类；2.必须确认调用成功才能进行下一步操作的应用。

  4. 服务降级：在访问高峰期高并发情形下，通过对服务降级保障核心功能和应用的正常运行。主要措施：拒绝服务和关闭服务。

  5. 幂等性设计：在服务层保证服务重复调用的结果相同。

---

2.4 高可用的数据

  重要性：数据是网站最宝贵的物质财产，失去了便不可恢复，保护数据就是保护命脉。而且现在的机器学习等手段可以利用大数据进行很多极有价值的数据分析和预测。

  数据存储高可用手段：数据备份和失效转移机制。

  缓存服务的高可用：可以使整个网站共享同一分布式缓存集群，这样对于大型网站，单台缓存服务器宕机影响较小。

  CAP原理：根据CAP原理——存储系统无法同时满足数据可用性、伸缩性和一致性这三个条件。在系统设计时，往往会通过牺牲数据一致性来获取其他两个特性。

2.4.1 数据备份

  分类：分为冷备和热备。

  数据热备：分为异步热备方式和同步热备方式。

  异步方式：应用服务器在收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本(该过程可能失败)

  同步方式：多份数据副本写入操作同时完成。

2.4.2 失效转移

  失效转移操作分为三步：失效确认、访问转移和数据恢复。

  1 失效确认：即判断服务器宕机，有两种方式——心跳检测和应用程序访问失败报告。

  2 访问转移：在确认数据存储服务器宕机后，需要将数据读写访问重新路由至其他服务器上。对于对等服务器，可以直接切换；对于不对等服务器，则需要重新计算路由。

  3 数据恢复：服务器宕机后，该服务器上存储数据的副本便减少一份；需要从健康的服务器赋值数据，将数据副本数目恢复到设定值。

2.5 高可用网站的软件质量保证

  首先说明，在网站运维中，导致系统可用性风险的不仅有网络、服务器等硬件故障；还有各种软件相关问题，尤其是软件发布时。下面介绍一些软件质量保证手段。

2.5.1 网站发布

  影响：由于应用的不断发布，用户需要面对周期性的宕机故障。

  解决方式：使用发布脚本进行分批发布。

2.5.2 自动化测试

  作用：使用自动测试工具完成一键测试部署、测试数据生成、测试执行、测试报告生成等全部测试过程。

2.5.3 预发布验证

  起因：经过严格测试后，软件部署还是会出现各种问题——测试环境和线上环境不同，特别是依赖关系，也就是无法完全仿真真实市场环境。

  解决手段：在软件正式发布前，使用预发布机器进行预发布验证，执行一些典型的业务流程，确认无误后再正式发布。

2.5.4 代码控制

  起因：大型网站的核心应用系统和共用业务模块涉及许多团队和工程师，需要对相同的代码库进行共同开发和维护。因此需要进行代码管理——保证代码发布版本的稳定正确，保证不同团队间开发互不影响。

  主流工具：Git和SVN。Git教程可以看廖雪峰老师的教程。

2.5.5 自动化发布

  基于规则驱动的火车发布模型。

2.5.6 灰度发布

  方式：将集群服务器分为若干部分，每天只发布一部分并进行运行观察；逐步发布。若发现问题，则进行回滚操作。

2.6 网站运行监控

  在网站运行过程中进行监控，根据监控信息进行管理，从而保证网站可靠性，规避风险。

2.6.1 监控数据采集

  1 用户行为日志收集：通过服务器端和用户客户端进行收集，可以用实时计算框架Storm进行日志统计与分析。

  2 服务器性能监控：收集服务器运行指标，将故障扼杀在萌芽阶段。

  3 运行数据报告：监控一些与具体业务场景相关的技术和业务指标。

2.6.2 监控管理

  作用：监控数据收集后，除了用作系统性能评估、集群规模收缩性预测等，还可根据实时监控数据进行风险预警，对服务器进行失效转移，自动负载调整等。可以实现自适应管理。