Сочетание Spring Cloud и инструментов оркестрации, таких как Docker Swarm и Kubernetes
У меня есть облачное приложение, которое реализовано с использованием Spring Cloud Netflix.
Итак, в своем приложении я использую обнаружение служб Eureka для управления всеми экземплярами различных служб приложения. Когда каждый экземпляр службы хочет поговорить с другим, он использует Eureka для получения необходимой информации о целевой службе (например, IP и порт).
Оркестровка сервисов также может быть достигнута с помощью таких инструментов, как Docker Swarm и Kubernetes, и похоже, что есть некоторые совпадения между тем, что делает Eureka, и тем, что могут делать Docker Swarm и Kubernetes.
Например, представьте, что я создаю сервис в Docker Swarm с 5 экземплярами. Итак, swarm гарантирует, что эти 5 экземпляров всегда будут в рабочем состоянии. Кроме того, каждая служба приложения отправляет периодический контрольный сигнал на Eureka внутри, чтобы показать, что он все еще работает. Кажется, у нас есть два уровня проверки работоспособности: один для Docker, а другой внутри самого Spring Cloud.
Или, например, вы можете открыть порт для службы для всего роя, что устраняет некоторые потребности в обнаружении службы (порты всегда очевидны). Другим примером может быть балансировка нагрузки, выполняемая routing mesh внутри докера, и балансировка нагрузки, выполняемая внутренне компонентом Ribbon или самим Eureka. В этом случае наличие аппаратного балансировщика нагрузки приводит нас к трехуровневой функции балансировки нагрузки.
Итак, я хочу знать, рационально ли использовать эти инструменты вместе? Кажется, что использование комбинации этих технологий значительно увеличивает сложность приложения и может быть избыточным.
Спасибо за чтение!
Ответы 3
Вы правы в том, что это кажется лишним. По личным наблюдениям, я думаю, что каждый уровень этой архитектуры должен обрабатывать балансировку нагрузки по-своему. В конечном итоге это дает вам гораздо больше гибкости при не намного большей стоимости. Если вы хотите воспользоваться преимуществами балансировки нагрузки на стороне клиента и любыми функциями аварийного переключения, имеет смысл установить Eureka. Основное преимущество заключается в том, что если вы не хотите пользоваться всеми функциями, вам не нужно этого делать.
Балансировка нагрузки на уровне оркестрации контейнера имеет место для любых приложений или служб, которые не соответствуют вашей части обнаружения службы, которая находится на уровне приложения (Eureka).
Аппаратный балансировщик нагрузки обеспечивает еще один уровень, который позволяет балансировать нагрузку вне оркестратора контейнеров.
Конкретный вариант использования, с которым я столкнулся, был на AWS для кластера Kubernetes с Traefik и Eureka с Spring Cloud.
Да вы правы. У нас есть аналогичное приложение Spring Cloud Netflix, развернутое на облачной платформе Oracle и Predix Cloud Foundry. Если вы используете несколько кластеров Kubernetes, вам необходимо использовать балансировку нагрузки ленты, потому что у вас есть несколько экземпляров для служб.
Я не могу сказать, что лучше Kubernetes или Docker Swarm. Мы используем Kubernetes для оркестровки сервисов, поскольку он обеспечивает большую гибкость.
Если у вас уже есть работающее приложение, то удаление компонентов netflix, вероятно, требует больше усилий и рисков, чем их сохранение. Есть аргумент, что если бы вы могли удалить, например, eureka, тогда вам не нужно будет поддерживать его, и будет на одну вещь меньше обновляться. Но это может не оправдывать усилия, а также зависит от того, используете ли вы его для чего-либо, что не может быть выполнено инструментом оркестровки.
Например, если вы подключаетесь к службам, для которых не настроена балансировка нагрузки ("безголовые службы"), вам может потребоваться лента в ваших службах. (Вы можете сделать это с помощью инструментов в весенний облачный проект инкубатора Kubernetes или его ткань8 эквивалент.) Еще одна ситуация, о которой следует помнить, - это когда вы подключаетесь к внешним службам (т.е. службам за пределами кластера kubernetes) - тогда вы можете захотеть добавить балансировку нагрузки или скорость ограничение и лента / гистрикс были бы вариантом. Это будет зависеть от того, насколько детализированы ваши требования к балансировке нагрузки или ограничению скорости.
Вы спросили конкретно о netflix, но стоит четко заявить, что Spring Cloud включает в себя другие компоненты, а не только netflix. И что есть и другие области пересечения, в которых вам нужно будет сделать выбор.
Я сосредоточился на Kubernetes, а не на рое докеров, отчасти потому, что это то, что я знаю лучше всего, а отчасти потому, что я считаю это текущим направлением путешествия для индустрии - здесь вы должны отметить, что kubernetes доступен в Docker EE. Думаю, вы читали много сравнительных статей, но https://hackernoon.com/a-kubernetes-guide-for-docker-swarm-users-c14c8aa266cc может быть вам особенно интересен.