验证和处理上传的Excel文件 - WebJob Vs服务结构MicroService

Question

我有一个用户案例，用户通过ASP.NET MVC 5网站或Windows应用商店应用上传Excel文件。该文件包含一个电子商务产品列表。这个文件需要首先验证正确的格式，数据的准确性等...验证完成后，需要读取日期并发送一条消息，如AddProducts，它会生成所有要添加的产品的事件。这个应用程序使用AR + E，所以必须记录在天青表存储所有事件。非功能性要求是，可能有成千上万的人将文件从网络或商店应用上传到他们的在线商店。这些请求需要逐一处理，如果处理成功，将通过SignalR立即通知用户。

看着像Azure的辅助角色，WebJobs等... WebJob可能是一个合适的，但它绑在Web角色进行思考服务织物微服务的几个选项。此服务/作业必须根据来自ASP.NET MVC5站点以及Windows应用商店应用程序的请求进行扩展。当WebJob被使用时，它可以根据我理解的网站角色进行扩展。

可否使用服务织物服务从单一服务结束点（1）与像/产物的文件中的POST操作一个REST终点/上传（2）另一端点实现所有的这些（3）每隔30秒检查一次从Azure存储队列上传的请求，并启动文件验证和处理（4）验证和处理文件？您可能会注意到，此服务应具有REST端点，对队列的访问权，以及利用CPU和IO操作的后台作业运行器。

Answer 1

您可以使用Service Fabric对此进行任意数量的建模。如果您习惯了具有外部状态存储的无状态工作者（Azure队列，表存储等），那么您可以通过添加更多像工作角色一样的实例来实现并扩展。服务结构允许您编写无状态服务，这些服务只是可以托管HTTP端点，运行处理作业或任何工作负载的通用服务。如果您不想以任何不同的方式考虑问题，那么这非常直接，除非服务不是由虚拟机角色定义的，所以如果需要，您可以在少量虚拟机上放置大量服务。

服务织物还具有状态服务，你其实有你的状态 - 队列和表 - 共同位于代码中的服务（我们将其高可用性和持续的你）里面。在这种情况下，您可以消除外部状态存储依赖关系。在这种情况下，您的比例也会有所不同：而不是增加无状态工作者的数量，分区有状态服务并将分区分布到多台计算机以增加容量。这种方法的不同之处在于，您的州商店与您一起扩展规模，因此它们不会成为瓶颈和单点故障。您还拥有队列和数据存储之间本地读取和事务操作的好处，这是您无法获得的其他功能。

下面就来看看这款机型从传统的3层系统的不同之处：https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-scenarios/

当然，你可以设置HTTP端点使用Web API为您的入口点的用户，让他们与你的服务进行通信使用您习惯的相同POST操作。

希望有所帮助。