自动化Azure中的作业

Question

我对automated jobs in Azure有疑问，但在我提出问题之前，我想我会解释现有的流程。

目前，我们的每个客户都有：

1. 在其服务器上运行的Windows服务，每x秒/分钟/小时轮询第三方云服务。这个Windows服务调用他们的SDK，它传递相关的用户名＆amp;密码并调用相关的API来检查数据是否可用。如果有，它将下载相关文档及其相关元数据。

如果有多个文件可用，它将下载每个文件及其相关数据。每个文档始终都有一个与之关联的元数据文件。

1. 另一个Windows服务轮询其服务器上的特定位置，其中已下载作业（1）中的文档和元数据。这反过来又处理元数据＆amp;文件并将它们插入我们的数据库。

我们需要能够在Azure中执行相同的操作，但我们需要为将运行云（多租户）解决方案的所有客户执行此操作。

1. 以特定间隔调用作业以与作业（1）相同。它应该根据每个客户端指定的时间间隔（特定于每个客户端）检查文档/元数据是否可用。有些客户会比其他客户处理更多数据和/或有些客户要求信息比其他客户更快。

此作业不仅需要按照客户定义的特定时间间隔进行调用，还需要使用每个客户端的相关用户名和密码连接到我们的第三方云合作伙伴，该合作伙伴具有元数据＆amp;存储在其系统上的文件。

它还需要处理失败：    - 无法连接到第三方    - 无法下载文档和/或元数据。

1. 以特定间隔调用作业以与作业（2）相同。它应检查作业（1）是否已下载任何文件/数据并处理它们，即将元数据和文档插入我们的数据库。

它还需要处理失败：    - 提供缺少/无效的元数据。    - 遗失文件。    - 无法在数据库中插入数据和/或文档。

我看到这项工作的方式如下：

1. 以特定间隔连接到我们的第三方云合作伙伴的作业将在Azure中运行。它将检查是否有任何文档和元数据可用。如果有，请下载文档和元数据并将其添加到队列中。

2. 作业将轮询队列，如果队列中有任何可用内容，它将开始处理队列中的项目。

虽然每个客户端都有自己的数据库，但我们将拥有一个主数据库，它将包含我们所有客户的数据库详细信息，即连接字符串ID，连接字符串等......

问题：

1. 我们应该为每个客户提供一份工作（1），还是应该有         所有客户的一份工作（1）？如果你认为一份工作         客户是要走的路，它将如何处理独立的间隔，         用户名和＆amp;每个客户的第三方云合作伙伴的密码？         如果需要，如何缩放，如何引入第二个或         第三个工作做同样的事情，但每个工作只处理一定数量         客户。

2. 我们应该为每个客户提供一份工作（2），还是应该有         所有客户的一份工作（2）？同样，问题与1相同             关于间隔，用户名和＆amp;密码到第三方云             合作伙伴，可扩展性等......定价/成本如何？              我们应该有一个全局队列还是每个客户端应该有一个队列？如果每个客户端有一个队列，那么这是什么 需要关于价格/成本吗？

3. 由于每个客户都有自己的数据库，job（1）如何知道 需要的相关间隔，用户名和密码             连接到第三方云合作伙伴？如果工作＆＃34;循环＆＃34;             通过我们的master数据库，获取相关的连接字符串，             连接到客户端数据库并使用用户名和用户名;密码并检查他们的间隔是否已达到？
4. 我们如何知道如何在相关信息中插入相关信息 数据在队列中可用时的相关数据库。工作时     （1）已下载元数据和文档并将其添加到             如果我们还要包含将再次使用的相关连接字符串（或与此连接字符串关联的id）             获取用户名，密码和间隔，以便知道哪个             数据库插入数据？这是可以接受的还是有更好的方法来做到这一点？
5. web job和Cloud Service工作人员之间的区别是什么？ 角色？我们应该使用哪一个？
6. 我们应该使用单独的cloud service来运行这些jobs而不是。{ 在托管/运行我们的网络应用程序的同一cloud service上运行它们？

Answer 1

虽然我无法回答您的所有问题（其中很多都取决于上下文），但我可以告诉您NubiloSoft上Azure上的这类内容。它不是在网站上出售，但我们在客户项目中使用它，每天处理大量任务。

首先，我们开发了一个调度程序框架。它是一个适用于多个存储提供商的单一框架，但我会在这里坚持使用Azure。基本上，框架将作业推送到Azure Queue存储（如果元数据太多，我们使用Table存储），因为它很便宜。然后，我们在多个服务器上运行一个工作进程，这些服务器会弹出作业并处理它们。

作业（我们推送存储的东西）基本上是具有任务元的任务ID。 ID用于确定哪个类应该完成工作，meta包含运行任务所需的信息。

现在，弹出收据之类的东西需要特别小心。基本上，如果您未在规定的时间内处理作业，则需要确保延长弹出收据。如果不是（f.ex.因为服务器崩溃），允许自动重新安排作业。现在请注意，您需要特别注意错误处理：如果抛出一个导致工作线程崩溃的异常，您必须正确处理它，否则您最终会遇到崩溃的作业。此外，我们在正确记录方面做了一些工作，因为对多个作业进行故障排除可能很困难。混合表存储和队列存储时，还需要特别注意可能发生的并发问题。

总而言之，我可以说这一切都是完全正确的......

考虑到这一点，我可以回答你的问题：

  

我们是否应该为每个客户提供一份工作（1）或者我们是否应该为所有客户提供一份工作（1）？如果你认为所有客户的一份工作是要走的路，它将如何处理独立的间隔，用户名和＆amp;每个客户的第三方云合作伙伴的密码？如果需要，如何缩放，即引入第二或第三个工作来做同样的工作，但每个工作只处理一定数量的客户。

一个辅助角色是最好的，因为如果队列填满，这可以让你做更好的扩展。可以为此配置自动缩放。

对于username + pwd，对我而言，这只是工作元数据。您可以使用符合安全约束的任何操作。我可能只是尝试将它们与队列中的作业元素一起存储，可能是加密的。

  

我们是否应该为每个客户提供一份工作（2）或者我们是否应该为所有客户提供一份工作（2）？同样，关于间隔，用户名和＆amp;的问题与1相同。第三方云合作伙伴的密码，可扩展性等......

我只需要一个队列和一个角色，纯粹从可扩展性和性能角度来看。如果你有1个队列和10个工作人员，你基本上比1个角色和1个工人更多地轮询队列10次，从而获得更多的吞吐量。此外，使用这种方法可以合并成本。

  

定价/成本怎么样？我们应该有一个全局队列还是每个客户端应该有一个队列？如果每个客户一个队列，这对价格/成本有什么影响？

全局一个队列更便宜，因为它可以减少存储事务。至于成本，这一切都取决于你使用的是什么。如果您使用云/队列存储，我的经验是它与计算成本相比无关紧要。

  

由于每个客户都有自己的数据库，job（1）如何知道连接到第三方云伙伴所需的相关间隔，用户名和密码？

调度程序负责处理间隔;作业中的逻辑告诉调度程序区间是什么。除此之外别无选择。

  

Web作业和Cloud Service工作者角色之间有什么区别？我们应该使用哪一个？

Web角色用于“iis Web应用程序”，工作者角色用于“Windows服务”。在IIS中运行可能会被回收的调度程序对我来说没有多大意义。

  

我们是否应该使用单独的云服务来运行这些作业，而不是在托管/运行我们的网络应用程序的同一个云服务上运行它们？

我愿意。