我正在设计我的服务架构集群。我在创建一个应用程序和托管内部所有服务与创建每个服务1个应用程序之间。 我没有找到明确的指导方针。我看到每个服务1个应用程序的主要优点是我们可以独立部署每个服务，因为它有自己的应用程序。我们也可以在不同的回购中托管代码。这有什么缺点吗？
答案 0 :(得分：5)
更好的方法是每套服务都有一个应用程序，其中服务提供了一致的功能。应用程序应该是与其功能相关的n个服务的保护伞，例如它们可以在相同的有界上下文中或者与公共操作单元相关。但是，这并不意味着必须一致地部署/更新它们。
如果您不使用DefaultServices构造，可以在ApplicationType中独立部署服务。您可以阅读有关在生产here中应该避免默认服务的原因 - 基本上它们会创建严格的部署策略，并且您将失去通过PowerShell提供的Service Fabric参数化的一些功能。
应用程序的概念似乎与微服务架构不一致，但请记住它只是一个逻辑分组，应用程序中的单个服务仍然可以独立部署。
Application Model文档中的大量有用信息。
答案 1 :(得分：1)
我看到每个服务1个应用程序的主要优点是我们可以独立部署每个服务，因为它有自己的应用程序。
您还可以在同一应用程序中部署\升级单个服务，而不会影响其他已部署的服务。请检查差异包装here和here
我们也可以在不同的repos中托管代码
通常，当我们将代码拆分为单独的存储库时，因为我们有一个域边界，我们不想跟踪其他服务，例如，不同团队拥有的服务或按不同的时间表部署，在这种情况下会使将它们作为单独的应用程序的意义。
这有缺点吗？
从技术上讲，没有。但是你必须记住一些可能的要点。
当我们谈论微服务时，我们将它们看作是独立运行的独立服务，尽可能少依赖其他服务，当我们谈论应用程序时，我们有点违背这个“法律”，因为我们必须将它们一起部署，我们不应该以这种方式看待应用程序，因为应用程序只是这些服务的逻辑隔离，因此SF应用程序的优势在哪里？
如果您部署了多个服务（相互依赖或不相关），您需要一种方法来将它们作为一个更大的单位进行跟踪，否则您可能会以：
结束SF应用程序的工作方式就像是这些服务的快照，因此，例如，每当新服务更新时，您还要升级应用程序以引用服务及其依赖项的新定义，这将告诉SF“这就是我的方式希望我的服务运行“和SF将设法完全按照你的描述获得它们。这并不意味着您需要在需要升级时更新所有这些内容，如果必须，SF将执行更新，但您只能更新已更改的应用程序，并且他们部署应用程序的一个版本，SF将管理每个版本的版本为您服务。类似地，它就像一个docker compose文件，您可以在其中指定必须作为单个部署部署的容器。
鉴于此，当您选择退出应用程序概念时，您将失去这些优势，因为现在您必须自己管理每个服务并跟踪它们所依赖的版本，以及在不同应用程序中的两个服务的情况下需要一起部署（例如，由于更改中的更改），如果其中一个失败，您将无法轻松回滚，因为它们不再相互依赖，因此您必须编写自己的逻辑来处理此问题。
您可能会遇到的典型情况是服务的新版本更新而其他版本未在同一版本上更新可能会停止工作，但对于您的部署，新服务看起来没问题，没有任何错误。
因此，最后，只是权衡，您选择更灵活地部署服务，但最终需要更多维护。