云原生背景运维转型之 SRE 实践-技术圈

点击上方“服务端思维”，选择“设为星标”

回复”669“获取独家整理的精选资料集

回复”加群“加入全国服务端高端社群「后端圈」

作者 | 腾讯程序员出品 | 腾讯技术工程

一、前言

这篇内容我想谈谈 DevOps 的下半段，通过我们的构建服务稳定性保障实践，利用 SRE 的思想与方法，不断去冲刺稳定性的终极目标：“提升 MTBF（平均故障时间间隔）、降低 MTTR（故障平均修复时间）”，很多小伙伴会有疑问，DevOps 与 SRE 到底是什么样的关系？在 Google 出版的第二本书《The Site Reliability Workbook》的第一章节，已经明确给出了这个问题的解释，一行代码胜千言：“class SRE implements interface DevOps”，即 SRE 是 DevOps 的一种实现方式，也是 Google 在运维领域的一种具体实践。个人也比较认同这个解释，也深受启发，不得不佩服 Google 大佬的抽象与总结能力，放眼国内运维行业的发展历程，也潜移默化在形成自己的发展路径，实践与 Google 提出的 SRE 具有异曲同工之妙，缺少的是进一步做抽象，形成一套完整的方法论体系。本文的出发点也是站在巨人肩膀之上，结合自身业务服务场景，思考在云原生背景下，运维转型还有多少种可能性，本文或许只给出其中一种答案吧。

二、构建 SRE 体系

▫ SRE 能力全景

我们因地制宜，根据 IEG 海量在线营销的业务场景，引入 SRE 度量的机制、定制 SRE 准则，以及打造较为完备的工具链体系，以下是团队构建的玄图-SRE 稳定性建设全景图：

图2.1 - 玄图-SRE稳定性建设全景图

在这个体系中，云原生环境下的 IAAS 或 PAAS，我们关注的是 MTTF (Mean Time To Failure，平均无故障时间)，这个能力由基础设施团队来保障。

全景图的中间是我们的玄图 SRE 体系，采用蓝鲸多级编排组装体系中的各种能力项，MTBF 列意为平均故障时间间隔，可以理解成稳定性保障的事前与事后，在这个环节中，我们在原有基础上扩展出两个核心能力，其中一个是“混沌实验”，旨在通过主动注入服务故障，提前发现并解决系统存在的隐患，提升系统的韧性；另一个为“全链路压测”，模拟真实的并发数及用户访问，通过自动拓扑图快速找到影响性能模块，定位问题根源。MTTR 列意为故障平均修复时间，这里我们拆解了 5 个步骤，分别做下解释：

MTTI （Mean Time To ldentify）平均故障发现时间，强调团队的监控告警能力的完备性；
MTTA（Mean Time To Acknowledge）平均故障确认时间，强调团队的 OnCall 机制执行，以及制度与技术的配套；
MTTL （Mean Time To Location）平均故障定位时间，要求团队对故障的分析与解决问题经验的积累，以及平台工具的配套；
MTTT （Mean Time To Troubleshooting）平均故障解决时间，对服务高可用架构的设计、容错、扩展能力提出要求；
MTTV （Mean Time To Verify）平均故障验证时间，围绕服务体验为核心的监测体系，建立与业务、用户的反馈机制。

这个环节作为稳定性保障的“事中”尤为重要，其中可观测性作为下一代的质量监控的代表，通过强化分布式服务的日志、链路、指标的关联，缩短发现问题、解决问题的时间，可以极大缩短 MTTR 中 MTTL 的耗时。

▫ 定制 SRE 准则

在实践 SRE 过程中，我们总结并提炼了“SRE 8 准则”，来指导我们的日常运维工作。有了这 8 个准则，就很清楚我们需要具备什么样的能力与工作方法，来达成什么样的工作目标，同时也延伸出下面介绍的 SRE 工具链。首先简单介绍我们的 SRE 8 准则，下面简要进行剖析：

