遵循傳奇模式的微服務中的非自願中斷/ SIGKILL 處理

Question

我應該設計我的微服務來處理硬件故障等非自願中斷嗎？ 這些中斷是否頻繁到足以在 AWS 托管 EKS 集群上運行的服務中處理。
我是否應該考慮在服務中進行一些設計更改以使用諸如在每個步驟中持久化數據之類的方法來處理意外的 SIGKILL，還是將其視為過度工程？

如果是，您會建議什么標准方法來處理這些非自願中斷
a) 一個安靜的服務，通常在 1 秒內響應（遵循 saga 模式）。 b) 在 1 小時內處理 1GB 大文件的服務。

Answer 1

有幾種方法可以處理這些中斷。 如此處所述：

以下是一些減輕非自願干擾的方法：

• 確保您的 pod 請求它需要的資源。
• 如果您需要更高的可用性，請復制您的應用程序。 （了解如何運行復制的無狀態和有狀態應用程序。）
• 為了在運行復制的應用程序時獲得更高的可用性，請將應用程序分布在機架之間（使用反關聯）或跨區域（如果使用多區域集群）。

自願中斷的頻率各不相同。

所以：

• 如果您的預算允許，將您的應用程序分布在各個區域或機架上，您可以使用節點親和性在 cetrain 節點上安排 Pod，
• 確保配置副本，它將確保當一個 Pod 收到SIGKILL時，負載會自動定向到另一個 Pod。 您可以在此處閱讀有關此內容的更多信息。
• 考慮使用DaemonSets ，它確保每個節點運行一個 Pod 的副本。
• 對無狀態應用使用部署，對有狀態應用使用StatefulSet 。
• 您可以做的最后一件事是編寫您的應用程序以容忍干擾。

我希望我為您清理了一點水，請隨時提出更多問題。