azure - 名称少于 32 个符号的 Azure Function Apps 的专用或共享存储帐户

Question

简短版本
我们想要迁移到 v4，并且我们的应用名称少于 32 个符号。
我们是否应该迁移到专用存储帐户？

长版
我们使用Azure Functions v3。从一开始，10 多个 Azure Function 应用 就共享一个存储帐户。这可能是运气好，但名称少于 32 个符号，而且不会改变。我们不使用插槽，因为最初不推荐它们，然后没有普遍采用的时间或建议。

问题前研究揭示this问题，但它看起来与耐用功能更相关。 Another问题看起来更切题，但已经过时，并且接受的答案指出可以使用一个存储帐户。

首先，官方文档中有一个页面是storage considerations它指出(指向它的 ijabit 的属性。):

It's possible for multiple function apps to share the same storage account without any issues. For example, in Visual Studio you can develop multiple apps using the Azure Storage Emulator. In this case, the emulator acts like a single storage account. The same storage account used by your function app can also be used to store your application data. However, this approach isn't always a good idea in a production environment.

不幸的是，它没有进一步详细说明最后一句话背后的基本原理。 page with best practices对于 Azure Function 提及:

To improve performance in production, use a separate storage account for each function app. This is especially true with Durable Functions and Event Hub triggered functions.

令我更加困惑的是was此页面上的一个小节表示“避免共享存储帐户”。但后来被删除了。
This问题在某种程度上与问题表面相关，因为它在线程中提到了建议。

其次，我们就与此问题无关的不同问题联系了 Azure 支持，两位不同的支持工程师对当前问题分享了不同的意见。一位说我们可以在 Functions Apps 之间共享存储帐户，另一位说我们不应该。因此，支持人员的建议好坏参半。

第三，我们希望迁移到 v4 并在 migration notes 中据称:

Function apps that share storage accounts will fail to start if their computed hostnames are the same. Use a separate storage account for each function app. (#2049)

深入研究这个主题，唯一的问题是 collision用于获取锁定的函数主机名，该锁定甚至在 2017 年 10 月就已知。人们可以关注该线程，看看如何在 2020 年 1 月提出更新官方 Azure 命名建议的建议，但它是 made仅在 2021 年 11 月下旬。我还发现一个非侵入式(即无需重命名)的解决方案是 manually set the host id 。两个参数raised balag0 的特点是:单点故障和更好的隔离。从更简洁的架构的角度来看，它们听起来不错，但实际上，我个人认为存储帐户是可靠的，尤其是在阅读有关冗余或考虑到 MS 正在将其用于其他服务时。所以对我来说它看起来更像是 Azure 的支柱。

最后，由于我们想要迁移到 v4，我们是否应该迁移到专用存储帐户？

Answer 1

对于我所从事的包含 30 多个 Azure 函数的大型项目，我们使用了专用存储帐户。原因是Azure Storage account service limits 。正如文档提到的，这确实在持久任务功能中发挥作用，但也可以在其他高容量场景中发挥作用。存储帐户的硬性限制为每秒 20k 个请求。达到该限制，请求将失败并返回 HTTP 429 响应。这意味着您的 Azure Function 调用也将失败。我们正在运行一些大容量场景并遇到了这个问题。

如果两个函数在 host.json 中具有相同的 TaskHub ID，也可能会导致持久任务函数出现问题。当持久任务框架使用存储队列和表存储进行内部簿记时，这会导致冲突，并且当事情以惊人的方式失败时会带来很多痛苦和痛苦。

请注意，可以通过向 Azure 提交支持票证来提高每秒 20k 请求的服务限制。如果获得批准，他们会将其提高到每秒 50k 请求。

因此，请避免潜在的麻烦，并为每个功能使用一个存储帐户。