PaaS云上的客户端负载平衡(Ribbon)和服务发现(Eureka)

Question

目前，我们将应用程序部署到关键云创建(PCF)，它在平台即服务( Platform，PaaS)模型中运行。

这意味着每当我们将应用程序部署到PCF时，PCF就会自动(除了它所做的其他操作之外)设置一个负载均衡器转发请求，将请求转发到它自动提供的实例数量。

考虑到这一点，是否有可能使用客户端负载均衡器(如PaaS云中的Ribbon )，以便您的应用程序的客户端能够直接接触到运行应用程序的实例，而不是负载平衡器？如果是的话，有什么好处？

另一个相关的问题是，如果我的所有服务都遵循相同的命名约定，例如myapp-service，因此在https://myapp-service.cfapps.io下可用，那么在PaaS云中设置服务发现服务(例如Eureka)有什么好处吗？

Answer 1

考虑到这一点，是否有可能使用客户端负载均衡器(如PaaS云中的Ribbon )，以便您的应用程序的客户端能够直接接触到运行应用程序的实例，而不是负载平衡器？如果是的话，有什么好处？

你当然可以。如果您正在使用映射到PCF上的应用程序的路径，您将只需要一个客户端负载均衡器，其中包含一个服务器，因此它并没有真正增加任何好处。

如果您使用客户端负载均衡器和Cloud的Container来进行容器网络，您会看到更多的好处。使用C2C，您可以直接与其他应用程序对话。在这种情况下，注册中心是必需的，因此您可以定位您的服务应用程序。

这篇博客文章介绍了一个使用SCS & C2C的基本示例(它适用于PWS，但应该在任何C2C环境下工作)。

https://content.pivotal.io/blog/building-spring-microservices-with-cloud-foundrys-new-container-networking-stack

还有一个相关的问题，如果我的所有服务都遵循相同的命名约定，例如myapp-服务，因此在https://myapp-service.cfapps.io下是可用的，那么在PaaS云中设置服务发现服务(例如Eureka)有什么好处吗？

我想问题是你的应用是如何找到myapp-service.cfapps.io的？如果您有一个应用程序正在使用一个服务，那么使用URL配置应用程序或者通过env变量甚至用户提供绑定服务也不难。问题解决了。

当你开始获得大量的服务时，“批次”是一个任意大的数字，这将是一个痛苦的管理。当您到达这个点时，使用服务注册中心将使生活变得更容易。并不是说您不能在一个应用程序/一个服务场景中使用服务注册中心，它可能没有那么大的优势。

使用服务注册中心的另一个优点是使用C2C网络，正如我前面提到的。在这种情况下，您需要一些东西来定位容器网络上的服务。SCS注册中心将这样做。

值得注意的是，如果您使用的是CF的最新版本，实际上存在通过DNS提供的平台服务发现。如果可用，这也可以用来定位您的服务实例。详情见这里。

https://www.cloudfoundry.org/blog/polyglot-service-discovery-container-networking-cloud-foundry/