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

仪表板网络应用这是一个简单的网页,它将调用Hashtag 快照服务进行 API ,显示所有键值对 。这对于手动验证非常有用 。(可选)此组件还可以通过 Dapr 的中间件验证 OAuth 功能 。
失败守护进程最后但并非最不重要的一点是,在给定固定配置的情况下,此服务将触发故障 。本文档稍后将介绍故障类型和特定的故障配置 。
平台、日志和指标长程测试应用将使用 AKS 群集进行部署,该群集在 3 个可用区中的每个节点上至少有 1 个节点 。由于目标是测试复原能力而不是性能,并且流量是人为生成的,因此便宜的硬件类型应该足够了,例如标准DS2 v2(2个vcpus,7 GiB内存) 。日志和指标将转发到 Azure 监视器,并且可以通过 JSON 作为结构化数据进行查询 。
故障类型为了模拟混乱的环境,将注入一些人为的故障 。可以通过将服务从 3 缩小到 0,然后从 0 扩展到 3 来实现重新启动 。当需要单个 POD(例如,placement服务)时,重新缩放应改为从1/到 1 。
应用容器崩溃若要模拟的应用崩溃(进程退出),任何容器都将在一段时间内重新启动此系统 。值得注意的是,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 服务注册,以确保服务获得流量负载 。预计数据处理会有些缓慢,但在洪峰结束后恢复 。

经验总结扩展阅读