在云代工厂中，所有应用都可通过云代工厂负载均衡器访问。 每个负载均衡器都有一个URL来调用应用程序。 即使有隐藏的方式（例如X-CF-APP-INSTANCE）， 它并不意味着直接调用应用程序实例。
Eureka具有高可用性和分区容错性，但缺乏一致性（CAP定理）。 为了克服注册表数据的陈旧性，Netflix使用客户端负载平衡（功能区）。 （见：https://github.com/Netflix/eureka/wiki/Eureka-2.0-Architecture-Overview）
因为云代工厂中的应用程序是通过其负载均衡器调用的，所以它会自动注册 Eureka负载均衡器的地址。如前所述，app实例甚至没有地址。 为了使其更加明显，让我们说有两个应用程序A（a1和a2）的实例在Eureka注册。 Eureka现在有两个应用程序A的条目，但都分配了相同的地址。
现在当Ribbon发生以克服Eureka的一致性问题时，重试很可能是针对与第一次尝试相同的实例。 因此，使用Ribbon进行故障转移不适用于云代工厂中的Eureka。
将应用程序的所有实例分配到Eureka中的同一地址这一事实在许多情况下使事情变得复杂。 即使是Eureka的复制我们也可以通过解决方法来解决。涡轮机需要以推动模式等进给。
我们正在考虑增强Eureka，以便设置X-CF-APP-INSTANCE标头。 在此之前，我们想知道是否有人知道让Eureka真正在云代工厂工作的更简单方法吗？
答案 0 :(得分：0)
我认为Eureka和其他任何发现服务在CloudFoundry这样的PaaS中都没有地位。尽管增强Eureka以支持X-CF-APP-INSTANCE标头听起来很吸引人，但是您还需要增强客户端部分（Ribbon）以利用该信息，并将该标头添加到每个请求中。
嗯，这是9个月后，也许您在此期间做了？还是您选择了替代解决方案？
无论如何，与此同时，应用集成中还有一个附加的应用container to container networking。甚至在这里，CloudFoundry开发团队也决定提供自己的discovery mechanism。