我有一个用户案例，用户通过 ASP.NET MVC 5网站或Windows应用商店应用上传excel文件。该文件包含电子商务产品列表。此文件需要首先验证正确的格式，数据准确性等...验证完成后，需要读取日期并发送消息，如 AddProducts ，为所有人生成事件要添加的产品。此应用使用 AR + E ，因此必须记录 Azure表存储中的所有事件。非功能性要求是可能有数千人将文件从网络或商店应用程序上传到他们的在线商店。需要逐个处理请求，如果处理成功，将立即通过 SignalR 通知用户。
看了几个选项，比如 Azure Worker角色， WebJobs 等等...... WebJob可能很合适，但它与Web角色的关系很紧密。想想Service Fabric微服务。此服务/作业必须根据来自ASP.NET MVC5站点以及Windows应用商店应用程序的请求进行扩展。当使用WebJob时，它可以根据我所理解的网站角色进行扩展。
我是否可以使用 Service Fabric服务从单个服务端点实现所有这些（1）具有POST操作的REST端点，例如 / product-file / uploaded < / em>（2）另一个端点，如 / product-file / checkstatus / myExcelFileName （3）每隔30秒检查一次来自 Azure存储队列的上传请求并启动验证并处理文件（4）验证并处理文件？您可能会注意到，此服务应具有REST端点，访问队列，使用CPU和IO操作的后台作业运行器。
答案 0 :(得分：1)
您可以使用Service Fabric以任意数量的方式对此进行建模。如果您习惯于使用外部化状态存储（Azure队列，表存储等）的无状态工作者，那么您当然可以通过添加更多实例来扩展，就像使用工作者角色一样。 Service Fabric让您编写无状态服务，它们只是可以托管HTTP端点，运行处理作业或任何工作负载的通用服务。如果您不想以任何不同的方式考虑问题，这是相当简单的，除了VM角色没有定义服务，因此如果您愿意，可以在少量VM上放置大量服务。
Service Fabric还具有有状态服务，其中您实际拥有状态 - 队列和表 - 与服务中的代码共存（我们使其高度可用且持久）。在这种情况下，您可以消除外部状态存储依赖性。在这种情况下，您也可以进行不同的扩展：不是增加无状态工作者的数量，而是分区有状态服务，并将分区分布在多台计算机上以增加容量。与这种方法的不同之处在于，您的州与您存储规模，因此它们不会成为瓶颈和单点故障。您还可以享受队列和数据存储之间的本地读取和事务操作，否则您无法获得这些操作。
以下是该模型与传统3层系统的区别：https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-scenarios/
当然，您可以使用Web API设置HTTP端点作为用户的入口点，这样他们就可以使用您习惯的相同POST操作与您的服务进行通信。
希望有所帮助。