对外，两个 LVS 以主备的形式对外提供服务，注意只有 master 在工作（即此时的 VIP 在 master 上生效），另外一个 backup 在 master 宕机之后会接管 master 的工作，那么 backup 怎么知道 master 是否正常呢，答案是通过 keepalived，在主备机器上都装上 keepalived 软件，启动后就会通过心跳检测彼此的健康状况，一旦检测到 master 宕机，keepalived 会检测到，从而 backup 自动转成 master，对外提供服务，此时 VIP 地址（即图中的 115.204.94.139）即在 backup 上生效，也就是我们常说的「IP漂移」，通过这样的方式即解决了 LVS 的高可用。
keepalived 的心跳检测主要通过发送 ICMP 报文，或者利用 TCP 的端口连接和扫描检测来检测的，同样的，它也可以用来检测 Nginx 暴露的端口，如果某些 Nginx 不正常 keepalived 也能检测到并将其从 LVS 能转发的服务列表中剔出。
借用 keepalived 这个第三方工具，同时实现了 LVS 和 Nginx 的高可用，同时在出现故障时也可以将宕机情况发送到对应开发人员的邮箱以让他们及时收到通知处理，确实很方便，keepalived 应用广泛，下文我们也能看到它也可以用在 MySQL 上来实现 MySQL 的高可用。
微服务接下来我们再来看一下「网关」，「站点层」,「基础服务层」，这三者一般就是我们所说的微服务架构组件，当然这些微服务组件还需要通过一些 RPC 框架如 Dubbo 来支撑，所以微服务要实现高可用，就意味着 dubbo 这些 RPC 框架也要提供支撑微服务高可用的能力，我们就以 dubbo 为例来看下它是如何实现高可用的
我们先来简单地看下 dubbo 的基本架构
思路也很简单，首先是 Provider（服务提供者）向 Registry（注册中心，如 ZK 或 Nacos 等）注册服务，然后 Consumer（服务消费者）向注册中心订阅和拉取 Provider 服务列表，获取服务列表后，Consumer 就可以根据其负载均衡策略选择其中一个 Provider 来向其发出请求，当其中某个 Provider 不可用（下线或者因为 GC 阻塞等）时，会被注册中心及时监听（通过心跳机制）到，也会及时推送给 Consumer，这样 Consumer 就能将其从可用的 Provider 列表中剔除，也就实现了故障的自动转移，不难看出，注册中心就起到了类似 keepalived 的作用
中间件我们再来看下这些中间件如 ZK，Redis 等是如何实现高可用的呢
ZK上一节微服务中我们提到了注册中心，那我们就以 ZK（ZooKeeper）为例来看看它的高可用是如何实现的，先来看下它的整体架构图如下
Zookeeper 中的主要角色如下
Leader: 即领导者，在集群中只有一个 Leader，主要承担了以下的功能
事务请求的唯一调度和处理者，保证集群事物处理的顺序性，所有 Follower 的写请求都会转给 Leader 执行，用来保证事务的一致性
集群内部各服务器的调度者：处理好事务请求后，会将数据广播同步到各个 Follower，统计 Follower 写入成功的数量，超过半数 Follower 写入成功，Leader 就会认为写请求提交成功，通知所有的 Follower commit 这个这与操作，保证事后哪怕是集群崩溃恢复或者重启，这个写操作也不会丢失。
Follower:
处理客户端非事务请求、转发事务请求给 leader 服务器
参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票）
参与 Leader 选举的投票
画外音：Zookeeper 3.0 之后新增了一种 Observer 的角色，不过与此处讨论的 ZK 高可用关系不是很大，为了简化问题，所以省略
可以看到由于只有一个 Leader，很显然，此 Leader 存在单点隐患，那么 ZK 是怎么解决此问题的呢，首先 Follower 与 Leader 会用心跳机制保持连接，如果 Leader 出现问题了（宕机或者因为 FullGC 等原因无法响应），Follower 就无法感知到 Leader 的心跳，就会认为 Leader 出问题了，于是它们就会发起投票选举，最终在多个 Follower 中选出一个 Leader 来（这里主要用到了 Zookeeper Atomic Broadcast，即 ZAB 协议，它是为 ZK 专门设计的一种支持崩溃恢复的一致性协议），选举的细节不是本文重点，就不在此详述了。