[翻譯]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。

應用容器崩潰

若要模擬的應用崩潰（進程退出），任何容器都將在一段時間內重新啟動此系統。值得注意的是，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 服務注冊，以確保服務獲得流量負載。預計數據處理會有些緩慢，但在洪峰結束后恢復。