Имея это в виду, возможно ли использовать балансировщик нагрузки на стороне клиента, такой как Ribbon, в облаке PaaS, чтобы клиенты вашего приложения обращались напрямую к экземплярам, на которых запущено ваше приложение, а не к балансировщику нагрузки? Если да, каковы преимущества?
Вы, конечно, могли бы. Если вы используете маршрут, сопоставленный с вашим приложением на PCF, у вас будет просто балансировщик нагрузки на стороне клиента с одним сервером, так что это не принесет никакой пользы.
Где вы могли бы увидеть больше преимуществ, если бы вы использовали балансировщик нагрузки на стороне клиента и контейнер Cloud Foundry для создания контейнеров. С C2C вы можете напрямую общаться с другими приложениями. В этом случае необходим реестр, чтобы вы могли найти приложения-службы.
В этом сообщении блога рассказывается о базовом примере использования SCS и C2C (он предназначен для PWS, но должен работать в любой среде PCF с C2C).
https://content.pivotal.io/blog/building-spring-microservices-with-cloud-foundrys-new-container-networking-stack
Еще один связанный вопрос, если все мои сервисы следуют одному и тому же соглашению об именовании, например, myapp-service и, следовательно, доступны по адресу https://myapp -service.cfapps.io Есть ли какое-либо преимущество в настройке службы обнаружения служб (например, Eureka) в облаке PaaS?
Мне кажется, вопрос в том, как ваше приложение находит myapp-service.cfapps.io? Если у вас есть одно приложение, которое использует одну услугу, не так уж сложно настроить приложение с помощью URL-адреса или, возможно, передать его через переменную env или даже предоставленную пользователем привязанную службу. Проблема решена.
Когда вы начинаете получать множество услуг, где «множество» - произвольно большое число, это становится проблемой для управления. Когда вы достигнете этой точки, использование сервисного реестра облегчит жизнь. Нельзя сказать, что вы не можете использовать реестр сервисов со сценарием «одно приложение / один сервис», просто это, вероятно, не такое большое преимущество.
Другим преимуществом использования реестра служб является сеть C2C, как я уже упоминал выше. В этом случае вам нужно что-то, чтобы найти ваши сервисы в сети контейнеров. Реестр SCS сделает это.
Для чего бы это ни стоило, если вы пользуетесь довольно свежей версией CF, на самом деле существует сервис, предоставляемый платформой через DNS. Если доступно, это также может быть использовано для поиска экземпляров службы. Подробности здесь.
https://www.cloudfoundry.org/blog/polyglot-service-discovery-container-networking-cloud-foundry/