我有 2 个微服务，A 和 B。当A 收到来自用户的请求时，它会被处理（在数据库中存储一些东西）并将消息发送到由B 读取的队列。
如果队列关闭，我最初的想法是让整个请求失败，回滚，并向用户显示错误，要求稍后再试。这是一种不好的做法吗？
将消息存储在A 的标记为NOT_SENT 的数据库中并在队列再次启动时有工作稍后发送它会更好吗？还是过度设计？
编辑：对A 的请求需要同步，所以用户知道它的结果，但他们不需要还需要知道B 处理消息的结果，所以它可以是异步的。
【问题讨论】：
标签： architecture queue message-queue microservices amazon-sqs
您正在就一个非常抽象的示例提出具体问题。在实践中，这样的问题很少产生有用的结果。
话虽如此，如果您的系统无法以可靠和确定的方式处理请求（例如，队列组件不起作用），那么您应该阻止所有依赖于该功能的请求（即使用 503 - 服务不可用）。实际上，这是队列问题还是数据库问题并不重要——除非所有部分都正常运行，否则服务无法执行其行为，因此请提前告知客户。如果您需要更高的可靠性，则必须在设计上投入更多时间以实现更高的可靠性。
【讨论】：
我有 2 个微服务，A 和 B。当 A 收到用户的请求时，会对其进行处理（将一些内容存储在数据库中），并将一条消息发送到 B 读取的队列。
好的。让我们假设某些东西被处理并保存到数据库中 = 产生了一些副作用。
如果队列已关闭，我最初的想法是让整个请求失败并向要求稍后重试的用户显示错误。这是一种不好的做法吗？
但是您需要撤消第一步（上面讨论过的那个），然后才使客户的请求失败！你有两个选择：
将副作用和队列添加到事务中；这仅适用于可撤消的副作用（即删除文件是不可撤消的，除非它只是移动到垃圾箱）。当第一步必须同步处理时，应使用此解决方案。
还将请求添加到队列并稍后处理，第一个异步步骤是微服务 A。如果添加到队列失败，则请求失败。此解决方案比第一个解决方案更具可扩展性。
【讨论】：
您正在数据库中创建一个冗余队列。如果您的队列不可靠，您可以创建几个，但是使用数据库设计您自己的队列是重复工作。如果您确实需要两个队列来实现冗余，请创建两个队列。它可以兼作医院队列，因为可能需要处理主队列中的处理失败（具有相同的重试语义）。
【讨论】：
是的，正如 Nicolas 指出的那样，这取决于您的操作是原子操作（因此用户需要即时反馈），还是只是一个后台处理作业。 我只想补充一点，您可能会考虑实施一个断路器模式，在向用户报告失败之前重试几次，或者将消息持久化为 NOT_SENT，具体取决于您的要求。
【讨论】：
我觉得这取决于用户是否应该能够根据他们的第一个操作对系统执行任何操作，或者他们希望它立即反映在其他地方。
作为一个示例，因为您通常在会话中管理此信息而不是写入数据库：如果第一个操作是“将产品添加到购物车”，然后用户继续尝试结帐，我认为整个请求应该尽早失败，而不是保存一个在稍后失败时可以被视为“假”的状态，并且一开始似乎工作正常。
另一个例子可能是获取某种收据或代码，然后他们想用它来离线兑换某些东西，但负责执行此操作的人员并没有将代码视为有效，而您又一次处于这种思维状态另一个是错误的，因为它们有不同的数据。
现在，如果您只是想收集一些数据并在不同的服务中处理它，也许最好将其保存为未发送，而不是强制用户多次发送数据或稍后再返回。
有了更多关于您的需求或领域的详细信息，您可能会对哪个选项是一个好的解决方案做出更有根据的猜测，因为它们解决了不同的问题。
【讨论】：