依賴注入和 Mediatr 與 Azure 函數結合使用效率低嗎？

Question

我在我的 Azure 旅程中處於早期階段。 我理解函數的方式是它們是一種無服務器解決方案，僅在實際需要時運行。 在執行了他們的邏輯后，他們再次“關閉”。 與始終運行的應用服務（即使沒有請求）相比，這更便宜。

我目前的情況：我在 DDD 設計中設置了一個類似於 Microsoft 的 eshoponcontainers 解決方案的解決方案。 我有一個 webapi 項目，它只有超薄控制器，只需將輸入傳遞給 Mediatr，Mediatr 將其傳遞給不同的項目進行驗證和業務邏輯。 我所有的 controller 方法如下所示：

[HttpGet]
[ProducesResponseType(StatusCodes.Status200OK)]
[ProducesResponseType(StatusCodes.Status404NotFound)]
public async Task<IActionResult> GetById(string id)
{
    // Mediator instantiated via DI in the controller constructor
    var result = await Mediator.Send(new GetByIdQuery { Id = id });
    return Ok(result);
}

刪除這個 webapi 項目對我來說是微不足道的，並將其替換為 Azure Functions 項目，該項目也從 HTTP 觸發器獲取輸入並將其傳遞給 Mediatr。 我的依賴注入東西設置在不同的項目中，獨立於 webapi，因此也可以輕松插入到我的 Azure Functions 項目中。 我所有的功能都是這樣的：

public class GetId
{
    private readonly IMediator _mediator;

    public GetId(IMediator mediator)
    {
        _mediator = mediator;
    }

    [FunctionName("GetById")]
    public async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] string id,
        ILogger log)
    {
        var result = await _mediator.Send(new GetByIdQuery { AgreementId = id });
        return new OkObjectResult(result);
    }
}

但從成本的角度來看，這不是很糟糕嗎？ 根據我有限的了解，每次啟動 Azure Function 時，它都會重新創建我的實體 DI 容器。 這意味着我為進行 DI 設置的 CPU 時間付出了很多，而不是我的實際業務邏輯。 還是我錯過了什么？

Answer 1

撇開 web API 與 Azure 功能討論不談，您正在做的事情相當奇怪：接受消息以便您可以使用基於事件的消息內容手動觸發 Mediatr。

Azure 已經為此提供了內置功能：事件網格、事件中心或服務總線。 創建這些資源之一，將事件/消息發布到它們而不是 web API/Azure 函數，並將您的 Mediatr 事件偵聽器替換為事件網格/事件中心/服務總線偵聽器。 那么你根本不需要 web API 或 Azure 功能。

關於實際問題，Azure 功能帶來了許多問題 - 無法使用 ASP.NET 核心中間件是一個大問題。 您可能會節省資源使用量，但老實說 Azure 是如此便宜，以至於這樣的節省可能不值得。 （我建議您查看實際定價，而不是假設 Azure 函數會因為它並非始終在線而為您省錢。）不，DI 容器構建根本不會花費太多 CPU - 如果是這樣，您有更大的架構問題。

總是有權衡，沒有什么是免費的。