微服务 - 从同一队列生产和消费

Question

我们正在设计一个基于微服务的新系统。
我想咨询一下，从同一个队列中生产和消费是否被认为是一种反模式。
该服务应该是基于 REST 的微服务。
后端微服务应该处理 IoT 设备上的大规模操作，这些设备可能并不总是连接到互联网，API 必须是异步的，并提供强大的功能，例如最终失败前的 X 重试次数等。
API 应立即从 POST 请求返回一个带有 201 个响应的 UUID，并通过在 get 请求中接受 UUID 来公开 IoT 设备操作状态的“获取当前状态”（挂起、活动、完成等）。
我们已经考虑了两种用于管理此任务的解决方案（在较高级别进行了描述）：

1. 同时实现 API GW 微服务和逻辑处理程序微服务。 API GW 将公开 REST API 方法，并将通过 RabbitMQ 发布消息，这些消息将由逻辑处理程序微服务的多个实例使用。 主要缺点是我们需要管理多个部署，并保持服务 A 中向服务 B 中的消费者公开的 API 之间的一致性。
2. 实现一个微服务，它公开相关的 API，为了处理规模和异步操作，将通过 RabbitMQ 将请求发布到自己的队列，由后台工作程序中的同一个微服务使用。

第二种解决方案看起来更易于开发、维护和更新，因为包括 REST API 处理在内的所有逻辑都将处理同一个微服务。
对于团队的一些成员来说，这个解决方案看起来有点脏，我们无法确定消费自己队列的消息是否是一种反模式。

任何建议都会有所帮助。

Answer 1

<块引用>

我想咨询一下，从同一个队列中生产和消费是否被认为是一种反模式。

这听起来确实很可疑，并不是说我对队列有很多经验。 但是，您还谈到了微服务以及从中“生产”和消费 - 听起来不错，没有理由说明微服务（以及扩展，它的 API）不能两者兼而有之。但后来我有点困惑，因为在阅读问题的其余部分时，我并没有真正明白这个问题是如何成为一个因素。

在 API 和微服务之间进行某种分离听起来很明智，因为您可以在不影响调用者的情况下更改微服务实现，假设这是一个非破坏性的更改。这意味着您有能力分别解决 API/消费者问题和后端问题。

版本控制只是良好工程实践的一部分，可能不是改变架构的理想理由。您应该能够并行运行多个版本——许多 API 提供商运行 N+2 模型，它们支持当前版本以及最后两个（主要）版本。这样您就可以为您的消费者提供合理的升级渠道。

Answer 2

只要您将这两个关注点保持模块化，这样您就可以在有意义的时候将它们分开。

我认为从长远来看，您可能希望将它们视为 two aspects of the same service，因为它们可能具有不同的更新周期（例如，网关部分可能需要诸如 auth 之类的东西，或者 gRPC 中的其他 api等），不同的安全要求（一个可以被外部访问，而另一个消耗内部资源）不同的可扩展性问题（您可能需要更多资源进行处理）等。