分布式负载测试实践

这篇偏技术，非技术的朋友可以选择不看 LOL。

上篇文章介绍了 Raft 共识算法，会去了解这些分布式的内容是因为工作上的需要。每个月代码总结也停了好久，用这篇文章完整总结一下前一段时间做的小工具：分布式定时负载测试，主要目的有一下几点：

  1. 测试内部开发 API 在不同请求发送速度和不同数量请求下的延迟，找出延迟过高的让开发程序员去优化。
  2. 不断增加请求的数量模拟增长的用户量，找出系统能处理请求数量的瓶颈。
  3. 监控系统在不同数量的请求下需要多少的资源：CPU, Memory等。

这个工具主要包括三部分：1. 负载测试，2. 定时器，3. 共识集群

负载测试

负载测试由两部分组成：1. 负载生成器，2. 负载发送器。这个部分的作用是将 JSON 格式的配置生成负载，然后按每秒请求数量、总共请求数量或者请求时常、通过多少个 HTTP 连接给内部系统的 API 发送负载，收集所有回复，算出每个 API 的延迟数据后，生成报告。更进一步，是可以发送按每秒请求数量，发送递增的请求数量，生成在递增请求数量的情况下，整个系统以及每个 API 在的延迟的报告。

负载生成器

这一部分最主要是要收集内部全部的 API，然后针对 API 去生成相对应 HTTP 请求需要的数据。不同公司的 API 文档不同，所以生成的方式不太一样。我们用的是 Spring，所以通过 Swagger 可以知道系统 API 的配置，用代码整合处理一下，就能生成对应的 HTTP 请求。

负载发送器

这一部分的实现主要通过稍微复杂一些。因为要可以模拟同一时间多请求同时访问，所以主要是通过 Golang 的 goroutine 来实现的。这部分的实现参考了 Vegeta，报告的生成则是用了 Gonum Plot，有兴趣的可以进一步看看。

定时器

定时器的作用是定时做负载测试，这个也没什么好说的，网上有挺多实现好了的。借鉴了 Cron

共识集群

因为负载测试通常会在下半夜时通过定时器自动运行，共识集群的作用是保证负载测试在运行过程中，如果一个节点出了问题，可以自动在别的节点上面继续运行。共识算法的实现，用的是上篇介绍的 Raft。

Raft

Raft 的底层不是自己完全实现的，用了 hashicorp/raft，不过在写了大半后才发现这个 lib 不是很完整，要自己补充一些内容，含泪一路走到黑，所以还是比较推荐 etcd 开源的 raft 。

Storage

本地的储存方面用了也是 hashicorp 的 raft-boltdb，一个很简单的 key-value 储存。但是在实际应用中需要储存比较复杂的数据结构，或者好几层嵌套的 map，所以在这个的基础上，做了个试用所有格式的、可以嵌套的储存方式。

Scheduler

也就是上面提到的定时器。客户端通过 HTTP request 控制定时器的启动，停止和删除。

假设共识集群有三个节点，这些部分是怎么一起运行的？举个新建定时器的例子，客户端给 Leader 节点发送 HTTP request 新建一个定时器，每小时做一次负载测试，这个定时器本身的数据会被储存在本地，然后通过 Raft 同步到另外两个节点上，如果在定时器运行的过程中，Leader 节点出故障了，另外一个节点会被选为 Leader ，重新启动定时器，执行定时器的任务。客户端直接给非 Leader 的节点发 POST 请求，收到将是 redirect 到 Leader 的信息，如果是 GET 请求，非 Leader 节点可以直接返回值。

整体架构

乍一看有点复杂，一部分一部分来。

最左边的 load attacker docker 是将上面提到的负载测试 docker 化，这样就能从共识集群指定任意一台空闲的机器来执行负载测试的任务。

中间大的六边形 k8s 代表部署在 Kubernetes 的部分，三个 Pod 圆圈代表的是共识集群，用到 Kubernetes 是因为在一个节点 (Pod) 挂掉后，可以在 Kubernetes 里配置自动再添加一个节点，保持整个集群中有三个正常运作的节点。

整个运行流程从 A.1 的客户端请求开始：

A.1: 客户端发了个新建定时负载测试的任务，通过 Kubernetes 的 nginx 导到 service，再通过 service 上有的 label selector 定向将客户端的请求转给共识集群的 Leader（Leader Pod 和 Follower Pod 有不一样的 Label），Leader 创建了新的定时器，同步到其他两个节点。
A.2: 在定时器时间到了之后，Leader 把负载测试的任务发送到指定的机器上执行任务。
A.3: 在这台机器执行完任务后，再把结果 push 到 Kubernetes。
A.4: Leader 收到结果后生成报告，并把报告上传到 AWS S3。

另外还有一部分 etcd 和 etcd trigger 没有提到，「通过 service 上有的 label selector 定向将客户端的请求转给共识集群的 Leader」，所以如果 Leader 挂掉了，要重新给 Kubernetes 的 Pods 加 label。实现的方式是：

B.1: etcd trigger 是一个很小的监听器，只要 etcd 上 Leader 的值发生了变化，就触发 B.3。
B.2: 共识集群 Leader 挂掉了，重新选主，新 Leader 选出来后，地址更新到 etcd 上。
B.3: etcd trigger 检测到了变化，更新 Kubernetes 里三个 Pod 的 label，特别的将 Leader 标记出来。

通过这么一个架构，可以实现分布式负载测试。

总结

好像是做了不少事情，但是效率还是不够高。而这些大方向上要做什么，大概要怎么做，本来都是一窍不通，还是要靠老板带路。

愿世界充满和平，充满爱。

Github 项目一览：

技术分布式共识算法