【问题标题】:What's the recommended way to handle microservice processing bugs new insights?处理微服务处理错误新见解的推荐方法是什么?
【发布时间】:2017-09-08 15:50:49
【问题描述】:

在回答我的问题之前,让我勾勒出一组微服务示例来说明我的困境。

场景大纲

假设我有 4 个微服务:

一项激活服务,提供给我们客户的功能被(停用)激活。可以添加和更改成员的注册服务。一种安全密钥服务,能够生成安全密钥(在一个多步骤过程中),供成员在与外界通信时使用。以及用于与外部供应商就我们的会员进行交流的通信服务

安全密钥服务可能仅在此功能被激活时才请求安全密钥。此外,通信服务只能与拥有安全密钥的成员进行通信,并且通信功能本身是否已激活。

因为它们是微服务,所以每个服务都有自己的数据存储并且完全自给自足。也就是说,其他微服务所需的任何数据都在本地复制,并通过来自其他微服务的异步消息保持同步。

困境

我实际上面临两个主要困境。首先是(很明显)数据同步。当有多个数据存储需要保持同步时,您必须考虑消息丢失或无序处理。但是有很多开箱即用的解决方案可以解决这个问题,当所有解决方案都失败时,您甚至可以退回到某种 ETL 流程来保持同步。

然而,我面临的主要问题是需要执行的操作。在上面的例子中,安全密钥服务必须执行一个动作,当它要么

  1. 当新成员知道安全密钥功能在激活服务中处于活动状态时,会收到来自注册服务的消息
  2. 收到来自激活服务的消息,当它已经知道来自注册服务的成员时,安全密钥功能现在处于活动状态

在这两种情况下,这意味着来自外部系统的消息必须导致本地数据副本的更新以及需要处理的一些逻辑。

问题

现在是实际问题:)

在处理这些消息时,应对错误或新见解的推荐方法是什么?假设 激活服务 的消息处理程序中存在错误。处理程序确实更新了内部数据结构,但它未能检测到已经注册的成员,因此永远不会启动 安全密钥生成 过程。或者,可能是没有错误,但我们认为我们希望处理程序执行其他操作。

系统将没有理由重新提交或重新处理消息(因为消息没有失败),但我们没有真正的方法来重新触发消息背后的行为。

我希望我的要求很清楚(如果它应该发布在其他 170 个 Stack... 网站中的任何一个上,我深表歉意,我只知道 StackOverflow)

【问题讨论】:

    标签: asynchronous message-queue microservices


    【解决方案1】:

    我不知道推荐的方法是什么,我知道DDD 是如何做到的,也许这可以帮助你,因为DDD 和microservices 是朋友。

    您所拥有的是一个长期运行/多步骤的流程,其中涉及来自多个微服务的信息。在 DDD 中,这可以使用Saga/Process manager 来实现。 Saga 通过订阅来自registration serviceactivation service 的事件来维护本地状态。随着事件的发生,Saga 通过提交CreateSecureKey 命令来检查它是否拥有生成安全密钥所需的所有信息。事件可能以任何顺序出现,甚至可以重复,但这不是问题,因为 Saga 可以弥补这一点。

    如果出现错误或新功能,您可以创建特殊脚本或其他进程来搜索特定情况并通过提交特定的补偿命令来处理它,而无需重新处理所有过去的事件。

    如果出现新功能,您甚至可能必须处理现在对您的业务流程感兴趣的旧事件。您可以以同样的方式执行此操作,通过查询新有趣的旧事件的事件源并将它们发送到新更新的 Saga。在导入过程之后,您将 Saga 订阅到这些新有趣的事件,并且 Saga 继续照常运行。

    【讨论】:

    • 感谢您的意见,我想我只是担心潜在的理论问题。查看您引用的文章中的图 2,假设 Order Process Manager 存在问题,导致有时不发送 付款 请求(步骤 7)。是否有一些标准或推荐的方法来确保我们能够从这种情况中恢复过来?
    • @Robba 我不这么认为,每个故障都有自己的恢复模式,但是如果您考虑要检测创建(自动)的(最重要的)故障类型,这是可以的检查特定故障的脚本。
    • 感谢您的帮助,我会创建更多图表并寻找破坏系统的方法;)
    • 我使用“如果服务器现在重新启动怎么办”场景来检测一些状态不一致,它可以帮助你
    • 您的意思是在应用程序启动时检查不一致?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-06-12
    • 1970-01-01
    • 2013-03-29
    • 2015-07-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多