ASP.NET Core 8.0 Web API 和辅助服务合并在一个 Docker 容器中

Question

在 ASP.NET Core 8.0 Web API 中，我可以使用

IHostedService

接口实现长时间运行的服务，并具有在一个 Docker 服务中拥有事件流生产者/消费者和 Web API 的优势。

有人可能会争论为什么不将它们分开，并让流消费者通过 SignalR 将内容推送到连接的客户端。但是，我们假设流数据很大，并且 UI 只需要在某个时间点显示一小部分，或者更好的是，我们有大量现有服务，我们不想重写这些服务，但引入事件流，或者我想要我所有解决方案/服务的统一服务端点。

考虑 Web API 和 Worker Service 的 docker 基础镜像是不同的：

• Web API：

  FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base

• 工人服务：

  FROM mcr.microsoft.com/dotnet/runtime:8.0 AS base

因此，考虑到 Web API 和辅助服务基于两个不同的 docker 映像，并且每个映像都是根据其需求量身定制的，我想知道在 Web API 中运行事件流或消息队列等长时间运行的服务有什么缺点现有 Web API 之上的环境？

由于速度和性能是一个主要问题，当我想要一个主要是后台服务并且在极少数情况下使用 Web API 的服务时，它会明显影响我的性能吗？

只是询问不同的意见和他们的经验，以防他们这样做。

Answer 1

ASP.NET Core 运行时是 .NET (Core) 运行时 + ASP.NET 特定的东西，就“按需定制”而言，docker 镜像只是“更大”（ASP.NET Core 镜像 基于运行时一个）。

将 Web API 和后台处理分开的主要优点是，您可以以不同的方式缩放它们，并在一个不影响另一个的情况下加载峰值。

如果 Web API 响应时间一般不是问题，您没有非常严格的 SLA 并且请求很少 - 那么您将两者结合在一起的单一部署听起来不错。另一方面，ASP.NET Core 运行时映像会更大，因此如果部署了很多容器 - 可能可以节省一些资源（主要是磁盘和 RAM）。