高可用是通过某种协议或技术，协调服务端为客户端提供持续性服务。
归纳为三种方式：
- 客户端对服务端服务进行健康管理，自动容错
- 服务端通过容错或网关协议提供统一的服务地址
- 服务端通过高可用模块通知客户端更新服务地址。
从客户端调用服务端维度来考虑，高可用就是 客户端调用服务端持续可用，两种方法，一种在客户端来做，一种在服务端来做：
- 客户端调用多个服务端地址，客户端通过自动容错服务端，保证高可用。
- 客户端调用一个服务端地址，服务端通过容错协议提供高可用地址，保证高可用。
- 客户端调用一个服务端地址，服务端通过高可用模块检测故障，通知客户端更新服务地址，保证高可用。
一次完整的服务请求过程包括以下组件：
- DNS
- LB
- Webapp
- Service
- DB
应用整体高可用需要每层每个组件高可用。
我们依次分析各层各个组件的高可用情况。
客户端
客户端为边缘节点，是最终使用者。
- 客户端配置主备DNS地址，主DNS故障时，请求被DNS
- 客户端调用一个负载均衡地址，负载均衡保证该地址高可用
外部与下游服务
- 主备DNS
- 高可用LB
DNS
DNS通过提供主备DNS，提供域名解析服务的高可用，同时辅以本地DNS缓存。
- 对外提供主备DNS地址
- 主DNS故障时，备DNS提供服务。
- 通过 区域传输技术
传统LB
这里指内网负载均衡
传统LB一般采用 Keepalived+反向代理 方案， 通过Keepalived基于 VRRP协议
- 对外提供VIP
- Keepalived负载负载均衡高可用
- Keepalived通过配置优先级选择主Keepalived实例
- 主实例故障时，选择优先级高的备实例为主实例
- 主实例周期性的向备实例发送VRRP通告报文
- 备实例三个周期间隔没有收到通告报文，备实例发起VRRP通告报文，根据优先级，选择优先级高的作为主实例。
- Keepalived对反向代理进行健康管理，保证反向代理可用性
- 反向代理对后端实例进行健康检测，保证后端服务可用性
腾讯CLB
腾讯CLB集群由多台LD组成，通过OSPF协议保证集群高可用性。
- 若一台LD发生故障，OSPF协议可以保证10秒以内把LD服务器从集群中剔除。
- 跨集群通过上层轮询来保证可用性。
阿里SLB
阿里SLB，通过BGP协议实现跨可用区容灾，通过云解析DNS等产品实现跨地域容灾。
以同一个地域双可用区为例，即同城双机房：
- 每个机房部署各两个节点
- 两个机房共用负载均衡配置信息，通过配置大小段路由控制流量指向。
- 当一个机房故障时，通过BGP协议自动秒级收敛路由，外部访问的流量会被转发给另外一个机房的SLB。
Webapp
Webapp负责业务页面层，挂载到LB后边。
- 对外提供多个实例地址
- 实例通常为无状态可横向扩展
- 单个故障不影响服务，负载均衡会对其进行健康检测，自动剔除与恢复
外部与下游服务
- 服务注册与发现
- 多实例Service
服务注册与发现作为关键组件，需要提供高可用注册与发现服务
不同的服务注册与发现的高可用大同小异，使用到的关键组件均做到高可用。
除了部署多实例，上游服务一般会缓存服务发现的结果，即使服务注册与发现系统出现短暂的故障，也对业务影响较小。
Service
Service负责业务层，提供专项服务。
- 对外提供多个实例地址
- 实例通常为无状态可横向扩展
- 单个故障不影响服务，客户端与服务注册与发现组件会对service进行健康管理，保证Service服务整体可用
外部与下游服务
- Service
- DB
- 缓存
- 消息中间件
Service间调用与webapp调用service相同
传统DB
数据库用于保存服务数据，是业务的核心。
以MySQL为例，采用MySQL+Keepalived方案提供高可用
- 对外提供VIP
- 默认主实例提供读写，主实例故障Keepalived漂移VIP到备实例，备实例提供读写服务
- 主备通过半同步保证数据一致性，网络波动时降级为异步复制，存在数据不一致的情况
主备切换，可能因为网络问题出现数据丢失的问题。
网络出现分区，存在脑裂的情况，脑裂导致数据库多主，业务数据出现错乱，需要尽量避免这种情况
建议当出现主实例停止服务，网络分区等故障时，备实例提供只读服务，避免因多主导致业务数据错乱，较难恢复的情况。
数据强一致性问题，可以考虑采用基于分布式一致性协议的新数据库系统
腾讯云 云数据库 MySQL
腾讯云数据库MySQL内网使用IP端口访问，外网使用域名端口访问。
资料较少，可能与实际情况不符，仅供参考。
内网访问路径为：SLB，MySQL
外网访问路径为：DNS，SLB，MySQL
Proxy访问路径为：Proxy MySQL
- DNS通过主备提供高可用
- SLB通过OSPF内部网关协议，提供高可用
- MySQL主实例故障后，自动检测，自动故障迁移到备实例，DNS、SLB地址不变
- Proxy
- 采用集群架构部署，多节点保证故障平滑转移。
- 可以通过跨可用区部署的方式来提升数据库代理的可用性。
阿里云 云数据库 RDS
数据库访问路径为：DNS，SLB，Proxy，RDS
- 对外提供唯一DNS地址访问，应用应关闭相关DNS缓存
- 高可用模块检测到主数据库实例故障时，切换到备数据库实例服务，DNS地址不变
资料较少，可能与实际情况不符，仅做参考。
把RDS当成一个应用来看，每一层都需要保证高可用
DNS通过主备提供高可用
SLB通过网关协议BGP提供高可用
独享代理是高可用架构，拥有2个节点，并且出现故障时会自动切换到备节点。
RDS通过高可用模块检测故障，通知上层更新后端地址，实现RDS高可用（有状态应用上层挂载一个后端地址，与普通无状态应用不同，无状态应用上层直接挂载多个后端地址）
总结
总结以上高可用方案，发现以下特点
- 多实例
- 客户端连接多个地址，服务端提供多个连接地址。
- 客户端对服务端进行健康管理，自动容错
- 应用客户端操作系统对DNS服务进行健康管理
- Keepalived对反向代理服务进行健康管理
- 反向代理对Webapp服务进行健康管理
- Webapp对Service服务进行健康管理
- Service对DB服务进行健康管理（Service使用mysql connector连接多个TiDB Server启用故障转移）
- 同时可以结合中间服务（服务注册与发现），提高服务容错效率（服务发现通知客户端隔离某个服务）。
- 客户端连接一个地址，服务端通过某种协议与技术，提供一个地址，保证其高可用。
- Keepalived通过VRRP协议，保证VIP高可用
- 腾讯CLB通过OSPF协议，保证VIP高可用
- 阿里SLB通过BGP协议，保证VIP高可用
- 阿里RDS通过HA模块，通知上层更新连接地址，保证服务高可用（类似于服务注册与发现）