架构设计准则 - 我们认为所有的架构都是不完美的，都存在缺陷，因此我们在做业务架构设计时都必须要考虑服务稳定性保障，如负载均衡、多点容灾、集群化服务、数据多活等能力；
SRE 前置准则 - 在业务立项之初，SRE 角色需要提前介入，将运营阶段可能出现的问题或风险提前在架构设计、编码阶段暴露，提前准备好解决方案，甚至规避问题与风险；
混沌实验准则 - 故障不可避免，为何不让其在测试或预发布环境提前到来，通过模拟现网真实故障来验证服务的“韧性”，找出系统的弱点，同时验证我们的监控告警的有效性，在 MTBF 阶段实施最好不过，也是我们其中一把利器；
可观测性准则 - 通过采集业务指标、日志、追踪等数据，快速分析与定位问题，同时发现复杂系统的瓶颈点，在很长一段时间内，业务指标、日志、追踪的采集与应用，都是独立存在并分开建设，随着时间的推移，发现这三者是相互关联，相辅相成的，是我们的第二把利器；
全链路压测准则 - 通过与可观测性、混沌实验能力的深度整合，实现模拟真实业务环境全链路压测，达到业务上线前的精准资源评估，主动发现潜在性能、版本缺陷等问题，是我们的第三把利器；
DevOps 交付准则 - 通过打造高效的价值交付链，覆盖 CI、CD、CO 服务全生命周期运营管理，CI 我们采用 ODP 封装蓝盾方案，CD 与 CO 采用蓝鲸运维编排及监控告警等能力，SRE 会将大分部精力聚焦在 CO 环节；
故障应急准则 - 故障不可避免，我们能做的是不断去提升 MTBF，降低 MTTR，包括事前的实施大量混沌实验、故障预案；事中采用打造的工具链，快速发现、分析、定位与解决问题；事后组织总结复盘，沉淀案例经验；
SRE 学习准则 - 营造学习的文化，目的是实现多个不同职能团队的有机融合，相互了解大家面临的问题或挑战，形成一致的目标，达到有效的协同，解决业务的问题。团队于 2016 年发起的《微分享》机制，截止目前累计 250 次分享。

三、跟踪 SLO 状态

量化目标是一切工作的起点，所有运维工作都以围绕 SLO（服务水平目标）指标的定制、执行、跟踪、反馈来展开。其中定制与执行因各业务形态的差异，此处不进行展开，指导的原则是选择合适的 SLI（Service Level Indicator，服务等级指标），设定对应的 SLO。梳理与采用业务侧关注的 SLI 指标，目标值达成一致即可。我们具体的 SLI 采集实践见第一篇文章的云原生应用监控章节，其中关于识别 SLI Google 提出 VALET 法，分别是 Volume、Availability、Latency、Error 和 Ticket 的首字母，这 5 个单词就是我们选择 SLI 指标的 5 个维度。

[x] Volume（容量）服务承诺的最大容量是多少，比如常见的 QPS、TPS、会话数、吞吐量以及活动连接数等等；
[x] Availablity（可用性）代表服务是否正常或稳定，比如请求调用 HTTP 200 状态的成功率、任务执行成功率等；
[x] Latency（时延）服务响应是否足够快，比如时延是否符合正态分布，需指定不同的区间，比如常见的 P90、P95、P99 等；
[x] Error（错误率）服务有多少错误率，比如 5XX、4XX，以及自定义的状态码；
[x] Ticket（人工干预）是否需要人工干预，比如一些复杂故障场景，需人工介入来恢复服务。

定义业务相对应 SLI 的 SLO 后，跟踪 SLO 有利于稳定性目标的达成，时刻提醒还有多少错误预算可以供消费，是否应该调整版本发布的策略或节奏，更加聚焦人力在质量方面的优化。我们采用 SLO Tracker 来对接故障报单平台，获取故障单据、影响时长等信息，定期统计并做团队反馈。

图3.1 - SLO跟踪统计报表

四、工具链建设

