0

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

看了几个选项，如Azure Worker 角色、WebJobs等……WebJob 可能很合适，但它与制作 Service Fabric 微服务的 Web 角色相关。此服务/作业必须根据来自 ASP.NET MVC5 站点以及来自 Windows Store 应用程序的请求进行扩展。在使用 WebJob 时，它可以根据我理解的它所附加的网站角色进行扩展。

我是否可以使用Service Fabric 服务从单个服务端点实现所有这些 (1) 具有 POST 操作的 REST 端点，例如/product-file/uploaded (2) 另一个端点，例如/product-file/checkstatus/ myExcelFileName (3) 每 30 秒检查一次从Azure 存储队列上传的请求并启动文件的验证和处理 (4) 验证和处理文件？您可能会注意到，该服务应该具有 REST 端点、对队列的访问权限、一个利用 CPU 和 IO 操作的后台作业运行器。

4

1 回答 1

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 操作与您的服务进行通信。

希望有帮助。

于 2015-06-26T05:38:21.590 回答