Service Fabric中应用程序概念背后的原因是什么？应用程序和服务之间的建议关系是什么？应用程序在哪些场景中有用？
应用程序是服务所需的顶级容器。您部署应用程序，而不是服务。所以你不能真正谈论两者之间的差异，因为没有应用程序你就无法获得服务。
来自https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-model：
应用程序是执行特定功能的组成服务的集合。服务执行完整的独立功能（它可以独立于其他服务启动和运行），并由代码，配置和数据组成。对于每个服务，代码由可执行二进制文件组成，配置包括可在运行时加载的服务设置，数据由服务使用的任意静态数据组成。此分层应用程序模型中的每个组件都可以独立进行版本控制和升级。
看一下提供的链接，您将看到层次关系。
以下是逻辑服务与物理服务的不同之处：https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/logical-versus-physical-architecture
现在，就Service Fabric而言，Service Fabric应用程序代表逻辑服务，而Service Fabric服务代表物理服务。为了简化它，Service Fabric应用程序是一个部署单元，因此您可以放置多个依赖于相同持久存储的服务或具有其他相互依赖性的服务，以便您确实需要将它们一起部署。如果您拥有完全独立的服务，则可以将它们放入不同的Service Fabric应用程序中。
应用程序是执行特定功能的组成服务的集合。服务执行完整的独立功能，可以独立于其他服务启动和运行。服务由代码，配置和数据组成。对于每个服务，代码由可执行二进制文件组成，配置包括可在运行时加载的服务设置，数据由服务使用的任意静态数据组成。此分层应用程序模型中的每个组件都可以独立进行版本控制和升级。
它详细描述了here
我目前看到它，应用程序是一个很好的概念，将多个服务组合在一起并将它们作为单个单元进行管理。在服务结构的背景下，如果您有多个纳米服务并不保证它们完全独立，这将非常有用;相反，你可以将它们一起打包成微服务（SF应用程序）。
免责声明： - 纳米服务将是一个非常小的代码片段，例如作为无状态SF服务运行（例如从队列中读取，要处理的几行代码，写入另一个队列）。 - 在“正常”微服务的情况下，可以考虑将它们打包为1 SF应用= 1 SF服务