SRE 的准则与方法论固然重要，但没有强有力的工具链来作为支撑，在执行面将面临步步维艰，因此我们在 2 年前就开始着手规划 SRE 工具链的建设，根据 SRE8 准则的平台能力要求，明确了三个发展的能力项，分别为可观测性、混沌实验、全链路压测等。首先我们也积极拥抱开源社区，得益于社区成熟技术标准与 SRE 工具链组件，让我们可以充分借用社区的力量，快速且低成本构建满足我们自身业务场景的服务能力。同时我们也积极参与开源社区，包括贡献源码，行业大会技术布道，参与中国信通院发起的行业标准定制等等。玄图-SRE 工具链体系，第一期我们通过“三位一体”，有效助力业务在“事前”提前发现潜在问题，“事中”快速定位问题根因，以及“事后”快速复盘历史故障。帮助业务实现服务高可靠性的目标。放眼行业，此组合方案也是云原生环境稳定性保障的首选。下面是玄图 SRE 工具链能力全景图：

图4.1 - 玄图-SRE工具链能力全景图

如图 4.1 所示，是我们构建 SRE 工具链的底层逻辑，首先我们打造整个体系的根基，分别定制 SRE 的标准规范、方法与目标。平台化只是将这套理论体系的实例化，在平台层面我们是以可观测性为底座，收集并共享业务的链路拓扑数据，供上层的混沌实验与全链路压测等平台进行集成，来实现更加高级的能力。通过多种能力的整合，目前已经初步具备了强弱依赖分析、资源精准评估、异常快速定位、发现服务瓶颈、业务拓扑理解、增强服务韧性等一系列核心能力。下面将逐一进行相关能力的介绍。

五、可观测性平台

1、可观测概括

在云原生时代下，应用的可观测性基础设施至关重要。在 IEG 营销服务场景下，微服务间调用关系更是错综复杂，给服务性能瓶颈分析、快速定位影响评估范围和根因分析等方面带来了诸多的挑战。云原生一线开发/运维人员时常面临以下问题：

服务调用关系错综复杂，如何快速定位问题根因？
某服务发生异常，如何快速评估影响范围？
如何快速分析复杂系统的服务瓶颈点？
服务追踪、指标和日志分开上报，问题定位难度大?
活动发布频繁，如何快速评估服务资源？

以上问题亟待建立全新的监控机制，帮助开发/运维人员全面洞察系统运行状态，并在系统异常时帮助其快速定位解决问题，云原生可观测性基础设施应运而生。可观测性则是通过采集业务指标、日志、追踪等数据，快速分析与定位问题，同时发现复杂系统的瓶颈点，在很长一段时间内，业务指标、日志、追踪的采集与应用，都是独立存在并分开建设，随着时间的推移，发现这三者是相互关联，相辅相成的，是云原生 SRE 保障的一把利器。

图5.1 -微服务调用关系图

2、可观测性架构

玄图-可观测性平台 基于 OpenTelemetry 通用解决方案，结合 IEG 营销服务场景的服务高吞吐以及采集治理等特性要求，平台架构设计如下图 5.2 所示。玄图可观测性平台的架构以 OpenTelemetry 为核心，覆盖 Trace/Metric/Log 数据采集、传输、处理和应用全流程。

图5.2 -玄图可观测性架构图

玄图可观测性平台特点如下：

OneSDK 统一上报 : 遵循 OpenTelemetry 协议规范，集成指标、追踪、日志能力-OneSDK，解决多节点上报时间误差至微妙级；
灵活的数据治理能力 : 支持多种动态采样策略、数据聚合控制、熔断及降级机制。根据业务的不同体量、精细化程度等要求，灵活配置与下发策略。通过兼容流式线的头部干预、尾部干预的综合治理能力，保障业务运行稳定；
丰富的能力扩展支持 : 为运营场景中复杂业务架构提供 AiOps 异常检测、混沌强弱依赖分析、全链路压测（精准资源评估）等扩展能力；
多语言 SDK 支持 : 目前可支持 Golang、Python、C++、PHP、RUST、JS 多种开发语言；
稳定性架构 : 支持多租户管理与运营，支持主机与 K8S 环境部署，支持百亿 PV 架构，协助运营人员快速发现、定位、分析与解决问题，效率提升 5 倍+；
服务解耦&分级存储 : 引入 Kafka/Pulsar 消息中间件做上下游解耦，极大扩展前后台服务能力，便于集成数据应用，且支持满足不同应用场景的分级存储，支撑高峰上报 QPS300W/S 的运营能力，提供秒级数据处理能力。

