架构：使用单独的队列进行错误处理？
Architecture: using a separate queue for error handling?
我们有一个小型微服务，其唯一目的是通过队列接收消息并将这些消息发送到外部系统。消息可以来自任意数量的其他服务，并且该服务不知道消息的内容。外部系统可以接受或拒绝此消息。我看到了一些处理外部系统响应的选项：
- 将响应放在用于接收消息的同一个队列中
- 将响应放在不同的队列中
- 将成功响应放在不同的队列中，将错误响应放在另一个队列中
我倾向于选择第三个选项来分离关注点，而不是用错误流程打扰愉快的流程，但希望得到反馈为什么这可能是一个糟糕的选择。
是否有任何可用资源记录此类问题的最佳实践解决方案？
（我知道上面可以重写为从队列中读取消息并将消息存储在数据库中的服务，将消息异步发送到外部系统并将响应存储在数据库中，发布事件以指示消息已处理并开发了一个 api 以允许从数据库检索响应，但这将需要一个额外的数据库、更多的工作和更多的资源，在我看来这太过分了）
出于几个原因，我也会选择第三个选项并分开您的顾虑。
- 如果所有不同类型的消息都在同一个队列中，那么您的消费者将不得不使用 filter/selector 来获取他们想要的消息。这会增加消费者的复杂性。此外，消费者端 filters/selectors 通常不被鼓励，因为它们会对性能产生负面影响，因为代理必须执行队列扫描以查找与消费者过滤器匹配的消息。
- 如果所有消息都在同一个队列中，那么管理会更加复杂。例如，如果您想知道发生了多少错误，则需要您的管理工具扫描队列以查找与错误模式匹配的消息。如果错误在单独的队列中，您只需查看队列中的消息数。
- 多个队列通常会提高性能，因为它们会增加并行度并减少瓶颈。大多数现代代理（例如 ActiveMQ Artemis）都可以很好地扩展多个队列和客户端。
值得注意的是，消息代理并不像数据库那样用于长期数据存储。如果您打算将响应详细信息保留一段时间，您可能希望在某个时候将它们卸载到数据库中。
有单独的错误队列/路径是将错误抛回给调用者（以某种方式）的替代方法......面向铁路的编程。
我们有一个小型微服务，其唯一目的是通过队列接收消息并将这些消息发送到外部系统。消息可以来自任意数量的其他服务，并且该服务不知道消息的内容。外部系统可以接受或拒绝此消息。我看到了一些处理外部系统响应的选项：
- 将响应放在用于接收消息的同一个队列中
- 将响应放在不同的队列中
- 将成功响应放在不同的队列中，将错误响应放在另一个队列中
我倾向于选择第三个选项来分离关注点，而不是用错误流程打扰愉快的流程，但希望得到反馈为什么这可能是一个糟糕的选择。
是否有任何可用资源记录此类问题的最佳实践解决方案？
（我知道上面可以重写为从队列中读取消息并将消息存储在数据库中的服务，将消息异步发送到外部系统并将响应存储在数据库中，发布事件以指示消息已处理并开发了一个 api 以允许从数据库检索响应，但这将需要一个额外的数据库、更多的工作和更多的资源，在我看来这太过分了）
出于几个原因，我也会选择第三个选项并分开您的顾虑。
- 如果所有不同类型的消息都在同一个队列中，那么您的消费者将不得不使用 filter/selector 来获取他们想要的消息。这会增加消费者的复杂性。此外，消费者端 filters/selectors 通常不被鼓励，因为它们会对性能产生负面影响，因为代理必须执行队列扫描以查找与消费者过滤器匹配的消息。
- 如果所有消息都在同一个队列中，那么管理会更加复杂。例如，如果您想知道发生了多少错误，则需要您的管理工具扫描队列以查找与错误模式匹配的消息。如果错误在单独的队列中，您只需查看队列中的消息数。
- 多个队列通常会提高性能，因为它们会增加并行度并减少瓶颈。大多数现代代理（例如 ActiveMQ Artemis）都可以很好地扩展多个队列和客户端。
值得注意的是，消息代理并不像数据库那样用于长期数据存储。如果您打算将响应详细信息保留一段时间，您可能希望在某个时候将它们卸载到数据库中。
有单独的错误队列/路径是将错误抛回给调用者（以某种方式）的替代方法......面向铁路的编程。