如何管理微服务失败？

Question

比方说，我有几个微服务（REST API），问题是，如果一个服务是无法访问的（我们称之为服务“A”）将其发送给服务“A”将被保存在临时数据库中的数据。服务完成后，数据将再次发送。 问题： 1.我应该每10秒钟创建一次服务“A”服务来知道服务工作吗？或者是否可以通过任务队列来完成？有什么建议么？

Answer 1

轮询是浪费带宽。你想使用一个事务性的队列。

掷所有出站队列中的消息，并有一些其他的进程来处理消息。

这将如何工作 - 后您的过程从队列中读取，并试图发送到REST服务：

• 如果它工作，提交事务（队列）
• 如果不起作用，不要犯。开始延迟（分钟，秒 - 你最清楚），直到你再次从队列中读取。

Answer 2

有多个维度对您的问题。首先，您需要考虑使用提供弹性的基础架构并使用self healing。这意味着您要部署容器集群，所有容器均包含您的服务A.现在，您可以在服务前使用负载平衡器或API网关来分配呼叫/加载。它还会定期检查您的服务的健康状况。当它检测到容器没有正确响应时，它可以杀死容器并启动另一个容器。这可以通过一个容器的基础设施，如kubernetes /泊坞窗群等

现在，这并不保护丢失任何请求提供。如果容器发生故障，那么在故障与下一次健康检查之间仍然会有很短的时间，因为请求可能无法提供。在许多应用程序中，这是可以接受的，客户端将重新请求并击中另一个（健康容器）。如果您的应用程序要求绝对不会丢失请求，则必须将请求缓存在例如API网关中，并确保其保留到服务完成之前（也称为Circuit Breaker）。 Netflix Zuul和Hystrix就是一个示例技术。使用这种内置容错的关守可以进一步提高弹性。作为一个方面说明 - 使用API​​网关还可以解决中央认证/授权，路由和监控问题。

的另一种方法来添加弹性/解耦是使用快速流/消息队列，如Apache卡夫卡，用于记录所有传入消息，并且具有准备的消息处理器处理他们时。然后，诀窍是只在您的请求完全投放时将消息标记为已处理。这也有助于在由于服务无法实时处理大量请求而导致出现故障的情况下（Asynchronous Decoupling with Cache）。

Answer 3

您可以使用断路器模式，例如，来自netflix的hystrix断路器。

有可能在超时或者当服务调用失败或难以接近打开断路器基。

Answer 4

服务可用时“A”应该解雇“就绪”事件。只听那个，然后重新发送你的请求。