Azure创建关联基础架构的最佳实践

在azure中工作并利用所有PaaS产品（如队列和表）时，我经常面临这样的难题：是应按需创建这些资源，还是作为资源调配的一部分提前创建这些资源

例如，假设我有一个worker角色，它从队列接收消息，然后将数据持久化到表中。我有两个选择

选项1-预先调配 作为配置过程的一部分，我可以通过类似于powershell脚本的方式创建队列和表。在代码中，在运行时，它会期望这些资源存在，如果它们不存在，则会引发异常

专业人士

• 该服务不需要管理员权限，因为它不需要创建任何内容
• 所有资源调配工作都发生在一个地方（资源调配脚本），而不是分散在代码中

缺点

• 该服务不能是“自愈”的。我的意思是，如果所需资源不存在（例如队列或表），或者可能不以所需的形式存在，则服务无法自动从中恢复。相反，它需要人工干预

选项2-随需应变

在运行时，由于需要资源，如果资源不存在，则会创建资源

专业人士

• 正在运行的服务可以创建它所需要的任何东西，因此将更加健壮，需要的干预更少

缺点

• 代码现在具有提升的权限，这可能会引起一些安全问题

---

我发现自己面临这个问题，主要是在处理队列或主题/订阅时。这有两个相互矛盾的原因

我希望为每个队列创建一个共享访问密钥，并且只授予所需的权限。例如，在上面的场景中，从队列读取数据时，我将创建一个具有只读权限的SAK

我喜欢在需要时自动创建东西，特别是在开发过程中。这让事情变得容易多了，而且一切都正常

---

我想知道的是，Azure团队或更广泛的社区是否推荐使用哪种方法？有人能给我一些明确的理由来选择其中一个选项吗？

作为资源调配的一部分，我们过去常常创建存储容器和队列。但在本地处理这是一件痛苦的事情：开发人员有时会被代码中不相关部分抛出（并吞没）的随机异常所困扰。有一次，我们浪费了一天时间才意识到存储容器不是本地创建的

然后，我们转向了“按需创建”，从不后悔

如果您谈论的是存储队列和表，那么就不需要提升访问权限—创建容器/队列/表可以使用与应用程序使用存储帐户相同的访问密钥

---

如果您谈到存储帐户和数据库，那么我们将其作为资源调配的一部分来进行—创建它们需要一个管理证书和对Azure管理API的一些调用。对于那些永远不会被删除/修改的东西来说，这是更多的额外工作。此外，如果您的应用程序突然失去了对blob存储的访问，则说明出现了严重错误，尝试自动修复也不会有任何好处。

不幸的是，基于意见的问题不适合在这里使用。解决这类问题有几种方法，没有单一的正确答案。谢谢David，我在提出问题之前考虑过这一点，但得出的结论是，最好的做法肯定应该优于简单的意见，对吗？