3、平台能力扩展

3.1 数据采集治理

微服务链路错综复杂，海量的链路追踪数据对可观测性平台服务的运营能力更是不小的挑战，完备的数据采集治理能力必不可少。玄图可观测性平台为运维和开发人员提供了丰富的采样治理能力和运营治理能力，如图 5.3 所示，玄图可观测平台支持多种动态采样策略、数据聚合控制、熔断及降级机制等采集运营策略。满足不同业务体量和精细化程度运营要求，支持灵活配置与下发策略，且通过兼容流式线的头部干预、尾部干预的综合治理能力，为业务稳定运行保驾护航。

图5.3 -数据采集治理技术架构

3.2 链路数据检索

玄图可观测性平台为用户提供链路追踪数据采集、传输、处理和应用全流程服务。其中通过链路数据检索和可视化功能可清晰明了地看到同一调用链下服务内部和服务间调用链路及其相应调用状态、调用时延等指标，可帮助用户快速定位链路异常点和分析服务性能瓶颈点。同时平台也提供了丰富的查询条件来帮助业务快速检索到所需链路数据，方便易用。

图5.4 - 服务链路追踪检索

3.3 链路调用拓扑

微服务链路错综复杂，玄图可观测平台提供了服务间调用拓扑关系图，帮助业务快速了解其业务场景下服务间上下游调用关系，从全局的视野观察和保障服务运营。玄图还利用该链路拓扑能力结合混沌工程、全链路压测，扩展更多业务服务能力（下面会有详细叙述）。

图5.5 -服务链路拓扑图

3.4 数据上报统计

对上报的链路数据，平台同时提供了多维度的统计能力，包括租户和服务维度下的错误率、P50/P95/P99 延迟、调用次数等指标。通过该分析数据，业务可轻松地观测到某个时间段内耗时最高、成功率最差、调用次数最多的服务表现，从而帮助运营任务分析问题；同时这些统计数据也对接了外部监控组件，可按照业务自定义规则进行告警，帮助业务第一时间发现问题。

图5.6 - 服务数据上报统计

4、平台能力扩展

4.1 全链路的异常检测

就异常检测而言，基于领域的传统 IT 管理解决方案往往只能在单一或数个维度根据人工规则进行判断，无法充分利用多种数据间的潜在关联性，也很难考虑到一些特殊情况，因而无法智能化地提供可靠、高可用的洞察和预测性分析。以玄图可观测性平台为基础的 AIOps 的研究旨在使用智能化的分析手段对 Trace/Metric/Log 数据进行分析，辅助传统规则方法，以更加精准识别服务的异常点，减少误告。

图5.7 - 服务异常检测方案架构图

玄图 AIOps 实践思路如上图 5.7 所示，获取最新一段时间的 Trace/Metrics 数据，通过训练好的模型推算异常权重，识别出异常的 Trace 数据。其中模型特征较为关键，我们通过测试阶段和上线阶段两个阶段不断完善，其中测试阶段我们结合压测平台和混沌实验，模拟故障，自动标注异常特征，并于上线阶段，采集现网真实的 Trace 异常点结合任何判断不断更新特征库。以下是平台上的 AIops 能力展示：

图5.8 -异常检测效果图1

4.2 调用强弱依赖分析

