Dapr 长程测试和混沌测试 _生活百科

介绍这是Dapr的特色项目，具体参见： https://github.com/dapr/test-infra/issues/11 ，在全天候运行的应用程序中保持Dapr可靠性至关重要。在部署真正的应用程序之前，可以通过在受控的混沌环境中构建，部署和操作此类应用程序来实现这种信心。
测试应用程序所测试应用程序将模拟在社交网络中发布的消息，以便通过情绪分析进行评分。不采用外部依赖来更好地控制环境。可以删除某些组件，并实现相同的结果。另一方面，这个测试设计是有意地执行Dapr的所有构建块。此应用程序中的所有组件使用相同的存储库和相同的编程语言实现，以便快速开发。由于此应用程序也使用 Actor 功能，因此可以用 .Net 或 Java 编写。鉴于当前的项目维护者更熟悉 C#，因此使用带有 C# 的 .Net SDK来实现这个项目。存储库应与现有存储库分开。建议创建一个名为“长程测试”的新存储库。

文章插图
Feed 流发生器生**工社交网络消息帖子，例如：“Dapr很棒。#DaprRocks #Kubernetes“ 。将在预定义的模板中自动生成这些消息“ is . <Hashtag 1> <Hashtag 2>” 名词和形容词的列表是预定义的，并且是随机选择的。与主题标签列表相同。该消息使用 UUID 生成器获取随机生成的消息 Id 和相关 Id，并使用 Dapr 的 PubSub API 以下列格式发布：
{"correlationId": "<UUID>","messageId": "<UUID>","message": "<message>","creationDate": "<creationDate>"}消息分析器该组件通过Dapr 的PubSub功能订阅主题，查找形容词与情绪类型（正面，中性，负面）的映射，并使用识别的类型（或未知，如果找不到）并将该内容附加到消息中。最后，通过 Dapr 的输出绑定API 发布新的标记有效负载。标记的有效负载采用以下格式：
{"correlationId": "<UUID>","messageId": "<UUID>","message": "<message>","sentiment": "<sentiment type>","creationDate": "<creationDate>"}Hashtag 计数器此组件将通过 Dapr 的输入绑定调用接收消息。从邮件中提取主题标签。对于每个hashtag标识的# 标签，它都会进行一个Actor方法调用：标识为“HashtagActor”的执行组件实例中的方法increment(sentiment) 。
Hashtag Actor 服务此组件对于在 Dapr 中练习“Actor ”功能非常有用。它注册主题HashtagActor 程序类型，其中hashtag是标识符。这个Actor 有一个方法increment(String sentiment), 其目标是保持每个主题标签 - 情绪组合的计数器。在状态键中传递的情绪和状态值是前一个值（如果未找到，则为零），增量为 1 。
Hashtag 快照服务此组件将执行 Dapr 的状态 API（而不是在Actor 的上下文中）。它每分钟唤醒一次，并从 Redis 状态存储中检索所有Key - 不使用 Dapr 的状态 API，因为 Dapr 不提供 API 来从另一个 Dapr 应用程序的状态存储中查询一系列状态。预计只有几十个Key，因为此组件中预定义了主题标签列表。现在，为所有状态生成键值对，并通过 Dapr 的状态存储 API 保存。此服务还提供了一个 API，用于通过 GET 方法检索所有密钥。
验证Worker此组件将对应用程序的结果执行运行状况检查。鉴于最终的一致性和人为注入的故障，验证必须是模糊的。Worker应执行以下验证：

每5分钟唤醒一次。
通过在Hashtag 快照服务上调用 API 来获取所有键值对。
Sleep 2分钟。
通过在Hashtag 快照服务上调用 API 来获取所有键值对。
计算已更改的计数器数的比率。
以 JSON 格式向标准输出指标：{ "longhaul-counters-changeratio": "<ratio>"}

仪表板网络应用这是一个简单的网页，它将调用Hashtag 快照服务进行 API，显示所有键值对。这对于手动验证非常有用。（可?。┐俗榧箍梢酝ü?Dapr 的中间件验证 OAuth 功能。
失败守护进程最后但并非最不重要的一点是，在给定固定配置的情况下，此服务将触发故障。本文档稍后将介绍故障类型和特定的故障配置。
平台、日志和指标长程测试应用将使用 AKS 群集进行部署，该群集在 3 个可用区中的每个节点上至少有 1 个节点。由于目标是测试复原能力而不是性能，并且流量是人为生成的，因此便宜的硬件类型应该足够了，例如标准DS2 v2（2个vcpus ， 7 GiB内存）。日志和指标将转发到 Azure 监视器，并且可以通过 JSON 作为结构化数据进行查询。
故障类型为了模拟混乱的环境，将注入一些人为的故障。可以通过将服务从 3 缩小到 0 ，然后从 0 扩展到 3 来实现重新启动。当需要单个 POD（例如，placement服务）时，重新缩放应改为从1/到 1 。