我有一个具有多个例程的Web作业，并且为了执行特定的例程，例程的名称作为作业的参数传递。所有这些例程都必须执行，并且它们之间存在依赖关系（一个例程的输入可能是其他例程的输出）；因此，为此，我计划使用 Logic App ，该应用实际上将调用相同的Web作业，但传递不同的参数。
通过上述所有操作，我将拥有一个Web作业实例，并使用Logic App控制作业流程。 但是我担心的是... ，让我们假设我只想执行一个特定的例程（它是独立的，它不依赖于另一个例程），因为（或者也许我想调试它）失败，所以我必须进入Azure中的Web Jobs门户，并复制作业的Web钩子URL，将作业参数设置为查询参数以调用例程，然后通过HTTP客户端调用它。但是我看到的问题不是那么友好：我必须做所有这些事情才能调用特定工作的例程。
为了解决上述问题，我打算复制作业实例（此处使用的重复术语不是为了扩展，而是为了灵活性），并将例程的名称硬编码到每个作业重复中。我看到的唯一优点是，直接进入相应的作业实例即可运行特定的例程，然后单击“运行”按钮（Azure Portal）。但是，我在这里看到的缺点是我在复制相同的源代码（相同的二进制文件），但是只是传递了一个不同的参数（在本例中为例程的名称），所以就可维护性而言，这很痛苦，因为如果作业源代码中发生了一些变化，我必须重新部署“例程计数”时间以保持一致性（所有作业都在同一源代码下运行）。
所以我应该牺牲代码可维护性（多次部署相同的源代码，并使用作业参数）以获得友好的作业执行方式吗？我想听听您的意见！如果需要更多信息，请告诉我！
答案 0 :(得分：0)
如果您可以选择触发作业的方式，那么我将看一下使用Service Bus而非Logic Apps来处理链接。您可以在同一总线内使用不同的队列来处理调用Web作业的不同部分，并且要传递的参数可以在消息内完成，而不是在HTTP参数内完成。这里的主要优点是它包含重试逻辑。如果作业失败，消息将返回到队列以再次运行。您可以将其配置为在将邮件移至死信队列之前重试特定次数（默认为10）。如果您想在Web作业之外执行一些控制流程，则可以使Logic App处于活动状态：Web作业=> Logic App =>服务总线=>回到Web作业。
如果您一次只希望运行该服务的一个副本，那么您确实需要坚持使用Web Jobs，但是您可能想要查看Azure Functions。它们旨在执行此类小任务，并且可以在内部与Logic Apps或Service Bus链接在一起。它基于Web Jobs SDK构建，因此在大多数情况下，代码更改很少。我不能肯定地说，因为我还没有看到您的代码，但是很有可能您会将每个作业拆分为单独的函数，而不是使用参数。