玄图可观测性链路追踪结合混沌平台，可以快速分析出服务间强弱依赖关系。玄图可观测性调用跟踪系统追踪记录了服务间的调用关系，使用混沌工程给被调服务注入故障，观察主调服务的业务指标，可以得出服务间的强弱依赖关系。业务方可以进一步结合具体业务场景进行依赖治理，优化关键路径，实现低耦合架构。比如某游戏任务系统这个例子，获取任务配置服务超时致入口超时，进而导致玩家请求失败，未能降级从本地获取配置，控制面的配置服务故障影响到了数据面，显然是不合理的。非核心服务出现了问题不能将问题一直传递下去导致服务整体不可用。

图5.9 - 强弱依赖分析案例

六、混沌实验平台

1、混沌工程概述

在我们将应用以云原生的方式上云之后，受益于云原生的 devops、K8S、微服务、服务网格等技术红利，应用的上线下线、发布变更、容量管理、服务治理等运营效率获得了极大提升。海量的并发请求、敏捷的运营诉求驱动着应用从单体服务向微服务、分布式系统演进。运营效率提升的同时也带来了新的挑战，主要表现为以下几点：

分布式系统日益庞大，很难评估单个故障对整个系统的影响；
服务间的依赖错综复杂，单个服务不可用可能拖垮整个服务；
请求链路长，全链路监控告警、日志记录等不完善，定位问题难；
业务、技术迭代速度快，频繁发布变更，使得系统的稳定性受到更大的挑战。

在复杂的分布式系统中，无法阻止故障的发生，而且发生时间可能是周末、半夜、团建时等。我们应该致力于在这些异常故障被触发之前，尽可能多地识别风险。然后，针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。混沌工程正是这样一套通过在分布式系统上进行实验，主动找出系统中的脆弱环节的方法学。混沌工程则是通过模拟现网真实故障来验证服务的“韧性”，找出系统的弱点，同时验证我们的监控告警的有效性，在 MTBF 阶段实施最好不过，是我们 SRE 保障的第二把利器。

图6.1 - 混沌工程的必要性（图片来源网络）

2、平台技术架构

玄图体系致力于打造完整的云原生运维能力，其中混沌工程作为质量管理工具，通过故障注入的方式帮助系统寻找薄弱点，提高系统的稳定性，构建具备韧性的应用。玄图混沌实验平台主要基于开源技术框架，并且在原框架基础上引入了开源组件 ChaosMesh 和 ChaosBlade。玄图混沌实验平台架构如下图 6.2 所示，在平台设计层面，我们按照计划-编排-执行-观察-记录-还原的思路，设计了演练计划、演练编排、演练管理、演练报表和演练报告等模块。基于这些模块，在平台上可以实施自动化日常演练、红蓝攻防演练、突袭演练等丰富的能力，且打通了蓝鲸、奇点、北极星等内部系统，业务开箱即用。

图6.2 - 玄图混沌工程实验平台架构图

具体平台能力体系如下：

故障注入场景丰富，玄图混沌工程实验平台提供 27 种故障原子，覆盖主机和 K8S 环境，并且支持自定义扩展；
灵活的实验编排能力，平台提供灵活的实验编排能力，相对于手工脚本编排实验，通过平台执行故障演练效率提升 10 倍；
实验观测&实验报告闭环，玄图混沌工程实验平台打通了监控系统，实验过程中可实时观测实验效果，实验结束输出实验报告；
红蓝对抗常态化，平台支持对抗演练记录、归档，便于回溯、沉淀，增强趣味性和参与积极性；
可扩展架构，平台基于可扩展架构设计，支持自定义故障原子，可灵活应对复杂实验需求；
通用性方面，玄图混沌实验平台将公司内部的蓝鲸、奇点、北极星、网管系统等系统进行集成打通，实现所有业务都能开箱即用，无需额外的开发接入改造成本，实现了一站式服务。下面分别具体介绍下玄图混沌实验平台具体能力体系。

3、平台能力扩展

1）故障演练提效

