azure - 如何设计 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 作业)、内部员工的后端仪表板(ASP.NET MVC)等。所以如果我不这样做不保持业务层相同，我必须为 Web 作业和后端仪表板再次编写相同的业务逻辑，我觉得这不是一个好主意。由于业务逻辑的简单更改将需要在多个位置更改代码。

还有一个问题是，在这种情况下，我必须使用服务到服务通信来进行 ACID 事务。例如，在创建订单时，必须同时创建订单和发票。因此，在这种情况下，我想到使用事件驱动编程，即订单服务将发出发票服务可以订阅的事件，以便在创建订单时创建发票。但复杂的是，如果发票服务无法创建发票，它可以继续尝试无限地这样做(我认为这是一个坏主意)，或者向订单服务发出另一个事件来订阅并回滚订单。这可能会引起很多困惑。

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

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

1. 您认为我的方法存在什么问题？可以吗？
2. 如果没有，请建议我更好的方法。您也可以指导我获取一些资源以获取实现细节或概念细节。

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

我很乐意学习。因为这是我第一次尝试设计微服务架构。

Answer 1

首先，为什么客户想要使用 Service Fabric 和微服务架构，同时听起来解决方案的其他部分(webjobs 等)不会被使用是塔尔架构的一部分，而是生活在它自己的生态系统中(但共享逻辑)？我认为首先了解指导架构的基本需求对您来说是有好处的。最重要的是什么？

• 可扩展性？灵 active ？
• 开发和部署？可维护性？
• 是否能够实现基于自主微服务构建新解决方案的模块化？

这样的例子还可以继续列下去。在你弄清楚这一点之前，进一步设计确实没有意义，因为你不知道你正在设计什么...

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