RabbitMQ、REST API、Docker 和 Kubernetes 最佳实践问题

Question

这是一个高级问题，我正在询问我目前正在构建的东西，但似乎无法找到我正在寻找的确切答案。

场景： 我有一个 .Net Core REST API，它将接收来自外部应用程序的请求。这些请求将被推送到 RabbitMQ 实例中。这些通知将被发送到一个交换器，然后分散到多个队列以供多个消费者使用。

我将负责一位消费者，我正在寻求有关最佳做法的建议。最终，将有一个 REST API 最终需要对这些被推送到队列中的消息做出反应。这个 REST API 是在 Kubernetes 集群上运行的容器化 (Docker) 应用程序。它将在这些通知（队列消息）之外接收大量请求流量，进行 SQL 调用等。

我的问题是，我是否应该有一个订阅此队列的外部微服务（托管服务/后台服务）以调用所述 REST API。有点像交通警察；根据某些数据点将消息路由到适当的 API 方法。

或者

是否可以将此消费者直接放入有问题的高流量 REST API 中？

对此有什么建议吗？提前致谢！

Answer 1

没有对错之分。这就是整体微服务和同步异步的困境。

如果您正在考虑使用微服务和更多的异步，您可以从以下问题开始：

• 您希望您的系统分成不同的代码库吗？
• 您想在不同团队之间划分职责吗？
• 您想为不同的组件使用不同的语言/项目吗？
• 您希望系统的某些组件更快地响应用户吗？
• 您的应用可以接受一个解耦组件可能完全失败的事实吗？

我是否应该有一个订阅此队列的外部微服务（托管服务/后台服务）以调用所述 REST API。有点像交通警察；根据某些数据点将消息路由到适当的 API 方法。

是的，如果您对微服务路线有更多的思考，并且上述大多数问题的答案是“是”（甚至更多未提及的微服务相关问题）。

---

如果您正在考虑更多关于单体路由：

• 您是否同意在不同团队之间共享相同的代码库？
• 您是否接受更统一的编程语言？
• 你想拥有一个monorepo吗？ （虽然你可以用 monorepos 做微服务）
• 代码库是否将主要由一些非常了解它的人来开发？
• 在应用程序中提供冗余是否容易？即，如果一个组件发生故障，应用程序不会崩溃。

是否可以将此消费者直接放入有问题的高流量 REST API 中？

是的，如果您的代码可以处理它并且您更符合上述答案中的“是”。