传统的手工故障演练一般是根据需求临时开发工具，工具开发完之后还需测试验证，功能大同小异，浪费了很多重复工作，临时开发的工具，效果还不能保证。玄图混沌平台的故障原子是经过大量的实践反复验证的，效果稳定可靠，拿起来就能直接用，没有开发成本。故障的原子非常丰富，可以模拟出机器、网络、操作系统、应用层异常等各种故障场景。平台还提供了灵活的实验编排能力，可以一次性把多个不同的故障编排之后自动执行。实验执行之后都需要观察效果，手工故障演练需要借助于其他工具或者第三方平台看效果，而玄图混沌平台打通了基础指标数据以及支持业务自定义指标，在实验过程中可以直接查看到实验效果。另外，临时演练是一次性的，没有记录和保留现场，没法回溯，玄图实验平台详细记录了每次实验内容，随时都可以查询以及复现。总结起来，玄图混沌工程故障演练平台，提供实验编排、执行、观察、记录一站式服务，将故障演练的耗时从小时级缩短到分钟级，相对于手工故障演练效率提高了 10 倍以上。

图6.3 - 精简流程，提升效率

2）故障注入原子

玄图混沌平台能够模拟的故障非常丰富，通过故障原子组合可以模拟出云服务异常，机器故障，操作系统故障，网络故障，应用层故障，以及根据特定场景定制的故障等。很好的解决了传统故障演练工具开发耗时久，工作重复，效果没发精准控制，工具没法复用等痛点。比如光纤中断生产环境很难复现，但通过混沌工程网络丢包实验可以轻松模拟。目前平台已经支持的故障注入能力如下：

表6.1 - 玄图混沌工程实验平台支持原子

3）实验编排能力

在实际场景中，我们一般需要同时模拟多个故障，也就是需要把多个故障编排在一起并行或者串行执行，玄图混沌平台支持拖拉拽完成复杂故障场景编排，可以同时模拟多个服务，多种类型故障，实现了分钟级复杂故障事件演练。

图6.4-实验编排

4）实验观测报告

混沌实验平台提供了实验编排、执行、观测、报告输出等一站式实验能力，比如我们需要验证一台机机器挂了对服务到底有何影响。可以在平台上发起一个丢包 100%的实验，理想情况下，1 分钟内能自动隔离异常机器，请求成功率会出现短暂下跌，1 分钟后能自动恢复。业务 QPS、耗时、成功率都能保持稳定。实验执行之后可以通过平台的报表实时观测效果，这里的例子我们发现响应延迟明显上升，QPS 明显下跌，并且持续 5 分钟以上都没有恢复，不符合预期。实验结束之后在平台可以直接记录实验结论：系统不能自动隔离剔除后端异常实例，需要优化改造。实验过程、数据得以很好的保存记录。

图6.5 - 实验报告

5）红蓝对抗常态化

玄图混沌平台还支持发起红蓝对抗，左右互搏通常很枯燥。通过红蓝对抗的方式，增加了故障演练的趣味性和游戏性。玄图混沌平台通过流程工具打通红蓝对抗的全流程，记录每一次演练的详情，很好的解决了传统的红蓝对抗，沟通成本高，缺少工具支持，流程不规范，反馈不及时，经验无沉淀的痛点。通过常态化的红蓝对抗故障演练培养了业务开发人员的风险意识，从软件设计之初就考虑到可能会遇到的各种故障，提前从架构设计层面规避，有效提升服务的容错能力。

图6.6 - 红蓝对抗流程图

6）可扩展架构

故障演练的需求随着技术和业务的发展会不断的变化，为了应对这种变化，我们从设计之初就采用了可扩展架构，实验原子之间解耦，某个原子的增删改不影响其他原子，遇到新的实验需求，可以任意横向增加原子，从软件架构上实现了对需求变化的灵活应对。

图6.7 - 可扩展框架

七、全链路压测+ 平台

1、全链路压测概述

游戏营销服务旨在通过精细化运营活动，实现拉新、拉活跃、拉回流等运营事件，使玩家获得更好的游戏体验。在线服务有如下特点：

