Как не допустить, чтобы Зуул стал узким местом

Question

Я работаю над микросервисной архитектурой с Ribbon / Eureka / Hystrix и Zuul, все работает нормально.Но поскольку мы работаем с микросервисами, мы можем масштабировать наши микросервисы так, как хотим, и иметь разные экземпляры одного и того же микросервиса.На данный момент балансировка нагрузки прекрасно работает с одним экземпляром Zuul, различными экземплярами Eureka, выполненными в виде кластера, и различными экземплярами µ-сервисов.Вопрос: могу ли я определить более одного экземпляра Zuul?Если да, разве Zuul не может быть доступен через разные порты и теряет роль обратного прокси, которая делает его сильным?потому что сейчас я вижу это как единую точку отказа и потенциальное узкое место.

Может кто-нибудь объяснить, как избежать этой проблемы?

Answer 1

могу ли я определить более одного экземпляра Zuul?

Вы можете и на самом деле должны определить более одного экземпляра для сложной системы микросервисной сборки с использованием Spring-Cloud, по моему мнению.

не может получить доступ к Zuul через разные порты и теряет роль обратного прокси, которая делает его сильным?

Несколько экземпляров в системе распределения могут повысить отказоустойчивость и могут иметь дело с более сложной маршрутизацией в вашей микросерверной системе, что, если вы планируете, и это не имеет большой связи по своей силе. (Может быть, я просто неправильно понимаю значение OP? )

Я думаю, что роль zuul подобна программному API-шлюзу для микросервиса, не только прокси, но и Аутентификация , Динамическая маршрутизация , Безопасность ... и в spring-cloud-starter-netflix-zuul он имеет зависимости Ribbon и Hystrix для баланса нагрузки и автоматических выключателей. Zuul является частью миркосервисного решения Spring-cloud и работает со шлюзами, как и обычные сетевые шлюзы.

Думал, что трудно ответить, что Зуул является (или не является) узким местом. Может вопрос в том, How to avoid network-gateway becoming a bottleneck?