Azure Function 项目结构(C# 与 CSX)和最佳实践

Question

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

我喜欢 C# 脚本命令式绑定(bind)，它使代码更简单(无需管理连接)

我发现 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 点证明了创建单独函数应用的管理和开发运营开销是合理的(大量函数应用，尤其是在类似微服务的架构中，可能是管理上的挑战)

在您的情况下，您的函数应用程序具有一定的灵 active ，因为它们只是消息监听器，如果您发现稍后想要将函数分解为单独的应用程序(例如http端点)，它们不会像http触发器那样受到影响改变)。