Cloud Foundry 服务与应用答案

【问题标题】：Cloud Foundry service vs appCloud Foundry 服务与应用
【发布时间】：2017-01-02 12:48:02
【问题描述】：

Cloud Foundry 中service/user provided service 和apps 的概念有什么区别？毕竟都暴露了网址

那么建议什么时候创建服务，什么时候创建应用呢？

【问题讨论】：

许多服务会公开 URL，但并不要求它们这样做。服务可以将凭据和连接值公开为离散值，例如主机、端口、用户名和密码，而不是 URL。或者服务可能根本不提供连接详细信息或凭据（例如，仅提供资源的不可绑定服务）。

【解决方案1】：

app 位于堆栈顶部，通常具有用户界面。它使用服务（建立在服务之上）。 Cloud Foundry 应用程序通常在浏览器中运行，并可通过 URL 访问。有apps that have no route（不可访问的网址）。

service 提供消耗性功能。它还有一个 URL，以便应用程序或其他服务可以访问它。典型的服务是数据库或机器人/对话/对话服务、地图或某些登录/密码服务。

为了让它更有趣，有些服务会封装一个应用并让应用的功能可以通过 URL 访问。我建议阅读Cloud Foundry overview 或Bluemix overview。您可能还想查看一些示例 here 或 here，这些示例演示了应用程序是如何基于服务构建的。

回答关于何时构建服务或应用程序的部分：
- 功能是否适合最终用户？它有用户界面吗？ => 应用程序
- 它会被其他应用程序或服务使用吗？ => 服务

【讨论】：

谢谢 1+ 没有可访问 URL 的应用程序的用例是什么？
in addtion 由于应用程序的范围是空间，那么空间 1 的服务呢？服务 - 如果我在开发空间中实现服务（使用服务代理 api），它在 qa 空间 2 中是否可见。用户提供的服务——同样的问题，谢谢
我添加了“无路线”部分的链接。那可能是守护程序应用程序，在后台运行的应用程序。为您的后续问题打开另一个主题。
我还要补充一点，服务通常具有某种持久状态或数据。例如，MySQL 数据库存储您的数据。 CF 中的应用程序没有或不应该具有持久状态。他们应该绑定一个服务并使用它来持久化他们的数据。

【解决方案2】：

考虑这一点的一种方法是从依赖关系的角度来看待它：

应用程序通常依赖于数据库或第三方 SaaS 提供商等服务。当开发人员提供服务并将其绑定到应用程序时，该服务的服务代理负责提供服务实例。

来源：https://docs.cloudfoundry.org/concepts/architecture/#services

另一方面，服务往往不依赖于应用程序。

【讨论】：

谢谢 1+，由于应用程序的范围是空间，那么空间 1 的服务呢？服务 - 如果我在开发空间中实现服务（使用服务代理 api），它在 qa/空间 2 中是否可见。用户提供的服务 - 相同的问题
我不确定答案 - 可能值得发布一个关于此的新问题。