Zuul 是我的应用程序的唯一入口点吗？

Question

我在我的基于微服务的应用程序中使用 Zuul 已经有一段时间了，它运行良好。

现在有人问了我一个问题，让我觉得微服务世界毕竟不全是彩虹和鲜花。

所以问题是“您将 Zuul 作为您应用程序的唯一入口点，这不是某种集中化吗？如果 zuul 宕机了怎么办？”

我只是想收集一些意见，并得到这个问题的答案。

谢谢。

Answer 1

是的，它是入口点，它为许多在您的微服务架构中拥有单一入口点的专业人士提供服务。

优点： 我能想到的头上

1. 所有 API 用户（应用程序）的单一联系点。 Zuul 在 api.yoursite.com 上运行并且每次都调用它比从你的 api 消费者调用单个服务（service1.yoursite.com、service2.yoursite.com）更好。

2. 从安全的角度来看，您只需处理一台服务器的安全性，您可以隐藏在网络中运行您服务的所有其他服务器，而不是将它们暴露在公共互联网上。亚马逊 AWS 和许多其他提供商都提供了这样的设施。

3. 您可以使用 zuul 作为入口点来利用路由优势，您可以将 80% 的流量路由到 service1 旧版本，而将 20% 的流量路由到相同的 service1 新版本。

缺点：

强大的力量伴随着巨大的责任。 如果您的主 zuul 服务器已关闭，则您的整个应用程序都已关闭。（编辑：仅当您有一个 zuul 设置时）。请查看@lahiru 的回答如何使用 eureka 注册表配置拥有多个 zuul 集群。

Answer 2

如果您的 Zuul 实例已关闭。您可能无法通过 api 网关定向到其他服务。

作为一种解决方案，我建议您使用具有两个 zuul 实例的集群解决方案。 你需要两个客户端服务注册服务（Eureka Servers）。

如果你打算管理容错，你可以申请哨兵。

您的微服务成为 eureka 客户端。

您必须在两个 eureka 服务器中注册您的微服务并创建一个 eureka 服务器集群。您可以参考下图作为实现的设计/架构图。

注意：您必须为两个 zuul 服务器维护两个端点。如果 zuul 1 宕机，客户端可以向 zuul 2 请求。 这将帮助您实现零停机时间。（您需要确保您的 VM 平台可靠且没有计划外停机时间）。