Eureka在Cloud Foundry / PaaS环境中的价值？

Question

我们正在开发一个部署在Cloud Foundry中的云原生应用程序，在最初“让我们使用Netflix的所有好东西”之后，我们开始质疑与CF的重叠是否证明使用Netflix组件是合理的。

特别是在 Eureka 的情况下，我们计划将其用于服务发现，但CF和路由提供了非常类似的功能。我们想念的是服务的运行时注册（如果体系结构不经常变化不是一个很大的挑战，实际上是serviceID的静态映射 - > CF路由）和心跳（在应用程序级别，因为我假设在容器级别CF确保一切都很好。

所以现在我想知道 - 在使用CF时如何在应用程序（真实应用程序）中使用它？将其保留在架构中有什么好处？

谢谢，

莱谢克

PS。 有趣的是，如果eureka存储了简单的serviceID地图 - > CF路线，如果我是对的，Zuul的价值也会下降（因为LB将由CF和gorouter交付是一个非常好的选择）。

Answer 1

Eureka使用应用程序ID进行服务发现，该服务发现仅存在于应用程序设计的上下文中。 Cloud Foundry路由使用URL进行寻址，这会在底层基础架构的代码中引入依赖关系。

如果我需要访问account-service，我想以此名称提出要求。根据我是在本地计算机上测试，运行已部署的QA实例还是在生产中运行，该服务的URL将有所不同。我不希望我的应用程序必须知道它在哪里运行，以及哪些URL映射到哪个环境。无论如何，这些网址可能会随着时间的推移而发生变化。

如果我使用Eureka，那么我只要求account-service，并且从我的应用程序中抽象出特定于环境的问题。

Answer 2

对于云代工厂，我们也觉得使用尤里卡可能是一种过度杀伤力。 但我们做了一件事来外化和标记服务的名称。我们最初需要Spring配置服务来管理配置，但我们觉得它可以用作服务url map的中心源。 （必须编写自定义代码以从中央数据源加载）。

我们使用自定义数据存储创建了一个Spring配置服务，其中包含许多内容，例如密码，服务URL等。 使用cups我们连接到Spring配置服务，配置模板包含一组令牌，然后可以动态转换为服务URL。

我们最初需要Spring配置服务来管理配置，但我们觉得它可以用作服务URL的中心源（必须编写自定义代码以从数据源加载）。

Cloud Foundry没有ip和端口，因此无需跟踪单个实例的运行状况检查以进行负载平衡。 CF在内部开箱即用。  所以你需要的是一个中心数据源来映射我们的host.domain名称和key / tokens。 例如。 membership.v1 = https://membership-1-0-2

但是，如果您希望单个事务命中CF以便能够调用托管在多个数据中心的服务，那么您将需要eureka或consul.io来克服这一点。 CF群集不跨越数据中心。