我正在使用Ribbon / Eureka / Hystrix和Zuul开发微服务架构，一切工作正常。但是，当我们使用微服务时，我们可以根据需要扩展微服务，并拥有同一微服务的不同实例。目前，负载均衡在Zuul的一个实例，作为群集的不同Eureka实例以及µservice的不同实例上都可以很好地工作。问题是：我可以定义多个Zuul实例吗？如果是，不是可以使用不同的端口访问Zuul，并且正在失去发挥其优势的反向代理作用吗？ “因为现在，我认为这是单点故障和潜在的瓶颈。
有人可以解释如何避免此问题吗？
答案 0 :(得分：1)
我可以定义多个Zuul实例吗？
在我看来，您可以并且实际上应该为使用spring-cloud构建的复杂微服务系统定义多个实例。
不能使用不同的端口访问Zuul，并且丢失了 反代理角色正在发挥作用吗？
配电系统中的多个实例可能会提高容错能力，并可以在您的microserver-sys中处理更复杂的路由，如果您为其设计该怎么办，并且它的强度并没有太大关联。（也许我只是误解了OP的含义？ ）
我认为zuul的角色就像微服务的软件API网关一样，不仅代理，而且 Authentication ，动态路由，安全性。 ..和spring-cloud-starter-netflix-zuul中，它具有Ribbon和Hystrix依赖项，用于负载平衡和断路器。 Zuul是spring-cloud的mircoservice解决方案的一部分，处理网关的工作与普通网络网关一样。
认为很难说Zuul是（或不是）瓶颈。
问题的重点可能是How to avoid network-gateway becoming a bottleneck吗？
答案 1 :(得分：1)
以上答案有效。您还可以通过注册多个实例并将其放在Zuul之类的cloud-based load-balancer后面来避免AWS ALB成为瓶颈，这样可以满足流量需求。