Microsoft AZURE blob 触发功能间歇性工作

Question

我们遇到了 Blob 触发函数的问题。该函数是用javascript编写的。我们很难为它制定一个自动化的部署流程。以下是我们遵循的步骤。

1. 使用 ARM 模板和参数文件在现有资源组中创建函数应用 New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateFile $templateFilePath -TemplateParameterFile $armParametersFilePath;

2. 通过Kuduapi 部署函数代码Invoke-RestMethod -Uri "$apiUrl" -Method Put -InFile "$functionCodeArchivePath" -Credential $credentials -DisableKeepAlive -UserAgent "powershell/1.0" -TimeoutSec 600

3. npm install通过kudu api运行命令 Invoke-RestMethod -Uri "$apiCommandUrl" -Method Post -Body $json -DisableKeepAlive -ContentType "application/json" -Credential $credentials -UserAgent "powershell/1.0" -TimeoutSec 1200

在最后一步 -npm install在 Kudu 上获取依赖项 ( )的命令超时，这似乎是一个已知问题。

为了克服这个问题，我们采用 WebPack 将所有依赖项打包到一个 JavaScript 文件中，遵循这种方法。

现在部署速度更快，但该功能似乎没有正确执行。

当我们将一个文件放入我们的 blob 存储帐户时，该函数是从 触发的，该函数似乎并不总是记录执行跟踪。有些运行具有完整的日志，有些运行只包含Function started在其中而没有任何自定义日志语句。

这是直接来自 Kudu 的日志（D:\home\LogFiles\Application\Functions\Function\functionname>）

2017-03-03T11:24:33.835 Function started (Id=77b5b022-eee0-45e0-8e14-15e89de59835)
2017-03-03T11:24:35.167 JavaScript blob trigger function started with blob:
2017-03-03T11:24:35.167 Name: _1486988111937 
 Blob Size: 8926 Bytes
2017-03-03T11:24:35.167 Extracting file
2017-03-03T11:24:35.167 JavaScript blob trigger function processed blob 
 Name: _1486988111937 
 Blob Size: 8926 Bytes
2017-03-03T11:24:35.183 Function completed (Success, Id=77b5b022-eee0-45e0-8e14-15e89de59835)
2017-03-03T11:24:35.292 { Error: [** SENSITIVE ERROR MESSAGE, INTERNAL TO FUNCTION, REMOVED **] }
2017-03-03T11:28:34.929 Function started (Id=8bd96186-50bc-43b0-916c-fefe4bd0cf51)
2017-03-03T11:38:18.302 Function started (Id=7967cc93-73cf-4acf-8428-20b0c70bbac9)
2017-03-03T11:39:32.235 Function started (Id=a0abb823-9497-429d-b477-4f7a9421132e)
2017-03-03T11:49:25.164 Function started (Id=ab16b1d9-114c-4718-aab2-ffc426cfbc98)
2017-03-03T11:53:51.172 Function started (Id=87ed29bc-122f-46d2-a658-d933330580c9)
2017-03-03T11:56:06.512 Function started (Id=23f8ee3f-cda0-45a3-8dd0-4babe9e45e4e)
2017-03-03T12:02:58.886 Function started (Id=c7ef7ad5-62b8-4b43-a043-bc394d9b02f5)

PS：我们的函数代码是获取 blob，一个压缩文件，解压缩它并对压缩文件夹中的每个文件进行 API 调用。[** SENSITIVE ERROR MESSAGE, INTERNAL TO FUNCTION, REMOVED **]日志中标有 的错误与与我们的 API 的连接有关。

Answer 1

看起来 Blob 触发不是那么可靠，至少根据这个页面：How to use Azure blob storage with the WebJobs SDK

WebJobs SDK 扫描日志文件以观察新的或更改的 blob。这个过程不是实时的；在创建 blob 几分钟或更长时间后，函数可能不会被触发。此外，存储日志是在“尽力而为”的基础上创建的；不能保证所有事件都会被捕获。在某些情况下，日志可能会丢失。如果您的应用程序无法接受 blob 触发器的速度和可靠性限制，则推荐的方法是在创建 blob 时创建队列消息，并在处理 blob 的函数上使用 QueueTrigger 属性而不是 BlobTrigger属性。

您可能应该更改逻辑并为您放入 Blob 存储的每个文件创建一个队列消息