关于测试:混沌工程推动可观测性的最佳实践-IDCF

本文中，咱们应用 DDD 领域建模的办法，设计了一个正当且简单的微服务叫车零碎，并在该零碎之上，利用 OpenTelemetry 进行了可观测性结构实际，最初采纳“强化混沌工程”的方法论，借助故障注入伎俩，实现了用于验证可观测性价值的最佳实际，并将游戏冲关的玩法融入软件开发的生命周期中，晋升利用的排障能力，以此升高零碎的 MTTR。

一、一个类 Uber 叫车试点利用

为了达到利用可观测性结构的成果，须要设计一个足够简单的试点利用，这里我抉择了这个类 Uber App 的设计和开发。

1.1 领域建模

首先，通过畛域驱动设计 DDD 的事件风暴，集众人之力实现该试点利用的畛域模型设计：

随后察看畛域中反复呈现的名词，找出限界上下文：

这样，类 Uber 叫车试点利用的畛域模型建模结束。

1.2 微服务架构设计

接着，咱们持续设计试点利用微服务化的零碎架构：

类 Uber 叫车试点利用有五个微服务，其中四个是由限界上下文衍生进去的，包含：

• User 乘客
• Match 叫车匹配
• Trip 载客旅程
• Payment 领取金流

另外加开了 broker-service，作为 Websocket 的对立进口。

微服务之间的通信机制，除了最间接的 RESTFul API，即上下游调用关系之外，也应用了 RabbitMQ 作为音讯队列将畛域事件无效播送到各服务去。

到了这边，类 Uber 叫车试点利用的设计也已趋于残缺，接下来就是实现。

1.3 Java Spring Boot 实现

应用 Java Spring Boot，遵循 Clean Architecture，最初花了一个月的工夫将后端残缺开发进去，共计大概 7000 行代码。

本文并不会深刻开展 Clean Architecture 的开发过程，有趣味的敌人可参考：https://github.com/Johnny8508…

二、OpenTelemetry 结构可观测性

2.1 可观测性概念的回顾

平时在开发环境中，遇到 Bug 的时候为求不便，都会开启调试器，借助中断来确认利用的行为是否合乎预期，然而，一旦利用部署到各环境中，便不能再应用调试器来察看利用的行为了。

所谓的可观测性，指的是利用在被部署到某个线上环境后，其自身还能透过“某种机制”来让开发人员，便捷地观测利用自身在线上“各个工夫点”的行为。

其中，Trace 记录着每个性能残缺的执行过程。因为执行过程会充斥着「上下游的调用关系」，联合起来就造成了一棵树。

那么，在技术上到底该如何出现？

手动剖析：

Grafana 出现：

2.2 OpenTelemetry 的新尝试

OpenTelemetry 的创造并非要解决新的问题，而是一个在可观测性三大支柱的需要下，实现繁多规范的框架。

咱们决定要尝试 OpenTelemetry 这一项 CNCF 近期推出的技术框架。

咱们先来看一下在以前，咱们都是如何做到分布式链路追踪的？

OpenTracing + Jaeger

以 OpenTelemetry 的设计观点来看，这种“大同小异”便有了能够施行统一标准的可行性。

在利用代码中，应用 OpenTelemetry SDK 来进行数据采集，下一步 Exporter 会将采集到的数据如：log/trace/metrics，用配置好的格局传递到 Agent 去，Agent 只是作为数据传递的中介，最初会再提供给 Collector。

为了要在利用中做分布式链路追踪，以往咱们都必须间接依赖厂商链路追踪产品的 SDK 来去埋点，但如此一来，将来如果决定要更换厂商时，则利用会有很大一部分须要重写。

OpenTelemetry 表演的就正是那一层形象的标准接口，如果利用依赖的是 OpenTelemetry 的 API，那将来要更换厂商时，就只须要扭转 OpenTelemetry 的配置就行，任何一行代码都不须要重写。

2.3 Java Agent 的主动采集

首先要先到 Github 下载 OpenTelemetry 最新释出的 Java Agent JAR。

https://github.com/open-telem…

