@[toc]
微服务治理 高可用 HA (High Availability) 的一些理解
1、简介
一般来说，公司要保证4个9的高可用目标，99.99%，意味着一年的停机时间是 0.876 小时
高可用的目的是通过设计减少系统的不可用时间
目前解决高可用的两个核心要点就是冗余和故障转移
高可用的核心是冗余，也就是备份，挂了之后，backup 可以立马顶上
另外，人工干预会导致故障恢复时间变成，因此系统的高可用还必须要实现自动故障转移
2、Nginx 高可用
Nginx 的高可用 （通过 keepalive + 虚拟 IP）
部署两台 Nginx ，一台提供服务，另外一台冗余，通过 keepalive 存活探测，Nginx 使用相同的虚拟 IP 提供服务
如果使用的 Nginx 挂了，keepalive 可以探测到并自动进行故障转移，将流量迁移到 shadow-nginx，因为使用相同的
虚拟 IP，所以切换过程对调用方没有影响
3、站点层的高可用
部署两个站点，Nginx 可以配置多个 Web ，Nginx 可以探测到多个 Web 的存活性
并自动进行故障转移，整个过程由 Nginx 完成
4、服务层 Service 的高可用
服务层的高可用通过部署多个实例进行负载，也可以根据流量情况在阀值情况下进行自动扩容
注册中心承担了一部分职能
5、缓存层的高可用
可以通过对缓存数据的冗余来实现高可用，Service 对缓存进行双读写
也可以通过支持主从同步的缓存集群来解决高可用问题
Redis 天然支持主从同步，官方也有 sentinel 哨兵机制做存活性检测
sentinel 可以探测到 Redis 是否可用并自动转移故障访问到其它 Redis
但是缓存并不是完全的需要绝对可用，对于允许缓存丢失的业务场景，可以对 Key 进行水平切分访问到不同的实例去
如果某个实例挂了，可以直接返回 Cache Miss
6、数据库层面的高可用
一般较大的数据库架构都采用了 【读写分类、主从同步】 的架构，所以这里高可用要分为两个
一个是读库的高可用，一个是写库的高可用
读库的话，可以多冗余几个数据库实例，数据库连接池会与多个读库进行连接，
连接池可以探测数据库的可用性并自动进行故障转移
写库这边，也是冗余，通过 MySql 双主同步，一台对线上提供服务，另外一台冗余
常见的方案是通过 keepalived 和虚拟 IP 方案进行解决，同 Nginx