节奏快，比如开黑节，战斗之夜，周年庆，活动仅持续数日；
数量多，每天都会有大量活动上线，而且活动种类繁多；
访问量大，游戏运营活动高峰时段日 PV 超过百亿；
访问量无法精准预估，很难精准的预测一次活动的访问量，玩家参与度经常超预期；
活动逻辑复杂，上下游依赖多，并且对依赖服务有 N 倍放大，容量评估工作量大。

正是由于营销活动这些特点，在日常运营中，我们几乎每天都要面临类似“双 11”的考验，经常面临如下难题：

活动上线节奏快，开发周期短，遇到性能问题需要快速定位解决；
微服务间调用关系复杂，性能问题排查困难，费时费力，难以快速诊断出瓶颈点；
调用拓扑链路不透明，需要耗费大量人力梳理调用关系和放大倍数；
已经在线上运行的服务容量评估主要依据经验，重要活动通过大量堆机器支撑。

为了解决以上难题，我们启动了全链路压测+平台建设，通过在生产环境对业务大流量场景进行高仿真模拟，获取最真实的线上实际承载能力、执行精准的容量规划，目的在于保障系统可用性。

事实上，系统的容量是一只薛定谔的猫，只有打开箱子才知道猫是什么情况，只有通过全链路压测才能准确掌握系统的极限值。如图 7.1 所示，QPS 到 1 万的时候，资源负载是 20%，根据经验预估 QPS 到 3 万负载到 60%，容量是充足的，流量涨 2 倍没问题。事实上影响服务性能的因素有很多，长连接、短链接、请求串、返回串的大小都会影响到服务性能，真正的两倍流量过来，服务已经过载了，经验往往是靠不住的。

图7.1 - QPS与资源负载曲线

只有通过生产环境全链路执行压测，真实模拟用户行为场景，实时监控系统表现，提前识别和快速定位系统的中的不确定因素，并对不确定因素进行处理，优化系统资源配比，使用最低资源成本，使系统从容面对各种极端场景，达到预期的系统性能目标。通过这种方法，在生产环境上落地常态化稳定压测体系，实现业务系统的长期性能稳定治理。因此平台放在 MTBF 阶段实施，是我们 SRE 保障的第三把利器。

2、全链路压测架构

传统压测工具的定位仅仅是制造压力，对目标服务发起请求，被压服务对其而言是个黑盒子，当压测发现问题后需要被压服务侧自行分析定位原因，压测工具能够发挥的作用有限，并且可替代性很强，市面上有非常多的压测工具可供选择。

全链路压测+平台具备传统压测工具的发压能力，压力引擎当前采用的是开源社区的 locust+boomer 方案，经过调优，单核发压能力能达到 2w/s，同时基于 TKE 云原生架构，压力源做到了弹性伸缩，可以根据负载自动扩容，理论上并发数可以做到无限扩展。同时，压力引擎可以根据需要灵活的集成使用其他优秀引擎。

图7.2 - 全链路压测+ 平台架构图

全链路压测+平台的重点在于对被压服务进行剖析，基于 SRE 工具链中的可观测性平台，拿到了服务调用关系链，通过 TraceID 可以将一次请求经过的全链路服务串联起来，基于此可以计算出服务间的调用拓扑图，在发起压测的同时自动生成全链路调用拓扑关系。并且统计出每一层调用的黄金监控指标，如 QPS、耗时、成功率等，可以一目了然的看到微服务间的放大倍数。在压测过程中能实时观测到全链路每个环节的指标，当压测出现瓶颈时，如入口延迟增大，从链路统计视图能快速定位到导致入口延迟增大的具体微服务，再进一步通过 trace 详情下钻分析，能够定位到具体的方法。

总体而言，全链路压测平台不仅提供了传统压测基础功能，如数据构造、请求拨测、压测监控、压测编排、发起压力等。同时提供了压测分析增值功能，如链路拓扑计算、链路统计、性能瓶颈定位、压测流量染色、根因下钻分析等。

3.平台能力介绍

3.1 灵活的压测编排

平台支持灵活的发压模式，包括：

