用于 SaaS 的 Cloud Foundry

Cloud Foundry for SaaS

我正在 Cloud Foundry 上为我的 SaaS 应用程序实施服务代理。

在我的 SaaS 应用程序的创建服务上，我也创建了另一个服务（比如服务 A）的实例。另一个服务 (service-A) 的新服务实例也被创建为每一个在我的应用程序上的租户。

新创建的服务实例 (service-A) 的详细信息通过环境变量传递到我的服务代理。

为了能够处理这个新注入的环境变量，服务代理需要 restaged/restarted。

这意味着每个新入职客户的服务代理都会停机。

我有以下问题： 1) Cloud Foundry 如何处理这些用例？ 2) 为什么 Cloud Foundry 选择使用环境变量来传递使用服务所需的信息？这似乎是有限的，因为它需要重新启动应用程序。

听起来您没有以 'correct' 的方式使用服务。如果没有您的用例的更多细节，很难说清楚。例如，为什么您的经纪人需要附加这项附加服务？

回答您的问题：

1) 不是这样的。您正在使用服务绑定来表示数据，而不是将它们用作支持服务。许多服务代理（我已经写了很多）需要动态配置诸如 Cassandra 集群之类的东西，但它们会在自己的数据存储中保留一些关于哪些 Cassandra 集群属于哪些 CF 服务的状态。代理不会绑定到它负责创建的每个事物。

2) 因为 12 Factor applications should treat backing services as attached, static resources。说向运行应用程序添加新的 MySQL 数据库是不正常的。

初步猜测，您的服务可能是 API 提供给客户的某种服务。 API 必须将它发送的数据存储在某个数据库中（例如 MongoDb 或 Mysql）。所以 MongoDb 或 Mysql 就是你所说的 Service-A。

由于您希望客户的 API 端点的性能彼此独立，因此您要为每个客户（即服务的每个服务实例）配置专用数据库.

你说得对，如果要从服务代理的环境中获取这些数据库的凭据，则需要重新部署服务代理。或者至少您必须重新读取 VCAP_SERVICES 环境变量。然而还有另一种解决方案：

使用 CC-API 创建服务，并将它们绑定到您喜欢的任何应用程序。然后再次使用 CC-API 查询此应用程序的绑定。这将包括凭据。这是此端点上 API 文档的 link：