如何避免 Zuul 成为瓶颈

Question

我正在使用 Ribbon/Eureka/Hystrix 和 Zuul 开发微服务架构，一切正常。但是当我们使用微服务时，我们可以根据需要扩展我们的微服务，并拥有相同微服务的不同实例。目前，负载均衡在一个 Zuul 实例、不同的 Eureka 实例作为集群以及不同的 µservices 实例上运行良好。问题是：我可以定义多个 Zuul 实例吗？如果是的话，Zuul 是不是可以使用不同的端口访问，并且正在失去发挥其优势的反向代理角色？因为现在，我认为它是单点故障和潜在瓶颈。

有人可以解释一下如何避免这个问题吗？

Answer 1

上面的答案是有效的。您还可以Zuul通过注册多个实例并将它们放在cloud-based load-balancer诸如 之AWS ALB后来避免成为瓶颈，这将扩展以满足流量需求。

Answer 2

我可以定义多个 Zuul 实例吗？在我看来，您可以而且实际上应该为使用 spring-cloud 构建的复杂微服务系统定义多个实例。Zuul 不能使用不同的端口访问并且正在失去发挥其优势的反向代理角色吗？分布式系统中的多个实例可能会增加容错能力，并且可以在你的微服务器系统中处理更复杂的路由，如果你设计的话，它的强度没有太多关联。（可能我只是误解了 OP 的意思？）我认为zuul的角色就像是一个软件API网关的微服务，不仅代理，但身份验证，动态路由，安全......在春季云起动，Netflix的-zuul，它拥有Ribbon和Hystrix依赖于负载均衡和断路器. Zuul 是 spring-cloud 的 mircoservice 解决方案的一部分，交易网关的工作就像普通网络网关一样。认为很难回答说 Zuul 是（或不是）瓶颈。问题的重点是How to avoid network-gateway becoming a bottleneck什么？