В чем разница между понятиями service/user provided service и apps в облачном литейном цехе? В конце концов оба они отображают URL-адресаСлужба облачного литья против приложения
Итак, когда рекомендуется создавать службу и когда приложение?
app находится поверх стека и часто имеет пользовательский интерфейс. Он потребляет услуги (построен на сервисах). Приложение Cloud Foundry обычно запускается в браузере и доступно через URL-адрес. Есть apps that have no route (не доступный URL).
A service обеспечивает расходную функциональность. Он также имеет URL-адрес, чтобы приложения или другие службы могли его достичь. Типичным сервисом является база данных или служба бота/беседы/диалога, карта или некоторые службы входа/пароля.
Чтобы сделать его более увлекательным, есть службы, которые обертывают приложение и обеспечивают доступность функций приложения через URL-адрес. Я бы рекомендовал прочитать Cloud Foundry overview или Bluemix overview. Вы также можете проверить некоторые образцы here или here, которые демонстрируют, как приложения основаны на сервисах.
Чтобы ответить на вопрос о том, когда нужно создать службу или приложение:
- Является ли функциональность для конечного пользователя? Имеет ли пользовательский интерфейс? => app
- Будет ли он использоваться другим приложением или службой? => Сервис
Спасибо 1+, что используется в приложении без доступного URL? –
in addtion Как приложение ограничено пространством, а что касается обслуживания в пространстве 1. service - если я реализую сервис (используя служебный брокер api) в dev-пространстве, это делает видимым в qa-пространстве 2. пользователь предоставил servcie - тот же вопрос спасибо –
Я добавил ссылку на раздел «Без маршрута». Это могут быть приложения-демона, приложения, работающие в фоновом режиме. Откройте еще одну тему для своих последующих вопросов. –
Один из способов, чтобы рассмотреть это, глядя на него с точки зрения зависимостей:
Приложения, как правило, зависят от услуг, таких как базы данных или сторонних поставщиков SaaS. Когда разработчик устанавливает и связывает службу с приложением, сервисный брокер для этой службы несет ответственность за предоставление экземпляра службы.
Источник: https://docs.cloudfoundry.org/concepts/architecture/#services
С другой стороны, услуги не имеют тенденцию зависеть от приложений.
Спасибо 1+, Поскольку приложение занято пространством, а что касается обслуживания в пространстве 1. сервис - если я реализую услугу (используя служебный брокер api) в dev-пространстве, то это видно в qa/пробеле 2.предоставленный пользователем servcie - same questio –
Я не уверен в ответе. Возможно, стоит опубликовать новый вопрос об этом. –
Многие службы выставляют URL-адреса, но нет необходимости, чтобы они это делали. Служба может выставлять учетные данные и значения соединения как дискретные значения, такие как хост, порт, имя пользователя и пароль вместо URL. Или служба не может предоставлять никаких сведений о соединении или учетных данных вообще (например, не привязываемая к службе услуга, которая содержит только ресурсы ресурсов). –