云原生SRE实践

云原生SRE实践

云原生

被广泛沿用至今的云原生概念是由 Pivotal 公司的 Matt Stine 在 2013 年首次提出的：云原生(Cloud Native) 代表的是一种构建和运行应用程序的技术和方法论，其中云(Cloud)表示的是应用运行在云基础设施之上；原生(Native)则强调的是应用从设计之初就是基于云基础设施能力的，借助云的优势实现更加高效强大的技术架构。

​2017年，Matt Stine 又将云原生特征重新归纳为六大点，分别是：

• 模块化 Modularity
• 可观测性 Observability
• 可部署性 Deployability
• 可测试性 Testability
• 可处理性 Disposability
• 可替换性 Replaceability

构建SRE体系

玄图-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准则

1.架构设计准则 - 我们认为所有的架构都是不完美的，都存在缺陷，因此我们在做业务架构设计时都必须要考虑服务稳定性保障，如负载均衡、多点容灾、集群化服务、数据多活等能力；

2.SRE 前置准则 - 在业务立项之初，SRE 角色需要提前介入，将运营阶段可能出现的问题或风险提前在架构设计、编码阶段暴露，提前准备好解决方案，甚至规避问题与风险；

3.混沌实验准则 - 故障不可避免，为何不让其在测试或预发布环境提前到来，通过模拟现网真实故障来验证服务的“韧性”，找出系统的弱点，同时验证我们的监控告警的有效性，在 MTBF 阶段实施最好不过，也是我们其中一把利器；

4.可观测性准则 - 通过采集业务指标、日志、追踪等数据，快速分析与定位问题，同时发现复杂系统的瓶颈点，在很长一段时间内，业务指标、日志、追踪的采集与应用，都是独立存在并分开建设，随着时间的推移，发现这三者是相互关联，相辅相成的，是我们的第二把利器；

5.全链路压测准则 - 通过与可观测性、混沌实验能力的深度整合，实现模拟真实业务环境全链路压测，达到业务上线前的精准资源评估，主动发现潜在性能、版本缺陷等问题，是我们的第三把利器；

6.DevOps 交付准则 - 通过打造高效的价值交付链，覆盖 CI、CD、CO 服务全生命周期运营管理，CI 我们采用 ODP 封装蓝盾方案，CD 与 CO 采用运维编排及监控告警等能力，SRE 会将大分部精力聚焦在 CO 环节；

7.故障应急准则 - 故障不可避免，我们能做的是不断去提升 MTBF，降低 MTTR，包括事前的实施大量混沌实验、故障预案；事中采用打造的工具链，快速发现、分析、定位与解决问题；事后组织总结复盘，沉淀案例经验；

8.SRE 学习准则 - 营造学习的文化，目的是实现多个不同职能团队的有机融合，相互了解大家面临的问题或挑战，形成一致的目标，达到有效的协同，解决业务的问题。

工具链建设

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 实践
云原生大厦的基石之一「云原生可观测性」