Azure Function 项目结构（C# 与 CSX）和最佳实践

Question

最近我得到了其他开发人员用 C# Script (.csx) 编写的 Azure 函数代码，我曾经使用 Visual Studio 编写 Azure 函数。

我喜欢 C# Script 命令式绑定，它使代码更简单（无需管理连接）

我看到了 C# 脚本的一些问题

1. 代码质量工具不起作用（StyleCop/Sonar）
2. Can't write unit test against .csx file

如果你有不同的意见，请分享。

所以我决定将所有函数 (10) 转换为带有声纳集成和 UnitTest 的 .net 项目。

问题 我的大多数功能都没有任何业务逻辑，他们从 EventHub 获取触发器并将数据转储到 cosmos DB，我无法决定应该在单个解决方案下创建 10 个项目还是 1 个项目？

我相信具有多个功能的单个项目具有单个 host.json 文件，如果我将更改 host.json 值以缩放特定功能，它也会影响其他功能。我说的对吗？

功能数量=项目数量是正确的解决方案吗？

它将如何影响成本？

Answer 1

个人意见是 CSX 文件可以用于实验或快速而肮脏的东西，但对于生产，您应该使用编译的 c#。

调整 host.json 文件中的任何设置都会影响该函数应用中的所有函数。关于何时将您的功能分解为单独的应用程序没有普遍正确的答案，但您可以提出一些问题来帮助您针对您的场景进行回答：

1. 特定函数是否具有与其他函数截然不同的缩放特性。 （例如，您的消息触发器之一与其他消息触发器的消息量或处理逻辑是否有很大不同 - 您是否需要更改 host.json）
2. 您的功能是否与其他功能执行单独的业务流程（例如，一个正在接收设备遥测消息，而另一个正在处理审计遥测）
3. #1 和 #2 证明创建单独的函数应用程序的管理和开发开销是合理的（大量的函数应用程序，尤其是在类似微服务的架构中可能难以管理）

在您的情况下，您的函数应用程序具有一定的灵活性，因为它们只是消息侦听器，如果您发现以后想将函数分解为单独的应用程序（例如 http 端点），它们不会像 http 触发器那样受到影响变化）。

Answer 2

您迁移到预编译项目的总体想法是有道理的。 Microsoft 建议将其用于除最简单的 ad-hoc 函数之外的所有函数。

单个项目与多个项目应根据您是需要单个功能应用程序还是多个应用程序来决定。 Function App 是一个缩放单元。如果您希望多个函数独立扩展，它们应该位于单独的应用程序和项目中。