使用Azure Service Fabric构建微服务的权衡和最佳实践

Question

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

此类Service Fabric项目的一般权衡和最佳做法是：

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

2. 在单个服务中使用一个与多个角色？每个服务有多个actor的时候有用吗？

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

我知道这些决定是基于具体项目的。但也许上述三点有一般的优点和缺点。

Answer 1

Simon Houlton在他的回答中很好地讨论了微服务之间的权衡，所以这里有一些专门针对您的Service Fabric问题的答案：

1. 应用程序是服务的分组构造。理论上，通过协同工作来生成一组内聚功能或实现单个业务目标的服务通常会分组到一个应用程序中。在实践中：

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

2. 通常，服务是一个actor type 的多个实例的主机。换句话说，您通常将一个actor type 映射到一个服务类型。然后，您可以在服务中实例化该actor类型的多个实例。

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

Answer 2

对于彼此之间的不同选项进行权衡是一个棘手的问题，因为它们不一定是相互排斥的，但是这里有一些关于你提到的点的开始，我也知道这不一定是你的服务结构问题，但我希望它仍然有用。

从代码角度来看，微服务环境非常棒，它使开发人员生活更轻松。通过将功能集中到一个服务，这意味着他们可以专注于问题而不必考虑不必要的依赖性。例如，如果您要将所有方法分组到一个项目中，并且必须更改界面，则可以决定创建新的终点。在这个例子中，你可能不得不考虑那些没有改变的方法的消费者，我们是想强迫它们提升还是我们很高兴他们指向以前的版本，但当然你支持多个版本。< / p>

最大的问题是微服务培养孤立的知识，并采取一种服务的开发者不需要知道消费者是谁或什么消费的方法，这意味着你无法回答什么往往是一个非常重要的问题。谁或什么消费这项服务，我们需要迫使他们提升到一个新的终点。实际上，这可能会使您的Web服务器陷入一些混乱，旧服务无需敲门。

独立于您的解决方案，我总是尝试将您的逻辑分组，并在同一个项目中放置类似的方法。我认为你必须接受你在没有完全了解解决方案将来如何发展的情况下做出决定，因此你可能不得不改变现状。

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

有状态的网络服务可能很难快速测试，不可否认你可以解决这个问题，但我总是喜欢能够提出服务请求并得到回复，如果我必须做好准备就会让我放慢速度，这可能令人沮丧在诊断实时问题时。