Dapr 长程测试和混沌测试( 二 )


应用容器崩溃若要模拟的应用崩溃(进程退出) , 任何容器都将在一段时间内重新启动此系统 。值得注意的是,Dapr的Sidecar 预计将继续运行 。预计容器将正常重新启动,Dapr的Sidecar将在没有手动干预的情况下恢复与应用程序的通信 。
Pod 崩溃要模拟给定 POD 不正常的情况 , 系统中的服务 POD 将在一段时间内重新启动 。这是部分故障,这意味着在 Kubernetes 恢复新 POD 时,服务应继续运行 。预计 Kubernetes 会将服务再次恢复到正常状态,而来自其他服务的 Dapr sidecar 将能够与恢复的服务中的所有 POD 进行通信 。
服务崩溃此故障通过重新启动服务的所有 POD 来模拟服务的完全中断 。这将导致验证工作程序可能会识别完全中断 。预计 Kubernetes 会将服务再次恢复到正常状态,而来自其他服务的 Dapr sidecar 将能够与恢复的服务中的所有 POD 进行通信 。
状态存储中断状态存储可能由于任何原因而关闭 。为了模拟这一点,Redis 的所有 POD 都将每隔一段时间重新启动一次 。
状态存储速度缓慢状态存储的性能可能会因邻居应用的繁忙或其他外部因素而降低 。这是通过在内部以 X tps 对 Redis 执行 Y 秒的写入操作来模拟的 。预计数据处理会有些缓慢,但在突发结束后恢复 。
主题中断主题可能因任何原因而关闭 。这将通过每隔一段时间重新启动 Kafka 的所有 POD 来模拟 。
主题缓慢由于并置了另一个主题并接收到流量峰值,因此主题的吞吐量可能会降低 。缓慢也可能是由其他外部因素引起的 。为了模拟这一点,创建了一个随机主题ios,副本设置为3(保证所有节点都有数据的副本),并且流量以X tps保持,持续时间为Y秒,间隔一次 。预计数据处理会有些缓慢 , 但在突发结束后恢复 。
Dapr 的sidecar 注入器奔溃使用以下步骤模拟此故障后,数据处理应继续,并且所有 POD 都应具有 Dapr sidecar 。

  • 将服务从 3 扩展到 0 。
  • 等待服务为 0 。
  • 重新启动达普尔的边车喷油器 。
  • 将服务从 0 扩展到 3 。
Dapr的placement服务崩溃这是通过每隔一段时间重新启动placement服务来模拟的 。
Dapr的Sentry服务崩溃这是通过每隔一段时间重新启动sentry服务来模拟的 。
Actor 实例化 洪峰某些应用程序可能会在很短的时间内创建许多Actor 。这种突发将通过创建随机类型的actor并以X tps的固定速率激活它来模拟,以达到一定间隔的持续 D 。频繁的Actor类型必须与应用中使用的actor 类型不同,但也应由 Hashtag Actor 服务注册,以确保服务获得流量负载 。预计数据处理会有些缓慢,但在洪峰结束后恢复 。
失败配置失败守护程序将配置为每隔一小时执行以下模式 (即 , 活动 1 小时 , 空闲 1 小时) 。
  • Feed 流生成器的容器每 2 分钟崩溃一次 。
  • 消息分析器的容器每 3 分钟崩溃一次 。
  • Hashtag计数器的容器每 4 分钟崩溃一次 。
  • Hashtag Actor 服务的容器每 5 分钟崩溃一次 。
  • Hashtag计数器的POD每9分钟崩溃一次 。
  • Hashtag Actor服务的 POD 每 10 分钟崩溃一次 。
  • 消息分析器的服务每 7 分钟崩溃一次 。
  • 状态存储每 25 分钟中断一次 。
  • 状态存储速度为每 29 分钟 1 分钟(tps 将在实现期间定义) 。
  • 每 21 分钟中断一次主题 。
  • 每 23 分钟有 1 分钟的主题缓慢 。
  • Dapr的Sidecar 注入器与Hashtag 快照服务每13分钟崩溃一次 。
  • Dapr的placement每5分钟崩溃一次 。
  • Dapr的sentry服务每7分钟就会崩溃一次 。
  • Actor 的实例化每 10 分钟突发 1 分钟(tps 将在实现期间定义) 。
如果上述所有故障在现实世界中都不能一起证明是可行的 , 那么 Failure Daemon 可以随机选择上述故障配置的子集(例如 5),并仅在给定运行中执行这些配置 。
测试验证测试验证通过 Azure 监视器中触发 sev3 的监视器上的警报进行 。将配置以下监视器,并应始终保持正常:
数据处理对于两个连续的数据点,验证工作人员的更改比率指标永远不应为零 。此指标由验证工作程序发出 。
消息分析器延迟消息分析器必须发布自消息创建以来延迟的指标 。任何消息都不应早于 2 分钟 。此指标由消息分析器发出 。
Hashtag计数器延迟Hashtag计数器必须发布自消息创建以来延迟的指标 。任何消息都不应早于 4 分钟 。此指标由 Hashtag计数器发出 。
过时快照即使 Hashtag 快照服务正在运行,最后一个快照也可能太旧 。Hashtag 快照服务应在自上次成功运行以来延迟时发布指标 。延迟不应超过 5 分钟 。此指标可由 Hashtag 快照服务发出 。

推荐阅读