固定压力模式：并发数固定，可以设置最大 QPS
阶梯压力模式：并发数持续增加，可以设置最大并发数和最大 QPS
快速压测模式：并发数持续增加，达到指定错误率或耗时阈值后压测自动停止

图7.3 - 压测编排

3.2 云原生架构

全链路压测+平台的压力源由平台托管，用户无需关注压力源。压力源基于 TKE 容器化部署，资源可以根据需要灵活扩展，理论上可以做到无限扩展。同时，平台将压力源的负载指标主动暴露出来，可以通过压测报告实时查看压力源负载数据。

图7.4 - 压力源负载指标

3.3 丰富的压测指标

全链路压测+平台的压测工具作为请求客户端，会实时上报压测指标，在压测过程中通过压测报告能实时观测到相关的监控指标，包括 QPS、耗时、成功率等，同时能够查看压测客户端的请求返回日志。

图7.5 - 压测指标监控

3.4 全链路拓扑图

基于可观测性技术，全链路压测平台能捕获微服务间调用拓扑关系，在压测过程中，根据实际请求调用链实时生成服务间调用拓扑图，并且统计出每一层调用的黄金监控指标，如 QPS、耗时、成功率等，通过拓扑图可以一目了然的看到微服务间的放大倍数。其中对于第三方服务（如 DB）在没有上报 trace 的情况下也能通过自动补链技术计算出统计指标。

图7.6 - 全链路拓扑图

3.5 全链路统计

基于可观测性技术，全链路压测平台能计算出链路拓扑图中每一层调用的黄金指标（QPS、耗时、成功率等），并通过时序报表实时展示。当压测出现瓶颈后（失败率或耗时明显增加），通过报表能够快速定位到导致系统出现瓶颈的微服务，再进一步通过 trace 详情下钻分析，能够定位到具体的方法，极大提升了性能问题定位效率。

图7.7 - 全链路指标统计

3.6 其它

除此之外，全链路压测+平台还提供压测流量染色（特定 Header 头）以及压测标记全链路透传功能，被压服务适配后能够实现压测流量隔离，将压测流量导流到影子库表。实现了在不污染生产环境业务数据情况下进行全链路性能测试，能在生产环境对写类型接口进行直接的性能测试，实现在生产环境可控压力测试。当前我们也正在探索无侵入的流量隔离方案，敬请期待。

八、思考与未来规划

SRE 体系的建设任重道远，完全复制 Google SRE 方法显然是行不通，个人认为原因有三个方面，第一点是以 Google SRE 岗位能力要求进行人才招聘，在国内存在一定难度；第二点是 SRE 文化在国内企业的认知与普及都不太够；第三点受限于基础设施即代码、体系化的 SRE 工具链、服务标准及抽象等能力成熟度。另外，我们也面临着诸多挑战，包括互联网行业日新月异的业务形态、新技术的不断发展，业务的复杂度势必会日益增大，但业务对稳定性诉求是不变的。同时，云原生环境存在着大量的三方 PaaS 连接与集成，稳定性保障也存在失控的风险。站在 SRE 的角度，任何一个细微环节的缺失与不足，都有可能影响 SLO 达标率。

为应对这些挑战，我们会将整个 SRE 稳定性全景拼图逐步进行拼凑，所以注定是一个长期持续建设的过程。下阶段我们会重点深度整合“三件套”能力，验证其真正发挥的效能。部分能力也会积极贡献给社区。相信不久，我们会陆续推出 SRE“四件套、五件套...”,大家拭目以待。

— 本文结束 —

● 漫谈设计模式在 Spring 框架中的良好实践

● 颠覆微服务认知：深入思考微服务的七个主流观点

● 人人都是 API 设计者

● 一文讲透微服务下如何保证事务的一致性

● 要黑盒测试微服务内部服务间调用，我该如何实现？

关注我，回复「加群」加入各种主题讨论群。

对「服务端思维」有期待，请在文末点个在看

喜欢这篇文章，欢迎转发、分享朋友圈

在看点这里