2016-02-03 3 views
1

Обычно разработчики приложений, например, J2EE, не придают приоритетности инфраструктурным проблемам при разработке приложения. Трудно взаимодействовать с традиционной неперестраиваемой инфраструктурой. Традиционный подход заключается в создании файла .war, который затем может быть запущен на сервере приложений, таком как JBoss. Традиционные рамки, такие как Spring (кроме нового аромата Spring Cloud), воспринимают это как предпосылку. Теперь, если существует отказоустойчивое, эластичное время выполнения развертывания, доступное, например, Kubernetes, похоже, что запись бизнес-приложения одинаково игнорирует такие возможности, как планирование, предоставляемое средой выполнения. Конкретный вопрос: типично ли для приложений говорить (и извлекать выгоду) из среды выполнения (например, Kubernetes, Mesos и т. Д.)? Если да, можете ли вы указать на хороший пример. Большинство ресурсов, которые я нашел, сосредоточены на стороне Ops больше, чем Dev.Что означает, что разработчик приложения запускает приложение в Kubernetes?

ответ

4

Нет, точка Kubernetes заключается в том, что ваше приложение не обязательно должно «осознавать» его. (В Mesos больше философии «приложения должны знать о нас».)

В Kubernetes каждый стручок только начинает и слушает порт. Приложение не регистрирует его присутствие или даже сообщает, какая версия. Когда ему нужно поговорить с другой службой, он использует DNS (или даже фиксированный IP-адрес службы), чтобы найти LB для этой последующей службы.

Обычно разработчики приложений не приоритеты, связанные с инфраструктурой проблем при проектировании приложения

В общем, есть только две вещи, чтобы беспокоиться о:

1) Сделайте свой сервис без гражданства, поэтому вы выталкиваете состояние на грани (базы данных и/или клиенты). Это позволяет Kubernetes «масштабировать» ваше приложение, запуская больше копий. Служебные услуги практически невозможно масштабировать.

2) Разбейте приложение на несколько «микросервисов», чтобы вы могли масштабировать функцию «просмотр продукта» без масштабирования функции «входа в систему».

3) Дополнительно: Голова в направлении 12factor приложений.