一、整体治理：2、高并发高可用整体治理思路

承接上一章，我们已经梳理出来，哪些应用、接口，出现了性能或稳定性问题，这一章从整体思路上进行探讨解决。

一、高并发

按照先硬件后软件，先整体后局部治理思想，我们确定了如下方案：

先环境治理 ，再对流量进行有策略的切片，最后治理代码和组件

1.1 运行环境优化

运行环境，是应用的骨骼，所以运行环境的选择与配置至关重要。（硬件服务器，不在我们本期讨论范畴）

根据服务要承担的压力，服务是计算密集型还是IO密集型，分别配置对应的JVM和TOMCAT。

代码框架的优化，也是我们需要考虑的。Java目前主流的框架是Spring cloud体系。

1.2 流量管控切片

如下图是流量的4个来源，如果设计不当，这4种来源的触发时机可能不可控。如图1（流量4种来源）：

线上1、2流量经过了负载，管理端3、JOB4的流量虽然按照集群进行负载，但每次选择一台。假设3、4恰好都选择“商品-02”，而管理端在做大量导出，JOB在处理批量大任务。此时该应用服务就会压力过大，进而影响其他功能响应。

流量的切片治理，除了常规的流量分治见图2（流量分治），再分3个方面：

1. 线上与后台分离：JOB 和 后台管理独立应用进行处理
2. 减少1的无效流量：特别是爬虫、重试等
3. 减少2、3瞬时热点流量：比如整点大量数据更新

图1：流量4种来源

图2：流量分治

1.3 提升组件抗并发能力

主要对Redis、Mysql、ES数据组件，在配置设置，设计的数据模型方面，提升扛量能力

1.4 高并发编程实战

分2个部分：

• 业务设计优化
  • 高内聚设计，减少外部依赖，可控性增强
    • 通过外部服务、外部数据和缓冲案例来探讨
  • 缩短业务实时链路，减少耗时
    • 区分业务必要环节，和后续异步补偿环节
  • 精细化管理业务访问目标
    • 通过商品不同场景，期望结果不一样来探讨
• 技术组件使用优化
  • 不同场景，线程池并发编程
  • 数据库性能提升
  • Redis性能提升

二、高可用

2.1 能自保：不被上游流量打跨

• 事前：评估并弥补应用短板
• 事中：功能降级见图3(功能分级降级)、多维度限流
• 事中: 快速补充、提升服务能力

图3：功能分级降级

2.2 缩小故障范围：不被下游拖挂

• 资源隔离，缩小故障范围（图4）

图4：资源隔离

• 选择合适组件，缩小保障半径图

  • Lettuce爆炸半径
  • 
  • Jedis连接复用后的爆炸半径
  • 
• 故障转移

2.3 灾后快速恢复

• 恢复范围
  • 业务恢复
  • Redis恢复
  • Mysql恢复
• 恢复策略

2.4 高可用编程

• 经验篇

  • 杜绝内存、线程、数据库、事务、异常带来的服务不可用

• 实战篇

  • 业务幂等下高可用
  • 一致性下的高可用
  • 高并发下的高可用

三、本章总结

高并发和高可用，很多时候是交叉在一起，两个都要