接下来只须要将这个 JAR，在 Dockerfile 中将其 COPY 到镜像中，而后在 CMD 中无关 Java 的执行指令中，增加 javaagent 参数，将其指向 JAR 的地位，一并执行就行。

此外，还须要把追踪零碎一并部署起来，例如：Jaeger 或 Grafana Tempo。

根本范例可参考：https://github.com/Johnny8508…

一行代码都不必写，就可能产生出以下的 Trace 了：

以 Java Agent 形式执行的 OpenTelemetry，开发人员不再须要亲自埋点，不须要对链路追踪零碎有任何的认知，更不须要为此写任何一行代码。

OpenTelemetry 会寻找所有被标注上 @RestController 的物件，并在其每个 RESTFul 办法调用之前，被动进行数据采集，帮忙埋下适当的 Trace。

2.4 定制化采集

在体验到主动采集的弱小之后，大家心中浮现的第一个问题必定是如果我要定制化采集的话，要怎么办？

• 第一种办法：由环境变量去设置 include / exclude 的类别或办法。
• 第二种办法：应用 @WithSpan 来减少想要被放进 Trace 的办法。

以类 Uber 试点利用为例，有两个 POJO 物件：StartDriving 和 FindCurrentTrip，也想要被退出到 Trace 之中。

因为这两个物件只是单纯的 POJO，因而在预设的状况并不会被 OpenTelemetry 捕捉，为了将其退出到 Trace 之中，只须要其办法上加上 @WithSpan，就可能失去以下的后果：

咱们借助弱小的 OpenTelemetry in Java，很不便地实现了类 Uber 试点利用的可观测性结构。然而，以 SRE 的观点来看：

始终以来，SRE 都心愿可能最小化可观测性结构实际，以缩小其所带来的额定保护老本。

因而，咱们须要一种新的最佳实际，来证实可观测性结构的价值。

三、推动可观测性的最佳实际

通过了思考与设计，最初我参考了混沌工程的精力，开发出一个办法，能够通知我“目前的可观测性实际是否仍有缺点”？我把这个办法称之为“强化混沌工程”。

3.1 叫车流量的自动化模仿

然而，目前仅有一个类 Uber 的叫车零碎，还须要模仿乘客和司机的行为，来自动化地产生正当的叫车流量。

如上所附的动画所示，在通过数日的开发后，终于做出了一个简略的自动化叫车流量产生零碎。动画中出现的是五个司机和一个乘客的状况模仿。

看似简略的叫车流程，其背地的工作其实是必须由五个微服务以及 RabbitMQ 来合作实现的，当初咱们曾经可能发明大量且正当的叫车流量，总算能够来开始实际“强化混沌工程”了。

3.2 强化混沌工程

从 SRE 的视角上，可观测性结构的价值在于，咱们要花多少工夫才可能觉察并修复好生产零碎发现的问题，即 MTTR。

当初曾经有了“自动化叫车流量生成器”，也有评判可观测性结构的规范 MTTR，那剩下我最缺的就是“故障”了。

微服务等分布式系统在开发和运维上带来更高的门槛和复杂度，因而混沌工程便也开始被一直提倡。讲白一点，混沌工程就是“有目的地看待测系统搞破坏来提前揭发零碎的问题”。

为了揭发零碎的问题，咱们须要先看待测系统定义其稳态。以类 Uber 叫车试点利用来说，稳态便是“可能残缺且顺畅地执行每一个叫车流程”。

借鉴了混沌工程的思维，将其使用到可观测性场景中的话，则是“要有目的地在零碎中搞破坏来提前揭发可观测性结构的缺点”。

对此，因为应用场景较为非凡，是否有现存的第三方工具，可能满足类 Uber 叫车试点利用定制化的混沌场景，我并没有太大的自信，因而我决定本人实作一个可能实现混沌工程的技术架构，以下图所示：

新开了一个服务在图正地方，称之为 Chaos-Server。

而在利用各个服务中都会执行一个 Chaos Client，即 Chaos Agent。

Chaos-Server 和各个 Chaos-Client 相互沟通，传递指令，来实现整个混沌工程的流程。

