0

我应该设计我的微服务来处理硬件故障等非自愿中断吗？这些中断是否频繁到足以在 AWS 托管 EKS 集群上运行的服务中处理。
我是否应该考虑在服务中进行一些设计更改以使用诸如在每个步骤中持久化数据之类的方法来处理意外的 SIGKILL，还是将其视为过度工程？

如果是
a) 通常在 1 秒内响应的安静服务（遵循 saga 模式），您会建议使用什么标准方法来处理这些非自愿中断。b) 在 1 小时内处理 1GB 大文件的服务。

4

1 回答 1

0

有几种方法可以处理这些中断。如此处所述：

以下是一些减轻非自愿干扰的方法：

  • 确保您的 pod 请求它需要的资源。
  • 如果您需要更高的可用性，请复制您的应用程序。（了解如何运行复制的无状态和有状态应用程序。）
  • 为了在运行复制的应用程序时获得更高的可用性，请将应用程序分布在机架之间（使用反关联性）或跨区域（如果使用多区域集群）。

自愿中断的频率各不相同。

所以：

  • 如果您的预算允许，将您的应用程序分布在各个区域或机架上，您可以使用节点亲和性在 cetrain 节点上安排 Pod，
  • 确保配置 Replicas，它将确保当一个 Pod 接收SIGKILL到负载时，会自动将负载定向到另一个 Pod。您可以在此处阅读有关此内容的更多信息。
  • 考虑使用DaemonSets，它确保每个节点运行一个 Pod 的副本。
  • 对无状态应用使用部署，对有状态应用使用StatefulSet。
  • 您可以做的最后一件事是编写您的应用程序以容忍干扰。

我希望我为您清理了一点水，请随时提出更多问题。

于 2022-01-05T13:02:13.797 回答