c# - RabbitMQ，REST API，Docker和Kubernete最佳实践问题

Question

这是一个高级别的问题，我要的是我目前正在设计的东西，似乎无法找到我想要的确切答案。
场景:
我有一个.Net Core REST API，它将接收来自外部应用程序的请求。这些请求将被推送到RabbitMQ实例中。这些通知将被扔到交易所，然后扇出到多个队列供多个使用者使用。
我将负责一名消费者，我正在寻找有关最佳做法的建议。最终，将有一个REST API，最终将需要对将这些消息推送到队列中使用react。有问题的REST API是在Kubernetes集群上运行的容器化(Docker)应用程序。除了这些通知(队列消息)之外，它将接收大量请求流量，进行SQL调用等。
我的问题是，是否应该有一个外部微服务(托管服务/后台服务)订阅此队列，以调用所述REST API。有点像交通警察；根据某些数据点将消息路由到适当的API方法。
要么
是否可以将该使用者直接放入有问题的高流量REST API中？
有什么建议吗？提前致谢!

Answer 1

没有对与错。这是围绕单片微服务和同步异步的整个难题。
如果您正在考虑使用微服务和更多异步服务，则可以从以下问题开始:

您是否希望系统进入不同的代码库？

您想在不同团队之间划分职责吗？

是否要对不同的组件使用不同的语言/项目？

您是否希望系统的某些组件更快地响应用户？

一个解耦的组件可能会完全失败，您的应用程序还可以吗？

should I have an external microservice (hosted service/background service) that subscribes to this queue with the intent of calling into said REST API. Kind of like a traffic cop; routing messages to the appropriate API method based on certain data points.

是的，如果您对微服务路线的思考更多，并且对上述大多数问题(甚至更多未提及的与微服务有关的问题)的回答都是"is"。

如果您正在考虑整体路线:

在不同团队之间共享相同的代码库可以吗？

您可以使用更统一的编程语言吗？

您是否想要一个monorepo？ (尽管您可以使用monorepos进行微服务)

该代码库是否主要由一些非常了解代码库的人开发？

在应用程序内提供冗余是否容易？即，如果一个组件失败，则应用程序不会崩溃。

Would it be OK to put this consumer directly into the high-traffic REST API in question?

是的，如果您的代码可以处理它，并且您对上述答案的回答是"is"，则更加满意。