目前，我们将我们的应用程序部署到Pivotal Cloud Foundry（PCF），后者以平台即服务（PaaS）模式运行。
这意味着每当我们将应用程序部署到PCF时，PCF会自动（除了它执行的其他操作之外）设置负载均衡器，将请求转发到它自动配置的所需数量的实例。
考虑到这一点，是否可以在PaaS云中使用功能区等客户端负载均衡器，以便应用的客户端直接与运行应用程序的实例联系，而不是负载平衡器？如果是，有什么好处？
另一个相关问题，如果我的所有服务都遵循相同的命名约定，例如myapp-service因此可以在https://myapp-service.cfapps.io下获得在PaaS云中设置服务发现服务（例如Eureka）有什么好处吗？
答案 0 :(得分：3)
考虑到这一点，是否可以在PaaS云中使用功能区等客户端负载均衡器，以便应用的客户端直接与运行应用程序的实例联系，而不是负载平衡器？如果是，有什么好处？
你当然可以。如果你在PCF上使用映射到你的应用程序的路线，你只需要一个客户端负载均衡器，其中包含一个服务器，因此它并没有真正增加任何好处。
如果您使用客户端负载均衡器和Cloud Foundry的Container to Container网络，您将看到更多好处。使用C2C，您可以直接与其他应用交谈。在这种情况下需要注册表，以便您可以找到您的服务应用程序。
此博客文章介绍了使用SCS＆amp; amp; C2C（它适用于PWS，但应该适用于任何带有C2C的PCF环境）。
另一个相关问题，如果我的所有服务都遵循相同的命名约定，例如myapp-service因此可以在https://myapp-service.cfapps.io下获得在PaaS云中设置服务发现服务（例如Eureka）有什么好处吗？
我认为问题是您的应用如何找到myapp-service.cfapps.io？如果您有一个应用程序使用一个服务，那么使用URL配置应用程序或者通过env变量甚至用户提供的绑定服务传递它并不困难。问题解决了。
当你开始获得大量服务时，＆＃34;很多＆＃34;是一个任意大的数字，这是一个痛苦的管理。当您达到这一点时，使用服务注册表将使生活更轻松。并不是说你不能在一个app / one服务场景中使用服务注册表，它可能没有那么大的优势。
使用服务注册表的另一个好处是使用C2C网络，如上所述。在这种情况下，您需要一些东西来在容器网络上找到您的服务。 SCS注册表将这样做。
对于它的价值，如果您使用最新版本的CF，实际上通过DNS提供平台提供的服务发现。如果可用，这也可用于查找服务实例。有关详细信息，请参阅此处。
https://www.cloudfoundry.org/blog/polyglot-service-discovery-container-networking-cloud-foundry/