8

我想构建一个基于 Azure Service Fabric 的微服务应用程序。对于一些有状态的服务或参与者，我想通过 web api 从外部访问状态。

此类 Service Fabric 项目在以下方面的一般权衡和最佳实践是什么：

  1. 在单个应用程序中使用一个与多个服务？因此，如果我每个应用程序使用一项服务，我的项目将有多个应用程序。每个应用程序使用一项服务何时有用？

  2. 在单个服务中使用一个与多个参与者？每个服务有多于一个演员什么时候有用？

  3. 为整个项目使用一个无状态 Web api 服务与为每个有状态服务或每个应用程序使用多个无状态 Web 服务？

我知道这些决定是基于特定项目的。但也许以上三点存在普遍的优点和缺点。

4

2 回答 2

5

Simon Houlton 在他的回答中很好地涵盖了围绕微服务的权衡，因此这里有一些专门针对您的 Service Fabric 问题的答案：

  1. 应用程序是服务的分组结构。理论上，协同工作以产生一组有凝聚力的功能或完成单个业务目标的服务通常被分组到一个应用程序中。在实践中：

    • 升级应用于应用程序级别。通常需要一起升级的服务应该在同一个应用程序中。但是您仍然可以单独升级应用程序中的服务。
    • 运行状况在应用程序级别汇总，因此您可以获得应用程序内服务的全面运行状况概览。
    • Visual Studio 工具使使用具有多个服务的应用程序变得非常容易。

  2. 通常一个服务承载一个actor类型的多个实例。换句话说，您通常将一种参与者类型映射到一种服务类型。然后，您可以在服务中实例化该参与者类型的多个实例。

  3. 取决于你在这里真正想要什么。无状态服务在做什么？如果您需要为您的用户提供一个入口点，那么您应该为整个项目提供一个无状态 Web api。这很标准。也许你有第二个无状态服务监听不同的端口，只是为了管理员或其他东西。如果每个有状态服务都有一个无状态 Web api 服务，那么您必须担心将用户路由到正确的无状态服务。
于 2016-01-07T01:10:30.840 回答
4

在不同的选项之间进行权衡是一个棘手的问题，因为它们不一定是相互排斥的，但这里有一些关于你提到的一些观点的开始，我也知道这不一定能解决你的 Service Fabric 问题，但我我希望它仍然有用。

从代码的角度来看，微服务环境很棒，它使开发人员的生活变得轻松。通过将功能集中到一项服务，这意味着他们可以专注于问题而不考虑不必要的依赖关系。例如，如果您要将所有方法分组到一个项目中，并且您必须更改接口，您可能会决定创建一个新的端点。在此示例中，您可能必须考虑未更改的方法的使用者，我们是否要强制他们提升或者我们很高兴他们指向以前的版本，但当然您支持多个版本。

最大的问题是微服务滋生了孤立的知识，并且通过采用一种服务的开发人员不需要知道谁或什么正在使用它的方法，这意味着你无法回答什么通常可能是一个非常重要的问题，即谁或什么正在使用这项服务，我们是否需要强迫他们提升到一个新的终点。实际上，这可能会使您的 Web 服务器陷入一些不必要的旧服务的混乱。

无论您的解决方案是什么，我都会尝试对您的逻辑进行分组，并将类似的方法放在同一个项目中。我认为您必须接受您在不完全了解解决方案将来如何发展的情况下做出决定，因此您可能不得不改组。

另一个考虑因素是需求管理和并行开发。使用微服务，您可能比使用单一服务更容易管理业务需求。假设您收到 10 个要求，并被要求在下个月交付 5 个，下个月交付另外 5 个。例如，前 5 个需求集中在业务逻辑 a 中，下一个集中在业务逻辑 b 中，如果您有两个开发人员，您可以让他们并行处理此问题，而无需分支和合并。这显然是一个很好的例子来说明这一点，但是如果它们被拆分到不同的服务上，这是一个相对容易的对话，因为很容易向业务窥视者说您的业务逻辑 A 更改需要一起进行。

有状态的 web 服务可能很难快速测试，诚然你可以解决这个问题，但我总是喜欢能够向服务发出请求并得到响应，如果我必须准备一些东西，它会减慢我的速度，这在实时诊断时可能会令人沮丧问题。

于 2016-01-04T15:55:33.500 回答