如何在 Azure Service Fabric 中设计层

Question

我被分配为 Azure Service Fabric 考虑分层微服务架构。但我的经验主要是在单体架构上，我无法提出具体的解决方案。

我现在的想法是……

数据层 - 这是所有 Code First 实体以及 DBContext 所在的位置。

业务层 - 这是所有服务经理将执行和执行业务逻辑的地方，即 UserManager (IUserManager)、OrderManager (IOrderManager)、InvoiceManager (IInvoiceManager) 等。

WebAPI（Service Fabric 内部自热）- 虽然此 WebAPI 在 Service Fabric 内部，但除了接收请求并调用 Service Fabric 下的相应服务外，什么都不做。 WebAPI 层还会在将调用传递给其他服务之前执行任何身份验证和授权（ASP.NET 身份）。

Service Fabric 服务 - UserService、OrderService、InvoiceService。这些服务从 WebAPI 层和 DI 业务层（IUserManager、IOrderManager、IInvoiceManager）调用以执行其操作。

你认为这可以继续吗？

虽然有一个理论问题，但在阅读了几个微服务架构资源时，我发现，他们都建议在服务中包含业务逻辑，以便可以独立扩展特定服务。所以我相信，我违反了微服务的基本方面。

我这样做是因为，客户要求在多个项目中使用此业务层，例如批处理作业 (Azure Web Jobs)、内部员工后端仪表板 (ASP.NET MVC) 等。所以如果我不这样做'不要保持业务层相同，我必须再次为 Web 作业和后端仪表板编写相同的业务逻辑，我觉得这不是一个好主意。由于业务逻辑的简单更改将需要在多个地方更改代码。

另一个问题是，在这种情况下，我必须使用服务到服务通信来进行 ACID 事务。例如，在创建订单时，必须同时创建订单和发票。所以在这种情况下，我想到了使用事件驱动编程，即订单服务将发出一个发票服务可以订阅的事件，以在创建订单时创建发票。但复杂性在于，如果 Invoice Service 无法创建发票，它可以继续尝试无限地执行此操作（我认为这是一个坏主意），或者向 Order Service 发出另一个事件以订阅和回滚订单。这可能会引起很多混乱。

另外，我必须提到，我们现在使用的是单一数据库。

所以我的问题是......

1. 您认为我的方法有什么问题？没事吧？
2. 如果没有，请建议我一个更好的方法。您也可以为我提供一些资源以了解实现细节或概念细节。

注意：客户的要求是，他们可以根据需要扩展特定的模块。例如，UserService 可能不会被太多使用，因为每天不会有很多注册或用户配置文件的变化，但 OrderService 可以扩展，因为每天可能会有很多订单。

我会很高兴学习。因为这是我第一次接触到设计微服务架构的机会。

Answer 1

首先，为什么客户想要同时使用 Service Fabric 和微服务架构，而同时听起来解决方案的其他部分（网络作业等）不会塔尔架构的一部分，而是生活在它自己的生态系统中（但共享逻辑）？我认为首先了解应该指导架构的底层需求对您有好处。什么是最不朽的？

• 可扩展性？灵活性？
• 开发和部署？可维护性？
• 基于自治微服务组合新解决方案的模块化能力？

列表可以继续。在你弄清楚这一点之前，进一步设计真的没有意义，因为你不知道你在设计什么...

关于与 webjobs 共享业务逻辑，没有什么能阻止你共享包含相同 BL 的代码包，它不一定是共享服务，并不意味着它必须以相同的方式打包关于它的接口或持久性。要考虑的另一件事是，当您可以在 SF 服务中构建类似的功能时，为什么不运行 webjobs？