咱们只须要在 Chaos 的操作页上对 Chaos-Server 下达命令就好。

3.3 冲关游戏的根本玩法

咱们把混沌工程的流程设计成了一款冲关游戏，上面是根本的玩法：

3.4 体验一次真正的冲关游戏

首先到 Grafana 的仪表盘上，能够看到三个根本面板：上方为 Metrics，包含：左上为即时的叫车匹配数量，右上为利用中的谬误数量；而下方则显示即时的 Logs。

开始一个新的关卡 56a8d709-9c22-489e-b44e-6d86f81796b2：

发现叫车流程整个卡住了，看来，Chaos 是真的开始在搞破坏了…。

一段时间之后，便在 Slack 频道上收到了一个谬误告警，通知咱们是时候去排障了。

同时也在面板上发现上方叫车匹配的数量急剧下滑，而下方也开始产生出了谬误日志：

搜寻带“ERROR”的日志，应用 Loki 的查问语法：

点击其中一个谬误日志，并且从日志的 traceID 栏，间接开启右半部 Jaeger 的 trace 页面。

间接从 trace 上察看，能够看到整个微服务的上半部是顺利的，但到下方调用 /api/drivers/{driverId} 这个 API 时产生了谬误。

同时，察看这个 trace 的执行工夫，居然高达了 12 秒！发现瓶颈为 /api/users/{userId} 这个 API。

点击 span 能够看到更多详细信息，而从 DriverController.setDriverStatus 这个办法的 span 中能够看见 exception.message 明火执仗地通知你，它就是 Chaos！

回到操作页面上，把对应到的两个 Chaos 杀掉：

• user.SetDriverStatusAPIBlocked
• user.FindUserDelay

杀掉完两个坏蛋之后，从页面上能够看到接下来只剩下 2 个 Chaos。

从这之后回去看叫车流程，会发现错误仿佛曾经隐没，然而整个叫车流程还是卡到不行。因而接下来必须要来做性能调优了。

这一步，到 Jaeger 这个 data source 下来操作，搜查在 match service 中近期的 traces，并且应用执行工夫来从大到小排序。从搜查后果上来看，会发现一个显著的效力瓶颈，居然有一堆 trace 的总执行工夫都高达六秒！点击左侧的 traceId，来导览到 trace 页面。

留神到 FindAvailableDrivers 有性能瓶颈，执行工夫高达 6 秒，这相对是 Chaos 搞的鬼。到 Chaos 操作页上将其杀掉！

接下来咱们就只剩下最初一个 Chaos 了。此时看叫车流程，性能感觉好了一些，然而整个停顿还是很迟缓，重复使用雷同的手法来排序 traces，但这一次咱们针对 user service。从这一次的搜查后果中，咱们便留神到了有许多的 traces，居然都花了长达 3 秒的工夫。

发现性能瓶颈可能在 UpdateLatestLocation，乘客或司机在旅程行驶中，会一直地调用它来更新本身的座标。如果 Chaos 对这个调用增加了提早，也难怪叫车流程会如此迟缓了。

最初，咱们就不用留情地把最初一个 Chaos 给杀掉。

游戏完结后，回去看叫车流程，会发现整个叫车流程的顺畅度又回来了！

四、结束语

本文中，咱们应用 DDD 领域建模的办法，设计了一个正当且简单的微服务叫车零碎，并在该零碎之上，利用 OpenTelemetry 进行了可观测性结构实际，最初采纳“强化混沌工程”的方法论，借助提前揭发实际瑕疵的故障注入伎俩，实现了用于验证可观测性结构价值的最佳实际形式，以游戏冲关的玩法融入软件开发的生命周期中，晋升咱们对利用的排障能力，以此升高可观测性结构的 MTTR。

起源：混沌工程实际

作者：水球潘 /JohnnyPan

申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。

IDCF 社区共创读书会 首期汇报，每周四晚 8 点， 冬哥有话说 收费直播，关注公众号回复“共读”获取直播地址

• 8 月 19 日，共读《思考，快与慢》
• 8 月 26 日，共读《DevOps 实际指南》
• 9 月 2 日，共读《麻利无敌之 DevOps 时代》