《大型网站技术架构》笔记：架构之高可用

---

网站的可用就是指网站可以进行有效访问，不可用就是服务器挂了，无法访问了，称为网站故障。
通常用多少个9来衡量网站的可用性。
如QQ的可用性为4个9，即99.99%，那么QQ一年之中不可用时间为：365×24×60×（1-99.99%）≈ 53分钟。

不可用的主要原因：
a.服务器硬件故障；
b.网站升级发布引起的宕机；

一个典型的网站设计基本分层架构：
应用层：不同业务产品，主要处理网站应用的业务逻辑；
服务层：共同的复用业务，如登录服务、账户管理等；
数据层：数据库服务、文件服务、缓存服务、搜索服务等

构建高可用架构的网站，主要从以上三个方面进行。

---

一、高可用的应用

分两种情况：应用无状态和应用有状态

1.1 应用无状态

所谓无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等 ，请求提交到任意服务器，处理结果都是完全一样的。

使用负载均衡进行无状态服务的失效转移

负载均衡是指将流量和数据分摊到一个集群组成的多台服务器上，提高整体的负载处理能力。当任意一台服务器宕机时，负载均衡服务器通过心跳监测机制发现该服务失去响应，就会把它从服务器列表中删除，而将请求发送到其他服务器上。为了保证系统的高可用，即使流量很小的应用，也应该至少部署两台应用服务器，使用负载均衡技术构建一个小型的集群。

负载均衡可以通过开源的免费软件或负载均衡硬件实现，都提供失效转移功能。

1.2 应用有状态

由于业务总是有状态的，常常将这些状态（上下文对象）保存在会话（Session）中。此时面临的主要问题就是应用服务器集群的Session管理。
集群环境下，Session管理主要有以下几种方案：

• Session复制
  定义：应用服务器开启Web容器的Session复制功能，集群中的几台服务器之间进行同步Session对象，使得每台服务器上都保存所有用户的Session信息。
  优点：任何一台服务器宕机都不会导致Session的丢失，而服务器使用Session时，只需要从本机获取即可。
  缺点：Session复制时的同步操作，会占用服务器和网络资源；每个服务器上都保存所有Session，在大量用户访问时，Session会占用大量内存，甚至超出服务器内存。

• Session绑定
  定义：负载均衡服务器利用源地址Hash算法，将来自同一IP的请求分发到同一台服务器上，这种方法又叫会话黏滞。
  缺点：不符合高可用的要求，一旦某台应用服务器宕机，那么该机上的Session就会丢失，用户请求切换到其他服务器上就会因为没有Session而无法完成业务。很少采用该方式。

• 利用Cookie记录Session
  定义：将Session通过Cookie保存在浏览器，每次请求时，将Session放在请求中发送给服务器，服务器处理完请求后，再将修改过的Session通过Cookie响应给浏览器。
  缺点：每次都传输Cookie，影响性能；如果用户关闭Cookie，访问就会不正常；Cookie大小有限制，能记录的信息有限。
  优点：简单易用，支持应用服务器的线性伸缩，许多网站或多或少都会使用Cookie记录Session。

• Session服务器
  定义：独立部署Session服务器，统一管理Session，应用服务器每次读写Session时，都访问Session服务器。
  实现：一种简单的方法是利用分布式缓存、数据库等，在这些产品的基础上进行包装，使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录（SSO）、用户服务等，则需要开发专门的Session服务管理平台。

---

二、高可用的服务

可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常都独立分布式部署，被具体应用远程调用。是一种无状态的服务，可以使用类似负载均衡的失效转移策略实现高可用。
此外，具体实践中，还有以下几点高可用的服务策略：

• 分级管理
  核心应用和服务、优先级低的服务区别分配不同的资源
• 超时设置
  在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或者将请求转移到提供相同服务的其他服务器上。
• 异步调用
  应用服务通过消息队列等异步方式进行调用，避免一个服务失败导致整个请求失败的情况。但对于必须确认服务调用成功才能进行下一步操作的应用不适合使用异步调用。
• 服务降级
  在访问高峰期，为保证核心应用和功能的正常，对服务降级
• 拒绝服务：拒绝低优先级应用的调用，减少服务调用的并发数或随机拒绝部分调用请求
• 关闭功能：关闭部分不重要的服务或非核心服务
• 幂等级设计
  在服务层必须保证服务重复调用和一次调用产生的结果相同，即服务具有幂等性。

---

三、高可用的数据

主要是指数据存储的高可用（不包含缓存数据的高可用），主要手段是数据备份和失效转移。

CAP原理
CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性(Avalibaility)、分区耐受性（Partition Tolerance，系统具有跨网络分区的伸缩性）这三个条件。大型网站通常选择选择强化可用性和伸缩性，而在一定程度上牺牲一致性。

数据一致性分类

• 数据强一致：各个副本的数据在物理存储中总是一致的；数据更新操作和操作响应总是一致的。

• 数据用户一致：数据在物理存储的各个副本的数据可能是不一致的，但是终端用户访问时，通过纠错和校验机制，可以确定一个一致的且正确的数据返回给用户。网站通常达到这一级别的一致性。

• 数据最终一致性：一致性最弱的一种，即物理存储的数据可能是不一致的，不同用户同时访问的结果返回也可能不一致，但系统经过一段时间的自我恢复和修正，数据会达到最终一致。

• 数据备份
  主要分为数据冷备份和热备份。冷备份是指定期将数据复制到某种存储介质。这种方式不能保证数据最终一致和数据可用，只是作为一种传统数据保护手段使用。热备份则是指对数据实时备份，分为异步热备和同步热备。

• 异步热备份
  将服务器分为主、从服务器，数据写入时，由主服务器的写操作代理模块将数据写入本机存储系统后立即返回写操作成功的响应，然后通过异步线程将写操作同步到从服务器。

• 同步热备份
  在应用程序客户端并发向多个存储服务器同时写入数据，然后等待所有存储服务器都返回操作成功的响应后，再通知应用程序写操作成功。这种情况下，没有主从之分，完全对等，便于管理和维护。由于并发写，所以性能和异步热备份差不多。

关系型数据库的Master-Slave同步机制不但解决了数据备份问题，还改善了性能：使用读写分离方式，写在Master，读在Slaver。
NoSQL都提供完备的实时备份机制。

• 失效转移
  某台服务器宕机后，将读写操作转移到其他服务器上。失效转移操作主要由三部分组成：失效确认、访问转移、数据恢复
• 失效确认：心跳监测和应用程序的访问失败报告
• 访问转移：对于完全对等的服务器，直接切换到对等的服务器上即可。如果存储不对等，就要重新计算路由，选择存储服务器。
• 数据恢复：将数据副本数目恢复到设定值

---

四、软件质量保证

• 网站发布：使用发布脚本完成，逐步更新
• 自动化测试
• 预发布验证：先把代码发到预发布服务器上进行验证，预发布服务器与正式服务器所有环境均一致，只是外部无法访问。
• 代码控制：一般采用分支开发，主干发布
• 自动化发布
• 灰度发布

---

五、网站运行监控

• 监控数据采集
• 用户行为日志收集：主要有①服务器端收集②客户端浏览器通过嵌入专门的JavaScript收集；由于日志数据量巨大，很多网站逐步开发基于实时计算框架Storm的日志统计与分析工具。
• 服务器性能监控：如系统Load、内存占用、硬盘IO、网络IO等，使用较多的工具是Ganglia
• 运行数据报告：监控一些与具体业务相关的技术和业务指标，比如缓冲命中率、平均响应延时时间等
• 监控管理
• 系统报警
• 失效转移
• 自动降级