Eureka 在 Cloud Foundry/PaaS 环境中的价值？
Value of Eureka in Cloud Foundry/PaaS environment?
我们正在开发一个将部署在 Cloud Foundry 中的云原生应用程序，在初始 "let's use all the goodies from Netflix" 之后，我们开始质疑与 CF 的重叠是否证明了使用 Netflix 组件是合理的。
特别是在 Eureka 的情况下，我们计划将其用于服务发现，但随后 CF 和路由提供了开箱即用的非常相似的功能。我们会错过的是服务的运行时注册（在不经常更改的体系结构的情况下这不是一个大挑战，实际上是 serviceID -> CF 路由的静态映射）和心跳（在应用程序级别，因为我假设在容器级别 CF 正在确保一切正常）。
所以现在我想知道 - 在使用 CF 时，您如何在您的应用程序（实际应用程序）中使用它？将它保留在架构中有什么好处？
谢谢，
莱塞克
PS。
有趣的是，如果 eureka 存储 serviceID -> CF 路由的简单映射，那么如果我是对的，Zuul 的值也会下降（因为 LB 将由 CF 交付，而 gorouter 是一个很好的选择）。
Eureka 使用应用程序 ID 进行服务发现，它仅存在于您的应用程序设计上下文中。 Cloud Foundry 路由使用 URLs 进行寻址，这会在您的代码中引入对底层基础设施的依赖。
如果我需要访问 account-service，我想用那个名字请求它。该服务的 URL 将有所不同，具体取决于我是在本地计算机上测试，运行 已部署的 QA 实例，还是在生产中 运行。我不希望我的应用必须知道它 运行 的位置，以及哪个 URL 映射到哪个环境。无论如何，这些 URL 可能会随着时间而改变。
如果我使用 Eureka，那么我只需要 account-service，并且特定于环境的问题会从我的应用程序中抽象出来。
对于 cloud foundry，我们还认为使用 eureka 可能有点矫枉过正。
但是我们做了一件事来外部化和标记化服务的名称。我们最初需要 Spring 配置服务来管理配置，但我们认为我们也可以将其用作服务 url 映射的中心源。 （必须编写自定义代码才能从中央数据源加载）。
我们使用自定义数据存储创建了一个 Spring 配置服务，其中包含许多内容，例如密码、服务 url 等。
我们使用 cups 连接到 Spring 配置服务，配置模板包含一组令牌，然后即时转换为服务 urls。
我们最初需要 Spring 配置服务来管理配置，但我们认为我们可以将其用作服务的中心源 url（必须编写自定义代码才能从数据源加载）。
Cloud foundry 没有 ip 和端口，因此无需跟踪单个实例的健康检查以进行负载平衡。 CF 在内部开箱即用地做得很好。
因此，您所需要的只是一个中央数据源，用于将我们的 host.domain 名称映射到 keys/tokens。
例如。 membership.v1=https://membership-1-0-2.
但是如果您希望单个事务命中 CF 以能够调用托管在多个数据中心的服务，那么您将需要尤里卡或 consul.io 来克服这个问题。 CF 集群不跨数据中心。
我们正在开发一个将部署在 Cloud Foundry 中的云原生应用程序，在初始 "let's use all the goodies from Netflix" 之后，我们开始质疑与 CF 的重叠是否证明了使用 Netflix 组件是合理的。
特别是在 Eureka 的情况下，我们计划将其用于服务发现，但随后 CF 和路由提供了开箱即用的非常相似的功能。我们会错过的是服务的运行时注册（在不经常更改的体系结构的情况下这不是一个大挑战，实际上是 serviceID -> CF 路由的静态映射）和心跳（在应用程序级别，因为我假设在容器级别 CF 正在确保一切正常）。
所以现在我想知道 - 在使用 CF 时，您如何在您的应用程序（实际应用程序）中使用它？将它保留在架构中有什么好处？
谢谢，
莱塞克
PS。 有趣的是，如果 eureka 存储 serviceID -> CF 路由的简单映射，那么如果我是对的，Zuul 的值也会下降（因为 LB 将由 CF 交付，而 gorouter 是一个很好的选择）。
Eureka 使用应用程序 ID 进行服务发现，它仅存在于您的应用程序设计上下文中。 Cloud Foundry 路由使用 URLs 进行寻址，这会在您的代码中引入对底层基础设施的依赖。
如果我需要访问 account-service，我想用那个名字请求它。该服务的 URL 将有所不同，具体取决于我是在本地计算机上测试，运行 已部署的 QA 实例，还是在生产中 运行。我不希望我的应用必须知道它 运行 的位置，以及哪个 URL 映射到哪个环境。无论如何，这些 URL 可能会随着时间而改变。
如果我使用 Eureka，那么我只需要 account-service，并且特定于环境的问题会从我的应用程序中抽象出来。
对于 cloud foundry，我们还认为使用 eureka 可能有点矫枉过正。 但是我们做了一件事来外部化和标记化服务的名称。我们最初需要 Spring 配置服务来管理配置，但我们认为我们也可以将其用作服务 url 映射的中心源。 （必须编写自定义代码才能从中央数据源加载）。
我们使用自定义数据存储创建了一个 Spring 配置服务，其中包含许多内容，例如密码、服务 url 等。 我们使用 cups 连接到 Spring 配置服务，配置模板包含一组令牌，然后即时转换为服务 urls。
我们最初需要 Spring 配置服务来管理配置，但我们认为我们可以将其用作服务的中心源 url（必须编写自定义代码才能从数据源加载）。
Cloud foundry 没有 ip 和端口，因此无需跟踪单个实例的健康检查以进行负载平衡。 CF 在内部开箱即用地做得很好。 因此，您所需要的只是一个中央数据源，用于将我们的 host.domain 名称映射到 keys/tokens。 例如。 membership.v1=https://membership-1-0-2.
但是如果您希望单个事务命中 CF 以能够调用托管在多个数据中心的服务，那么您将需要尤里卡或 consul.io 来克服这个问题。 CF 集群不跨数据中心。