分布式场景下的稳定性保障

分布式场景下的稳定性保障

1. 什么是稳定性保障

稳定性保障的核心是确保系统始终保持高可用状态，将不可用的时间控制在极低范围内，例如每年仅允许发生几十分钟的不可用情况。为什么需要稳定性保障？因为现代社会中，许多电商和支付系统已经成为关键的社会基础设施，其长时间的不可用不仅会带来巨大的经济损失，还会严重削弱用户的信任。

稳定性保障适用于各种流量巨大的业务场景，例如直播、电商大促、秒杀活动等。例如，2022年9月3日晚刘德华线上演唱会“把我唱给你听”，吸引了3.5亿人次观看，这样的活动需要强大的系统稳定性保障。同样，电商平台的618、双11等促销活动，以及日常的高并发交易场景（如秒杀茅台、12306平台抢票）也对系统的稳定性提出了极高的要求。

2. 明确稳定性保障目标

2.1 确定一级目标

稳定性保障的首要任务是明确一级目标。例如，某明星直播活动需要支持3亿还是6亿人次观看，或某支付系统需要支持的峰值TPS（每秒事务数）是多少。常见的业务稳定性目标包括全年可用率达99.995%，对应全年仅允许约26分钟的不可用时间（525600分钟 × 0.00005）。

另一个重要目标是系统的峰值负载能力，包括峰值QPS（每秒请求数）和TPS。这些目标应根据具体场景区分为日常保障目标和大促保障目标。大促场景下的负载能力通常比日常高出许多倍，例如大促峰值目标可能是日常峰值的十倍或上一年大促峰值的两倍。虽然精准估算并不容易，但建议在资源配置时尽量估算较高的负载上限。

2.2 拆解二级目标

在确定一级目标后，需要进一步细化为二级目标。例如，如果支付系统的一级目标是支持某个TPS峰值，则应拆解为支付咨询量、交易创建量等具体指标。这种拆解可以确保每个子系统都能获得针对性的稳定性保障，从而避免顾此失彼的情况。

比如，在支付场景中，仅关注支付的TPS峰值是不够的。如果交易创建接口的性能无法保障，即使支付接口稳定，整体业务仍然会受到影响。因此，必须对所有相关的关键指标进行全面的保障。

3、如何进行稳定性保障

稳定性保障的过程可以分为链路梳理、全链路压测、集群扩容、服务限流、提前预案和紧急预案等多个环节。本文将以秒杀业务为例，详细说明如何实现这些保障措施。

3.1 全链路梳理

全链路梳理是指对各系统间的调用量进行分析，包括主链路系统、消息中间件和数据库等。以秒杀系统为例，全链路梳理的重点在于以下几个方面：

• 减少依赖：对于某些服务，可以直接依赖缓存。例如，如果电商系统查询某些数据依赖于系统A，而这些数据更新不频繁，可以将其直接放入缓存集群中以减少依赖。
• 同步改异步：对于性能要求高但无需及时响应的接口，可以采用同步受理、异步处理的方式。
• 增加限流配置：主链路中涉及的所有接口都应配置限流，以确保在高并发场景下的系统稳定性。
• 增加降级开关：如果系统负载过大，可通过降级开关拦截部分请求，降低系统压力。

3.2 全链路压测

全链路压测是检验系统稳定性的核心手段，尤其对于秒杀业务这样高并发的系统，通过压测可以了解系统的高可用水位，例如系统最大承载的 QPS 和 TPS。

压测前需注意以下事项：

• 优先在生产环境中进行压测，确保真实链路的验证效果，但需要提前通知相关系统负责人。
• 配置限流，逐步提高压测流量，确保限流机制正常工作。
• 区分读流量和写流量的压测。读流量对线上影响较小，而写流量需写入影子表，避免影响线上数据。
• 每次系统变更后需重新进行压测，以确保性能稳定性。

压测过程中需要关注以下关键指标：

• 系统指标：包括应用错误数和业务流程的正常运行情况。
• 机器性能指标：如 CPU 利用率、IO、负载、带宽流量、线程池状态等。
• 消息处理：检查消息是否存在积压及其处理时间，确保不影响正常业务。
• 限流机制：验证限流设置的正确性，并根据需要调整限流策略。

3.3 集群扩容

集群扩容包括服务器集群、缓存集群、分布式存储和数据库的扩容。扩容时需重点关注以下几点：

• 根据单机承载的 QPS 计算集群总需求。例如，如果集群需承载 20 万 QPS，单机承载能力为 2000 QPS，则需部署 100 台机器。
• 配置限流时需考虑扩容后的调整，如单机和机房的流量匹配。
• 确保每个机房具备高可用性，即单机房能够独立支撑全量流量。
• 定期评估容量需求，例如大促前通过压测和容量预估进行扩容。

3.4 服务限流

服务限流是保护系统稳定性的关键手段。限流配置需根据系统性能水位设置，避免超过单机承载能力。限流分为以下三类：

• 单机限流配置
• 机房限流配置
• 集群限流配置

通过单机限流配置推导出机房和集群的限流数值，确保整体系统的平稳运行。

3.5 提前预案

提前预案是在大促开始前准备的保障措施，主要包括：

• 服务降级：关闭部分非核心功能，以减轻系统压力。
• 调整主链路依赖的限流配置。
• 关闭大数据同步任务，降低数据库负载。
• 关闭可降级的业务入口，例如签约和解约功能。
• 禁止发布和配置变更，减少意外风险。

3.6 紧急预案

当系统流量过大或出现问题时，可启动紧急预案。例如：

• 功能降级：将用户请求跳转至静态页面，提示活动已结束。
• 熔断机制：检测到数据异常时及时中断处理，避免进一步扩散。

紧急预案执行前需双人复核，确保执行无误，避免因误操作导致更大问题。

3.7 系统监控

系统监控分为业务流量监控和系统问题监控两部分：

• 业务流量监控：监控秒杀活动的访问量、请求量和成功量，并设置秒级监控，以快速发现问题。
• 系统问题监控：重点监控 CPU、内存、带宽、错误日志等指标，配置精准报警阈值。例如，当内存利用率超过 60%时触发报警，及时处理潜在问题。

在保障系统稳定性方面，大促活动需要在常规保障的基础上，进一步落实包括计划制定、活动准备、值班安排和复盘总结等关键环节。以下将详细介绍大促保障的实施步骤。

4.1 制定大促计划

大促保障涉及的工作内容十分繁杂，需制定全面的计划以确保万无一失。具体工作包括：

• 明确目标
• 主链路分析
• 系统分层设计
• 制定项目计划
• 执行全链路压测
• 进行集群扩容
• 预先制定和实施预案
• 配置限流策略
• 编制值班手册
• 搭建监控大盘
• 落实大促前准备
• 安排大促当天值班
• 大促后进行复盘总结

4.2 大促准备

在大促前一天，应确保以下事项已完成：

• 确认数据库权限是否已申请到位。
• 确认服务器访问权限是否已申请到位。
• 确保监控系统的访问权限无误。
• 检查各服务器的性能指标，包括IO、内存、CPU、GC、带宽、硬盘（日志）和数据库相关指标，确保状态正常。
• 确保所有提前预案均已执行完毕。
• 确认业务方拥有后台操作权限，以便大促当天若出现问题时可及时发布公告或进行其他操作。
• 将紧急预案录入应急平台，确保执行方便。
• 重启主链路系统，以清理可能已积累较高水位的缓存或CPU资源。
• 准备详尽的大促执行手册，明确问题排查、数据核对及规范操作步骤。

4.3 大促值班

大促当天，所有值班人员需注意以下事项：

• 密切关注监控大盘，确保系统无异常。
• 检查服务器性能指标，及时发现潜在问题。
• 如遇紧急情况，立即执行紧急预案，并在团队群内同步变更信息。
• 避免在排查问题时对主链路造成影响，应尽量使用单机操作，而非全局执行。
• 若某台机器出现问题，应迅速将其下线，而非尝试修复，以免拖累整体业务。为此，需提前预留足够的备用机器。

4.4 大促后复盘

大促复盘是总结活动成败的关键环节，主要包括以下内容：

• 梳理本次大促的整体性能指标及业务效果，与上次大促进行对比，评估资源投入及保障成本是否得到优化。
• 记录和分析活动中出现的所有线上问题，深入探讨问题产生的原因，并制定相应的改进措施，确保下次大促中避免类似问题发生。
• 总结本次保障过程中表现优异的环节，提炼成功经验，形成可复用的最佳实践。

通过以上步骤，全面提升大促活动的稳定性和保障效率，为业务发展保驾护航。