一、可用性度量

网站可用性通常用多少个9来进行衡量，比如一些大型网站可以做到4个9以上的可用性，也就是可用性超过99.99%。这样的一个指标描述的是可用时间与总时间的比值。

网站的可用性非常重要，如果某个网站或者服务崩掉，多公司所产生的影响：信誉、顾客满意度等可能非常大。

二、高可用指标

网站高可用架构设计的前提是必然会出现服务器宕机，而高可用设计的目标就是当服务器宕机（服务器硬件故障）的时候，服务或者应用依然可用。

如何设计高可用的系统

2.1 高可用的应用

在架构分层的前提下，应用层主要负责处理业务逻辑。在这部分很可能访问的请求都是带有用户状态信息的。

高可用的应用对于无状态应用很好处理。可以通过集群的方式来进行负载均衡，通过集群也可以避免单点故障：通过负载均衡进行无状态服务的失效转移。

对于有状态信息的请求可以使用 session 的方式。

  • Session 复制：在集群的几台服务器之间同步 Session 对象。当集群规模较大时，复制占用网络大量资源。
  • 利用 Cookie 记录Session。这是一种早期普遍的方式，问题主要是传输Cookie 影响性能。
  • Session 服务器。更好的一种方式

限流的方式：限流为了对服务端的接口接受请求的频率进行限制，防止服务挂掉。比如某一接口的请求限制为 100 个每秒, 对超过限制的请求放弃处理或者放到队列中等待处理。限流可以有效应对突发请求过多。

2.2 高可用的服务

手段有

  • 超时重试机制
  • 异步调用
  • 服务降级：拒绝服务（Twitter）、关闭功能（秒杀）
  • 熔断：降级的目的在于应对系统自身的故障，而熔断的目的在于应对当前系统依赖的外部系统或者第三方系统的故障。

2.3 高可用的数据

保证数据存储高可用的手段主要是数据备份和失效转移机制。

CAP 理论

CAP 原理认为：一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availability）、分区耐受性（Partition Tolerance）

  • 数据备份：冷备（简单但可用性差）与热备
  • 失效转移

主要方向就是上述两个，对于具体的环境又有更多细节的设计

  • 灾备设计

    灾备 = 容灾+备份。

    • 备份 ： 将系统所产生的的所有重要数据多备份几份。
    • 容灾 ： 在异地建立两个完全相同的系统。当某个地方的系统突然挂掉，整个应用系统可以切换到另一个，这样系统就可以正常提供服务了。

  • 异地多活

    异地多活描述的是将服务部署在异地并且服务同时对外提供服务。和传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。

    异地多活是为了应对突发状况比如火灾、地震等自然或者认为灾害。

    一文看懂异地多活

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

  • 网站发布
  • 自动化测试
  • 预发布验证
  • 自动化发布
  • 灰度发布：一部分一部分发布
  • 网站运行监控