上一个是 高性能，这一篇就分析高可用。
文章目录
- 高可用实现
- 对等节点的故障转移
- 非对等节点的故障转移
- 接口层面的超时设置、重试策略和幂等设计。
- 降级处理
- 限流处理
- MQ场景的消息可靠性保证
- 灰度发布
- 监控报警
- 灾备演练
- 高可用设计方向
- 高扩展实现方案
- 合理的分层架构
- 存储层的拆分
- 业务层的拆分
高可用实现
对等节点的故障转移
Nginx和服务治理框架均支持一个节点失败后访问另一个节点。
非对等节点的故障转移
通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。
接口层面的超时设置、重试策略和幂等设计。
降级处理
保证核心服务，牺牲非核心服务，必要时进行熔断；或者核心链路出问题时，有备选链路。
限流处理
对超过系统处理能力的请求直接拒绝或者返回错误码。
MQ场景的消息可靠性保证
包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。
灰度发布
能支持按机器维度进行小流量部署，观察系统日志和业务指标，等运行平稳后再推全量。
监控报警
全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。
灾备演练
类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。
高可用设计方向
高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。
高扩展实现方案
分层 拆分
合理的分层架构
比如上面谈到的互联网最常见的分层架构，另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（但是需要评估性能，会存在网络多一跳的情况）。
存储层的拆分
按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分（分库分表）。
业务层的拆分
最常见的是按照业务维度拆（比如电商场景的商品服务、订单服务等），也可以按照核心接口和非核心接口拆，还可以按照请求源拆（比如To C和To B，APP和H5）。
