【架构设计复习】高可用，高扩展实现方案

上一个是 高性能，这一篇就分析高可用。

文章目录

• • 高可用实现
  • • 对等节点的故障转移
    • 非对等节点的故障转移
    • 接口层面的超时设置、重试策略和幂等设计。
    • 降级处理
    • 限流处理
    • MQ场景的消息可靠性保证
    • 灰度发布
    • 监控报警
    • 灾备演练
  • 高可用设计方向
  • 高扩展实现方案
  • • 合理的分层架构
    • 存储层的拆分
    • 业务层的拆分

高可用实现

对等节点的故障转移

Nginx和服务治理框架均支持一个节点失败后访问另一个节点。

非对等节点的故障转移

通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。

接口层面的超时设置、重试策略和幂等设计。

降级处理

保证核心服务，牺牲非核心服务，必要时进行熔断；或者核心链路出问题时，有备选链路。

限流处理

对超过系统处理能力的请求直接拒绝或者返回错误码。

MQ场景的消息可靠性保证

包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。

灰度发布

能支持按机器维度进行小流量部署，观察系统日志和业务指标，等运行平稳后再推全量。

监控报警

全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。

灾备演练

类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。

高可用设计方向

高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。

高扩展实现方案

分层+拆分

合理的分层架构

比如上面谈到的互联网最常见的分层架构，另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（但是需要评估性能，会存在网络多一跳的情况）。

存储层的拆分

按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分（分库分表）。

业务层的拆分

最常见的是按照业务维度拆（比如电商场景的商品服务、订单服务等），也可以按照核心接口和非核心接口拆，还可以按照请求源拆（比如To C和To B，APP和H5）。