azure - 基于事件的容器App是如何被调用的？

Question

我对如何开发将在容器应用程序中运行并响应服务总线主题中的消息的 C# 应用程序感到有点困惑。

我之前曾使用过基于事件的 Azure Functions，在我看来，它们是相同的，只是容器应用程序完全基于容器。

在 Azure Functions 中，我可以使用带有 [Function] 属性和函数参数上的 ServiceBusTrigger 属性的 Run() 方法。然后，当消息添加到主题时，Azure Functions 将负责调用我的函数，并将消息传递到函数的入口点。

我正在寻找类似的调用模型，其中当消息添加到主题时，我的应用程序或应用程序的入口点由 KEDA(?) 或 DAPR(?) 触发。

但是，我看到的示例创建了一个 Microsoft.Extensions.Hosting.BackgroundService 工作线程，然后创建一个“消息泵”来为该工作线程订阅主题订阅。因此，容器不断运行，并且负责监听新消息。这不是我所期望的。

看到定价模型与 Azure Functions 的计费方式(vCPU、内存和请求)相似，我想象每个请求都会调用容器。

看起来 KEDA 只负责向上和向下扩展容器应用程序，而不负责在收到新事件时调用容器。

请告诉我我的理解是否正确。

Answer 1

在基于事件的容器应用程序方法中- 容器负责监听事件并响应它们。而且它不遵循 Azure Functions 的按需调用模型，在该模型中，平台会在触发事件发生时负责调用您的函数。

相反，在基于容器的场景中，您需要在容器内创建一个长时间运行的进程来订阅事件并对事件使用react。这通常是通过创建连续轮询或监听事件的后台服务或工作人员来实现的。 在容器内创建长时间运行的进程的步骤。

• 使用 Docker 创建容器镜像。

Docker 文件

#See https://aka.ms/customizecontainer to learn how to customize your debug container and how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/azure-functions/dotnet:4 AS base
WORKDIR /home/site/wwwroot
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["testingFun/testingFun.csproj", "testingFun/"]
RUN dotnet restore "testingFun/testingFun.csproj"
COPY . .
WORKDIR "/src/testingFun"
RUN dotnet build "testingFun.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "testingFun.csproj" -c Release -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /home/site/wwwroot
COPY --from=publish /app/publish .
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

• 选择服务总线主题。

• 使用Dotnet SDK to connect the Event source.

• 并订阅事件

• 运行该进程。

The examples you've seen that use Microsoft.Extensions.Hosting.BackgroundService and create a "message pump" are following this approach.

容器保持运行状态，容器内的工作线程负责监听来自服务总线主题的新消息。此设置允许工作人员在事件到达时连续处理事件。

KEDA 用于根据事件驱动指标自动扩展 Kubernetes 工作负载。

Dapr 是一个运行时，可简化基于微服务的应用程序的开发。

In an event-based container app approach, the container stays running, and you need to implement a background service or worker inside the container to subscribe to events and handle them as they arrive. KEDA and Dapr can be used alongside container apps to provide additional capabilities like scaling and pub/sub messaging, respectively, but they don't handle the event invocation directly.

有关更多信息，请参阅此 MS Doc .