Service Fabric 中每个服务的应用程序

Question

我正在设计我的 Service Fabric 集群。我在创建一个应用程序和在内部托管所有服务与为每个服务创建 1 个应用程序之间。 我没有找到明确的指导方针。我看到每个服务 1 个应用程序的主要优势是我们可以独立部署每个服务，因为它有自己的应用程序。我们还可以将代码托管在不同的存储库中。这有缺点吗？

Answer 1

更好的方法是每组服务有一个应用程序，其中服务提供内聚功能。一个应用程序应该是 n 个在其功能上相关的服务的保护伞，例如它们可能在相同的有界上下文中或与一个共同的操作单元相关。但是，这并不意味着它们必须统一部署/更新。

如果您不再使用 DefaultServices 构造，则可以在 ApplicationType 中独立部署服务。您可以了解为什么在生产环境中应避免使用默认服务here - 本质上，它们创建了一个严格的部署策略，并且您失去了通过 PowerShell 提供的 Service Fabric 参数化的一些功能。

应用程序的概念可能看起来与微服务架构不一致，但请记住它只是一个逻辑分组，应用程序中的单个服务仍然可以独立部署。

Application Model 文档中有很多有用的信息。

Answer 2

我看到每个服务 1 个应用程序的主要优势是我们可以独立部署每个服务，因为它有自己的应用程序。

您还可以在同一应用程序中部署\升级单个服务，而不会影响其他已部署的服务。请检查差异包装here和here

我们也可以将代码托管在不同的仓库中

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

这样做有缺点吗？

从技术上讲，没有。但是您必须牢记一些可能的要点。

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

当您部署了多个服务（相互依赖或不相互依赖）时，您需要一种方法将它们作为一个更大的单元来跟踪，否则您可能会以：

• 一个充满服务的集群，这些服务有时不再需要，只是因为我们“可能正在使用它们”或者有人在他们的对等设备过时时忘记删除它们。
• 新部署缺少相关服务
• 彼此不兼容的服务版本（合同、API 等）

SF 应用程序就像这些服务的快照一样工作，例如，每当更新新服务时，您还升级应用程序以引用服务及其依赖项的新定义，这将告诉 SF “这就是我希望我的服务运行”，SF 将设法完全按照您的描述获得它们。并不意味着您必须在需要升级时更新所有这些，如果需要，SF 会这样做，但是您可以只更新已更改的那些，它们会部署您的应用程序的一个版本，SF 将管理每个版本为您服务。打个比方，它就像一个 docker compose 文件，您可以在其中指定必须作为单个部署部署的容器。

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

您可能会遇到一个典型的场景，即更新了服务的新版本而其他未在同一版本上更新的服务可能会停止工作，但对于您的部署，新服务看起来不错，没有任何错误。

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