我是否应该复制我的 Azure Web 作业实例以提高灵活性？

Question

我有一个包含多个例程的 Web 作业，为了执行特定的例程，例程的名称作为作业的参数传递。所有这些例程都必须执行，并且它们之间存在依赖关系（一个例程的输入可能是另一个例程的输出）；因此，为了协调这一点，我打算使用一个 Logic App，它实际上会调用同一个 Web 作业，但传递不同的参数。

通过以上所有操作，我将拥有一个 Web 作业实例，并使用逻辑应用程序控制作业流。 但这是我的担忧......假设我只想执行一个特定的例程（它是独立的，它不依赖于另一个例程），因为它失败（或者我想调试它），所以我必须去我在 Azure 中的 Web Jobs 门户，并复制作业的 web hook url，将作业参数设置为调用例程的查询参数需要，然后通过 HTTP 客户端调用它。但我看到的问题是这不是那么友好：我必须做所有这些事情才能调用特定工作的例程。

为了解决上述问题，我计划复制作业实例（此处使用的复制术语不是为了扩展，而是为了灵活性），并将例程的名称硬编码到每个作业复制中。我看到的唯一优点是通过直接转到其各自的作业实例来运行特定的例程，然后单击“运行”按钮（Azure 门户）。但是，我在这里看到的缺点是我正在复制相同的源代码（相同的二进制文件），但只是传递了一个不同的参数（在这种情况下是例程的名称），所以就可维护性而言，这很痛苦，因为如果作业源代码发生了一些变化，我必须重新部署“例程计数”次数以保持一致性（所有作业都在相同的源代码下运行）。

那么我应该牺牲代码可维护性（多次重新部署相同的源代码，并使用作业参数）来获得一种友好的作业执行方式，还是不？我想听听你的意见！如果需要更多信息，请告诉我！

Answer 1

如果您可以选择如何触发作业，我会考虑使用 Service Bus 而不是逻辑应用来处理链接。您可以在同一总线中使用不同的队列来处理调用 Web Job 的不同部分，并且您要传递的参数可以在消息中而不是 http 参数中完成。这里的主要优点是它包含重试逻辑。如果作业失败，消息将返回到队列以再次运行。您可以将其配置为在将消息移动到死信队列之前重试特定次数（默认为 10）。如果你想在 Web Job 之外做一些控制流，你可以让 Logic App 发挥作用：Web Job => Logic App => Service Bus => back to Web Job。

如果您只希望一次运行一个服务副本，那么您确实需要坚持使用 Web Jobs，但您可能需要查看Azure Functions。它们旨在完成此类小型工作，并且可以在内部与逻辑应用程序或服务总线链接在一起。它建立在 Web Jobs SDK 之上，因此在大多数情况下，代码更改很少。我不能肯定地说，因为我没有看到你的代码，但你很可能会将每个作业拆分为单独的函数而不是使用参数。