【发布时间】:2018-05-27 00:58:03
【问题描述】:
在过去的 2-3 个月里,我一直在使用 Cloud Foundry,并且遇到过用户定义和托管服务。我的理解是,如果托管服务伴随着所需的实现,如果服务代理和用户定义的服务,定义服务的人必须负责实现。我想了解使用托管/用户定义的服务与在应用程序中定义连接细节(或将其外部化到属性文件中)相比有什么优势
【问题讨论】:
标签: java spring-boot cloud-foundry
在过去的 2-3 个月里,我一直在使用 Cloud Foundry,并且遇到过用户定义和托管服务。我的理解是,如果托管服务伴随着所需的实现,如果服务代理和用户定义的服务,定义服务的人必须负责实现。我想了解使用托管/用户定义的服务与在应用程序中定义连接细节(或将其外部化到属性文件中)相比有什么优势
【问题讨论】:
标签: java spring-boot cloud-foundry
我相信使用服务绑定方法的总体优势是应用程序不必为每个可能部署到的环境都有多个配置文件。
具体来说,如果您有 Dev、Test、Stage 和 Prod 环境,您可能会有一组反映每个环境的自定义 URL/IP/端口/凭据的配置。您还需要一些方法来触发使用正确的环境配置。在 Spring Boot 方法中,您通常使用 Spring Profiles 来定义和激活这些配置。但是,这通常意味着您的应用程序提前与所有必需的配置文件配置捆绑在一起。
使用 Cloud Foundry,连接/服务绑定细节是通过部署的云平台本身注入的。这意味着您只需要定义一个适用于您必须支持的所有环境的“云”配置文件。
可以说这种方法有几个好处:
您可以建立新环境,而不必重建/重新配置应用程序本身。例如,如果您对 Test2 有短期需求,您可以轻松创建和定义新的空间和服务绑定,而无需重新构建应用程序。从技术上讲,您可以通过其他方式来实现这一点——正如您通过外部化配置所建议的那样。我对 CF 的理解是,这并不是一种真正值得鼓励的做法(并且可能不容易实现,除非您将所有内容都外部化为独立的环境变量)。
您不必将凭据存储在应用程序配置中。这可以说是一种安全优势,因为应用程序开发人员永远不必知道他们绑定到本地环境之外的任何服务的连接细节。这对您来说可能重要也可能不重要。
您或许能够跨环境使用不同的支持服务实现(可能是为了避免非产品的高许可成本?)。我不喜欢这种方法,所以我真的不认为它有好处。
如果我还缺少其他潜在的好处,希望其他对 Cloud Foundry 有更多了解的人可以加入。
另外,我会更仔细地查看这个项目:http://cloud.spring.io/spring-cloud-connectors/,看看您是否可以通过这种方法获得任何额外的好处。
【讨论】: