【发布时间】：2017-07-09 01:06:32
【问题描述】：
Service Fabric 中应用程序概念背后的原因是什么？应用程序和服务之间的推荐关系是什么？应用程序在哪些场景中被证明是有用的？
【问题讨论】：
-
Azure API 应用与众不同
标签： azure microservices azure-service-fabric
【发布时间】：2017-07-09 01:06:32
【问题描述】：
这是一个很好的总结逻辑服务与物理服务的区别：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 服务
【讨论】：
-
如果您开发 LOB 应用程序，我可能会为每个域创建一个应用程序并在其中包含多个微服务。因此，如何将事物分解为应用程序和服务还取决于您正在创建的解决方案的类型。
-
“因此，如何将事物分解为应用程序和服务还取决于您正在创建的解决方案的类型。” - 同意
应用程序是服务的必需顶级容器。您部署应用程序，而不是服务。因此，您不能真正谈论两者之间的区别，因为没有应用程序就无法提供服务。
来自https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-model：
应用程序是执行特定功能的组成服务的集合。服务执行完整的独立功能（它可以独立于其他服务启动和运行），由代码、配置和数据组成。对于每个服务，代码由可执行的二进制文件组成，配置由可以在运行时加载的服务设置组成，数据由服务使用的任意静态数据组成。此分层应用程序模型中的每个组件都可以独立进行版本控制和升级。
查看提供的链接，您将看到层次关系。
【讨论】：
-
“没有应用程序就无法获得服务。” - 并没有真正说明您为什么需要这些应用程序，或者为什么将它们引入服务结构。 “你部署的是应用程序，而不是服务。” - 技术上是的，但本质上因为服务是独立版本的，你为什么需要一个应用程序？附言我在对这个问题的回答中发表了我对这个主题的看法。
-
好吧，你已经问了三个问题。第一个很难回答，但在我看来，我的回答解决了第二个和第三个问题：由于应用程序是强制性的，因此关系由该要求定义，并且必须使用“证明”它们为什么有用的应用程序来部署服务。您的回答并没有解决对应用程序的需求，而是像我所说的那样将服务组合在一起。