大家好，我是坤哥
今天我们来聊一下互联网三高（高并发、高性能、高可用）中的高可用，看完本文相信能解开你关于高可用设计的大部分困惑
前言高可用（High availability，即 HA）的主要目的是为了保障「业务的连续性」，即在用户眼里，业务永远是正常（或者说基本正常）对外提供服务的。高可用主要是针对架构而言，那么要做好高可用，就要首先设计好架构，第一步我们一般会采用分层的思想将一个庞大的 IT 系统拆分成为应用层，中间件，数据存储层等独立的层，每一层再拆分成为更细粒度的组件，第二步就是让每个组件对外提供服务，毕竟每个组件都不是孤立存在的，都需要互相协作，对外提供服务才有意义。
要保证架构的高可用，就要保证架构中所有组件以及其对外暴露服务都要做高可用设计，任何一个组件或其服务没做高可用，都意味着系统存在风险。
那么这么多组件该怎么做高可用设计呢，其实任何组件要做高可用，都离不开「冗余」和「自动故障转移」，众所周知单点是高可用的大敌，所以组件一般是以集群（至少两台机器）的形式存在的，这样只要某台机器出现问题，集群中的其他机器就可以随时顶替，这就是「冗余」。简单计算一下，假设一台机器的可用性为 90%，则两台机器组成的集群可用性为 1-0.1*0.1 = 99%，所以显然冗余的机器越多，可用性越高。
但光有冗余还不够，如果机器出现问题，需要人工切换的话也是费时费力，而且容易出错，所以我们还需要借助第三方工具（即仲裁者）的力量来实现「自动」的故障转移，以达到实现近实时的故障转移的目的，近实时的故障转移才是高可用的主要意义
怎样的系统可以称之为高可用呢，业界一般用几个九来衡量系统的可用性，如下
可用性级别 系统可用性% 宕机时间/年 宕机时间/月 宕机时间/周 宕机时间/天不可用 90% 36.5 天 73 小时 16.8 小时 144 分钟
基本可用 99% 87.6 小时 7.3 小时 1.68 小时 14.4 分钟
较高可用 99.9% 8.76 小时 43.8 分钟 10.1 分钟 1.44 分钟
高可用 99.99% 52.56 分钟 4.38 分钟 1.01 秒 8.64 秒
极高可用 99.999% 5.26 分钟 26.28 秒 6.06 秒 0.86 秒
一般实现两个 9 很简单，毕竟每天宕机 14 分钟已经严重影响业务了，这样的公司迟早歇菜，大厂一般要求 4 个 9，其他要求严苛的业务要达到五个九以上，比如如果因为一个电脑的故障导致所有列车停驶，那么就会有数以万计的人正常生活受到阻碍，这种情况就要求五个九以上
接下来我们就来一起看看架构中的各个组件如何借助「冗余」和「自动故障转移」来实现高可用。
互联网架构剖析目前多数互联网都会采用微服务架构，常见架构如下:
可以看到架构主要分以下几层
接入层：主要由 F5 硬件或 LVS 软件来承载所有的流量入口
反向代理层：Nginx，主要负责根据 url 来分发流量，限流等
网关：主要负责流控，风控，协议转换等
站点层：主要负责调用会员，促销等基本服务来装配 json 等数据并返回给客户端
基础 service：其实与站点层都属于微服务，是平级关系，只不过基础 service 属于基础设施，能被上层的各个业务层 server 调用而已
存储层：也就是 DB，如 MySQL，Oracle 等，一般由基础 service 调用返回给站点层
中间件：ZK，ES，Redis，MQ 等，主要起到加速访问数据等功能，在下文中我们会简单介绍下各个组件的作用
如前所述，要实现整体架构的高可用，必须要实现每一层组件的高可用，接下来我们就来分别看一下每一层的组件都是如何实现高可用的
接入层&反向代理层这两层的高可用都和 keepalived 有关，所以我们结合起来一起看