在Service Fabric中，每个服务都有一个应用程序。

Question

我正在设计我的Service Fabric集群。我在创建一个应用程序并将所有服务放在其中与为每个服务创建一个应用程序之间犹豫不决。

我没有找到明确的指南。我认为为每个服务创建一个应用程序的主要优点是，由于它拥有自己的应用程序，我们可以独立部署每个服务。我们还可以将代码托管在不同的存储库中。这种方法是否存在缺点？

- George Moussa

Answer 1

更好的方法是针对一组提供协同功能的服务拥有一个应用程序。一个应用程序应该是n个相关功能的服务的总称，例如它们可能在相同的界限上下文中或者与共同的操作单元相关联。然而，这并不意味着它们必须同时部署/更新。

如果您不使用DefaultServices结构，可以在ApplicationType中独立部署服务。您可以在此处阅读有关为什么应避免在生产环境中使用Default Services的原因-基本上它们创建了一种严格的部署策略，而您失去了通过PowerShell可用的Service Fabric参数化的一些功能。

应用程序的概念可能似乎与微服务架构不符，但请记住，它只是一个逻辑分组，应用程序中的单个服务仍然可以独立部署。 应用程序模型文档中包含了许多有用的信息。

- KnowHoper

Answer 2

我认为每个服务拥有自己的应用程序的主要优点在于，我们可以独立部署每个服务，因为它有自己的应用程序。

您还可以在同一应用程序中部署和升级单个服务，而不会影响其他已部署的服务。请查看关于差分打包的信息 here 和 here。

我们还可以在不同的存储库中托管代码。

通常，当我们将代码拆分为单独的存储库时，是因为我们有一个域边界，我们不想与其他服务一起跟踪，例如，由不同团队拥有或在不同时间表上部署的服务，在这种情况下将它们作为单独的应用程序是有意义的。

从技术上讲，没有缺点。但是有一些可能要记住的问题。

当我们谈论微服务时，我们将它们视为独立的服务，尽可能少地依赖其他服务运行。但是，当我们谈论应用程序时，我们有点违反了这个“规律”，因为我们必须一起部署它们。我们不应该这样看待应用程序，因为应用程序只是这些服务的逻辑隔离，那么在SF应用程序中的好处在哪里呢？

当您部署多个服务（相互依赖或不相互依赖）时，您需要一种方法将它们作为更大的单位进行跟踪，否则您可能会遇到以下问题：

- 一个由服务组成的集群，有时不再需要，只是因为我们“可能会使用它们”或某人忘记在同行过时时删除它们。 - 缺少依赖服务的新部署 - 服务版本彼此不兼容（合同、API等）

SF应用程序类似于这些服务的快照，因此例如，每当一个新服务得到更新时，您也会升级应用程序以引用您的服务及其依赖项的新定义，这将告诉SF“这是我想要我的服务运行的方式”，并且SF会按照您的描述精确地管理它们。这并不意味着在需要升级时您必须更新所有服务，如果必须，SF会这样做，但您可以仅更新已更改的服务，然后部署应用程序的版本，SF将为您管理每个服务的版本。类比一下，就像一个Docker组成文件，您可以将要部署的容器指定为单个部署。

鉴于此，当您选择退出应用程序概念时，您将失去这些好处，因为现在您必须单独管理每个服务并跟踪它们所依赖的版本，在两个服务需要一起部署（例如由于重大更改）的情况下，如果其中一个失败，您将无法轻松回滚，因为它们不再相互依赖，因此您必须编写自己的逻辑来处理此问题。

您可能会遇到的典型情况是，某个服务的新版本得到更新，而同一发布中未更新的其他服务可能停止工作，但对于您的部署，新服务看起来没有任何错误。

因此，最终只是一种权衡，您选择更灵活地部署服务，但最终需要更多的维护工作。

- Diego Mendes