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

目前，我们将应用程序部署到 Pivotal Cloud Foundry (PCF)，它以平台即服务 (PaaS) 模型运行。

这意味着每当我们将应用程序部署到 PCF 时，PCF 会自动（除了它执行的其他操作）设置一个负载均衡器，将请求转发到它自动配置的所需数量的实例。

考虑到这一点，是否可以在 PaaS 云中使用诸如 Ribbon 之类的客户端负载均衡器，这样您的应用程序的客户端将直接访问运行您的应用程序的实例，而不是负载均衡器？如果是，有什么好处？

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

标签： cloudmicroservicesnetflix-eurekacloud-foundrynetflix-ribbon

考虑到这一点，是否可以在 PaaS 云中使用诸如 Ribbon 之类的客户端负载均衡器，这样您的应用程序的客户端将直接访问运行您的应用程序的实例，而不是负载均衡器？如果是，有什么好处？

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

如果您使用客户端负载均衡器和 Cloud Foundry 的容器到容器网络，您会看到更多好处。通过 C2C，您可以直接与其他应用程序对话。在这种情况下需要注册表，因此您可以找到您的服务应用程序。

这篇博文介绍了一个使用 SCS 和 C2C 的基本示例（它适用于 PWS，但应该适用于任何具有 C2C 的 PCF 环境）。

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

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

当您开始获得大量服务时，其中“lots”是一个任意大的数字，这将变得难以管理。当您达到这一点时，使用服务注册表将使生活更轻松。并不是说您不能在一个应用程序/一个服务场景中使用服务注册表，它可能没有那么大的优势。

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

值得一提的是，如果您使用的是最新版本的 CF，则实际上有平台通过 DNS 提供服务发现。如果可用，这也可用于定位您的服务实例。有关详细信息，请参见此处。